Where MCP and Skills Belong

Use MCP for dynamic discovery and cross-client ecosystems, typed service tools for stable side effects, and treat a skill as supply chain, not documentation.

Use MCP for dynamic capability discovery and cross-client ecosystems. Use typed service tools for stable operations and side effects. And treat a skill as something closer to a dependency than to an article: installing one changes how every future matching task gets executed, not just what you have read.

MCP is for discovery, not for calling

MCP fits when you need to reuse tools across processes or languages, plug into a third-party tool ecosystem, share capabilities across agent hosts, or standardize discovery of resources and prompts.

Avoid it just as clearly for ordinary functions inside one process, business logic serving a single project, low-latency core paths, and high-risk operations without a clear authorization boundary. Stable operations and side effects belong in typed service tools. Batch work, rerunnable jobs, CI, builds, tests, and migrations belong in CLIs and scripts.

The test is one sentence: are you trying to discover unknown capabilities at runtime, or to execute a known operation reliably? The first is MCP. The second is not.

The MCP security baseline has no optional items

HTTP MCP uses a standard authorization flow with token audience validation. No token passthrough, no tokens in URLs, HTTPS everywhere. A local MCP install shows the full command and gets explicit consent. Every MCP server is its own trust domain. Connect on demand, per skill or task, rather than connecting every server by default.

The one teams skip is treating each server as a separate trust domain. Connect three MCP servers and you have pulled three pieces of external code inside your trust boundary; if any one misbehaves, the blast radius is whatever permissions you granted it. The local-install rule fails the same way — the user reads a friendly one-line description while the machine runs a full command.

MCP costs are resident costs

Tool cost is not only execution. It includes schema tokens that sit in context permanently, selection reasoning, argument construction, execution, result injection, and the repeated carriage of all of that through later history. Connect enough servers and the schemas alone take a visible bite out of the window.

How big a bite is on record. Five MCP servers can introduce tens of thousands of tokens of tool definitions, which is close to 30% of a 200K window before the first user message. Cursor's mitigation was to sync tool descriptions into a folder and show the agent only an index of names, with definitions fetched when needed; in an A/B test that cut total token consumption on MCP-related tasks by 46.9% ai-agent-book.

Shape and volume are two separate decisions and teams keep collapsing them into one. Whether a capability is a dedicated tool or a skill decides how many tokens it keeps resident, how its arguments travel, and who may change it; how many capabilities sit in front of the model at once is a disclosure policy ai-agent-book. The two price points are far apart. Connecting an MCP server opens a runtime connection whose full tool definitions enter the context of every session; installing a skill copies a folder to disk, and only its name and description stay resident, which is one to two orders of magnitude cheaper. That cheapness pushes out the distance at which "keep the whole skill catalog resident" stays viable — but it only loosens the disclosure side of the ledger. It does not choose a disclosure policy for you.

So set a server and tool allowlist per agent, measure what each schema and result costs, push large results into an artifact store, and never expose every connected MCP tool to every agent by default. The converse also holds: cost is never a reason to skip permissions, confirmation, or audit.

A skill is supply chain, not documentation

Four stages each need their own permissions and audit trail: discovery, installation, activation, execution. A production-grade skill carries a pinned version and digest, a named owner, a compatibility matrix, reviewed signatures for any executable script, a trigger eval, and a rollback path.

Drop any one and you cannot answer a basic question in production: which version of which skill changed this behavior?

One risk here is semantic rather than logistical. A skill is the institutionalized form of loading external content as instructions. Text hidden in a web page still has to survive whatever you do to the page before it reaches the model; skill content takes effect directly, in the voice of instructions. A malicious line inside a third-party skill is far more effective than the same line on a page, which is why an unaudited skill should be read line by line — body and scripts — the way you would read code you are about to execute ai-agent-book.

Progressive loading, and what is worth a skill at all

Load in three steps: names and descriptions first, the full SKILL.md after a task matches, and references, scripts, and assets only when needed. Descriptions must state when the skill triggers and when it does not, and you have to test both false triggers and missed triggers.

Write the description as a routing condition rather than a feature blurb: "when to use me" matters more than "what I can do." Phrased broadly — "help with backend" — every backend task can trigger it and routing loses its edge, so the book's advice is to spell out both boundaries and include a few counter-examples of work the skill should not take ai-agent-book.

Scale is the hard constraint on this mechanism. Once enough skill descriptions sit permanently in the system prompt, quality degrades even on frontier models, so selection has to happen before loading rather than after you have flattened every skill into the prompt langchain-stripe.

One skill at Tencent Cloud is the full worked example. It carried an entire C++ to tRPC-Go refactor: uncommented historical patches, a dozen state-machine branches scattered across four or five projects, and nothing trustworthy except the code itself. They compressed the knowledge into three tiers — rules capped at 100 lines injected automatically when you edit the target directory, a SKILL.md under 200 lines holding only the five-stage flow, and references of any length loaded per stage. Judgments only domain experience could make were turned into multiple-choice questions, at most five per round, with decisions written to clarifications.md so later sessions could restore them. Then a circuit breaker: three failed attempts at the same error and it stops for a human; five rounds of automated test-fix loops and it halts and summarizes. The result was a refactor that used to depend on tribal knowledge and took days becoming a reproducible flow tencent-skill-refactor.

That clarifies where durable value sits. Generic public techniques get absorbed into model weights eventually, and a skill built around them decays to zero contribution. Durable value is procedure plus current sources plus tools plus policy plus a verifier plus recovery plus provenance: skills that need constant updating, carry organizational ownership, or touch real permissions are the ones worth building.

Four layers of skill evaluation

Run a control: if the model does the task without the skill, the skill contributes nothing. Calibrate difficulty: too easy and no difference shows, too hard and both arms fail. Trace the trajectory: the skill was in context, but did the model actually follow it? Verify the path: the result is correct, but did it skip the critical checks?

The last two are the ones teams skip and the ones that lie to you. Judge by final output alone and you will book "the model would have done this anyway" as "the skill worked."