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

Start by seeing which side owns the responsibility: the protocol cannot enforce these rules by design. The specification states outright that MCP itself cannot enforce these security principles at the protocol level, that tool descriptions and annotations should be treated as untrusted unless they come from a trusted server, and that hosts must obtain explicit user consent before invoking any tool mcp-spec. The protocol exists to put capabilities on the table. Nothing in the stack will stand behind the question of whether they may be used, and to what extent.

So the items below are not best practices. They are the host's own responsibility:

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.

Validate the frontmatter against the spec before you ship. The skill spec allows six fields and no more, and an extra field is silently ignored in one tool while it errors out in another — the same mistake failing quietly here and loudly there, so a constraint you believe is in force may never have been. A real case: a line reading tools: Read, Write, Edit was added, but that field belongs to the sub-agent file, not the skill. One tool skipped it without a sound; another tool's packaging validator refused outright aase-egm.

The skill body: why before what

The layout of a body is not a formatting preference. It is written for a reader who has no idea what is going on. A SKILL.md reads like a runbook you would hand a colleague: an opening paragraph on what problem this skill solves and what it produces, then the hard rules, a checklist of steps, each step, the anti-patterns, and finally where this skill sits in the larger flow.

"Why this step exists" is worth more than "you must do this." A model that knows the reason can make the right call when the steps do not cover the case; one that only knows the prohibition has to guess outside the list. The anti-patterns are the most valuable lines in most skills — they were written after watching something actually go wrong, while steps can only prevent the errors you thought of in advance.

Put the hard rules at the top. Long sessions get compacted, and after compaction only the beginning of a skill survives, so anything written late is the same as not written. The checklist serves the same purpose: a session that runs for days relies on a checklist and a status file to know which step it is on.

References and assets are two different jobs. The first is guidance the model reads in order to judge; the second is a template that gets copied into the output. They are kept apart for a reason that has nothing to do with tidiness: they load at different times. Guidance loads when it is time to read; a template loads when it is time to use. One constraint is easy to miss — every reference has to sit one hop from SKILL.md. Ask the model to follow a reference and then follow a link inside it and it will skim its way past the part that mattered.

Strictness follows fragility

Not every instruction should be equally strict. The test for matching them is whether softening this step would break something immediately.

• Low freedom, verbatim. The lines that set the tone, the framework you want restated, the reset line the model says back to itself. Change a word and the effect changes — "you are not very polite" and "rip it apart" are not the same thing.
• Medium freedom, a template. The skeleton of the output, the shape of the ledger. Field names have to be right; the content can vary with the case.
• High freedom, only a goal. The part that needs back and forth, such as what an interview should ask and where it should dig. This part cannot be written as steps, and writing it as steps only freezes it.

How strict an instruction should be asks whether softening it would break something immediately, not how important it is. An important judgment can often be given as nothing more than a goal, while a fragile opening has to be word for word.

Why a tone-setting line has to be word for word: models are trained to be agreeable, so "please review this critically" still reaches them as the polite version. Say it flatly up front instead — "I have a strong intuition that this code is of poor quality. Please tear it to shreds and tell me all the ways it sucks" — and what changes is what "helpful" means for this conversation: you have declared that you expect bad news, so being pleasant now means failing the task. Rewording it is not a style choice, it is swapping a load-bearing wall for decoration.

Where a script belongs, not a prompt

Some steps need no judgment. They need to come out the same every time, and those should be a script.

There are two reasons. A script is executed, not read — a few hundred lines of checking logic cost the model only their output; a prompt is carried on every turn. A script is also the same every time: asking the model to grep for "ten consecutive lines without a comment" cannot be done, because it improvises differently each time, and a finding labeled "mechanically checked" stops meaning anything.

Scripts written for agents differ from scripts written for people in a few specific ways. No interactive prompts, because an agent cannot answer "are you sure". --help has to teach the model how to use the thing. Exit codes have to mean something, so the skill can say what to do next based on the code. Errors have to state what to run next, not "not found".

The last of these matters most: the script measures, the human decides. A script that checks a gate should not go on to change the state of that gate itself. Measuring belongs to the script and judging belongs to the person, and that division of labor is the strongest guard in the whole method against a model watering things down to get to the end.

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."