MCP vs skills: do you need a connection or a playbook?
A grounded distinction between MCP servers, tools, resources, prompts, and skills for teams extending AI agents.
The common confusion
Both MCP and skills show up when people ask how to give an agent more context. That phrase hides two different needs. Sometimes the agent needs access to a system: list tables, read a file, search docs, create an issue. Sometimes the agent needs a method: review a migration, write in a brand voice, or triage an incident.
MCP is strongest for the first need. Skills are strongest for the second.
The confusion is understandable because both change what the model can do. But they change different things. MCP changes what systems the agent can reach. Skills change how the agent uses that access. Mixing them up leads to strange designs, like hiding API credentials inside a markdown playbook or turning a review rubric into a fake tool.
MCP is an interface to capabilities
An MCP server exposes tools, resources, and prompts through a standard protocol. The client can discover what is available and call into those capabilities without each agent inventing a custom integration.
This is useful when the capability should be shared across many clients or agents. A Postgres MCP server, a Linear MCP server, or a docs search MCP server can serve multiple workflows.
MCP is especially useful when the external system is not owned by the agent author. A team can maintain one approved server for a database, CRM, or ticketing system, then let multiple agents use the same capability under the same access rules.
Skills are playbooks
A skill is a playbook. It tells the agent how to perform a class of work: what to check, what to avoid, what output shape to use, what examples matter.
Skills should not hide credentials or grant authority. They can tell the model to use a read-only SQL tool carefully, but the read-only boundary must still live in the tool, database role, MCP server, or runtime policy.
A good skill makes the agent more consistent without giving it new powers. It might teach severity levels for code review, rules for customer-facing email, or the right way to answer analytics questions. The skill improves judgment; it does not replace permissions.
Use both when capability needs a method
Many useful workflows need both layers. A data analyst needs database access and metric definitions. A support agent needs ticket access and escalation policy. A code reviewer needs GitHub access and review calibration.
In those cases, the design question becomes: what does the agent need to reach, and what does it need to know? MCP answers the first question. Skills answer the second.
Decision table
MCP
Use when
The agent needs live access to external tools, resources, or server-provided prompts.
Avoid when
The agent only needs local procedure or writing rules.
Skill
Use when
The agent needs repeatable judgment, checklists, examples, or output standards.
Avoid when
The agent needs credentials or live system access.
Both
Use when
A workflow needs external capability plus domain-specific procedure.
Avoid when
The combination adds indirection without improving reuse or safety.
FAQ
Can a skill call an MCP tool?
A skill can tell the agent when and how to use the tool. The runtime still performs the actual tool call.
Can MCP replace skills?
No. MCP can expose prompts, but skills remain useful for local, portable procedure and examples.
Which is safer?
Neither by default. Safety comes from scopes, validation, approvals, and logs.