PMaker home
Two words people keep mixing up — the split is actually simpleSkillInstructions for the model: steps, formats, boundaries, examples; touches no external systemSolves "it doesn't know how" — you change it by editing a document, zero codeMCPA standard way to connect: wraps databases, order services, email into one shapeSolves "it can't reach" — connection only, does not fix usage"Doesn't know how" means Skill; "can't reach" means MCP; most real agents use both

A Skill is an operator's manual for the model; MCP is a power strip for the system. One changes knowledge, the other changes interfaces.

Skills and MCP

One carries knowledge, the other carries interfaces. They solve different problems; don't mix them up.

These two words keep getting treated as the same thing, but they solve two completely different problems: one tells the model how to do things, the other tells the system how to connect.

Symptoms you'll recognize:

  • The docs use the two words interchangeably, and a meeting runs on for an hour before anyone notices they are two things.
  • You install MCP and expect the model to know how to do its job; it still does not.
  • You want "an agent that writes weekly reports" and cannot tell whether that is a Skill or an MCP.

What each word solves

A Skill carries "how." It is instructions for the model: the steps to follow for a class of tasks, the format to use, the boundaries to respect, examples to imitate. It touches no external system; it only changes how the model goes about its work.

MCP carries "how to call." It is a standard for connecting: it wraps your systems, databases, order services, email, in a uniform shape so an agent can call them through one convention. It solves the connection problem; it does not care whether the model knows how to use those capabilities well.

A handy pair of metaphors: a Skill is the operator's manual, and MCP is the power strip. The manual tells a person how to operate; the power strip lets them plug in. Both matter, and they are different things.

How a Skill is organized

A Skill usually has a few parts.

Trigger conditions: when to use this Skill, whether the user mentioned a relevant need or an action was detected.

Steps: the order in which to do this kind of task. This is the body.

Rules and boundaries: what not to do, format requirements, quality floor, what to do on errors.

Examples: one or two complete input-output pairs, worth more than any abstract description.

At bottom, a Skill is a high-quality prompt and reference pack. Its biggest value is organizational: collecting best practices that were scattered around into a reusable bundle. Editing a Skill is editing a document, no code, takes effect immediately, and is far cheaper than changing logic.

That is also its boundary: a Skill cannot change whether the model can reason. It can only make the model follow a better process with the abilities it already has. If the task itself exceeds the model's capability, no amount of Skill detail helps.

What MCP solves

MCP solves the standardization of integration. Before it, wiring a new system into an agent meant writing bespoke adapter code in whatever format you liked. MCP defines one shape: tools, which are callable operations with parameter specs; resources, which are readable data and files; and prompts, which are reusable instruction templates.

For a product person, the point of MCP is not the protocol; it is the ecosystem. More and more mainstream systems ship MCP interfaces natively, so hooking up a new service keeps getting cheaper. The official docs use the USB-C analogy themselves: one standard connector replacing a pile of proprietary cables. mcp-intro

But mind the boundary: MCP puts interfaces in front of the agent; it does not guarantee correct use. Poor tool descriptions, misconfigured permissions, untrustworthy data — MCP fixes none of these, and things still blow up.

Which one when

A practical rule of thumb.

"The problem is it doesn't know how": use a Skill. You need it to follow a process, a format, a standard — that is a knowledge problem, solved cheaply with a Skill.

"The problem is it can't reach": use MCP or a custom tool. You need it to actually query a database, send a message, operate a system — that is a connection problem. Use MCP when the system already has an interface; otherwise write a custom tool.

Usually both. A mature agent typically has MCP providing a set of external capabilities, Skills describing how to combine them into a complete job, and layered prompting governing the overall behavior. Anthropic's guidance on building agents uses the same structure: tools define what is possible, workflows and prompts define how it is done. anthropic-agents

One final caution: don't use it for its own sake. If you are connecting a single interface, a simple tool function is enough; you do not need a full MCP stack. MCP pays off when there are many systems to integrate and manage.

References

  1. What is the Model Context Protocol (MCP)? — Model Context Protocol
  2. Building effective agents — Anthropic