Two answers to two different questions
People often ask whether they need an agent skill or an MCP server. The honest answer is that they usually need both, because they answer different questions.
A skill answers how should this be done? It is procedural knowledge — a recipe for a workflow, written in plain text.
An MCP server answers what can the agent do? It is a capability provider. It exposes tools and data the agent can call: a database it can query, an API it can hit, a file system it can read. MCP — the Model Context Protocol — is the standard way agents connect to those external tools.
The recipe and the kitchen
A useful image is cooking. The MCP server is the kitchen: the stove, the knives, the pantry. The skill is the recipe: the steps that turn raw capability into a finished dish.
A kitchen with no recipe leaves the agent improvising — it has tools but no reliable method. A recipe with no kitchen leaves the agent stuck — it knows the steps but has nothing to act with. Pair them and you get reliable, repeatable results: the right method applied to real capability.
Where each one shines
Reach for an MCP server when the agent needs a new ability it does not already have. If it must read from your issue tracker, run queries against a warehouse, or call a third-party service, that connection is the MCP server's job.
Reach for a skill when the agent already has the means to act but needs guidance on doing the task your way. Code review is a good example: the agent can already read a diff, but a skill encodes which issues to flag, in what order, and how to report them. Browse the development category to see how many skills assume capabilities are present and focus purely on method.
They compose
The real power shows up when you combine them. An MCP server connects the agent to your project management tool. A skill then tells the agent how to triage incoming issues using that tool — which fields to check, how to label, when to escalate. The MCP server supplies the hands; the skill supplies the judgment.
This is also why skills stay small and portable. They do not have to ship a database driver or an API client. They lean on whatever capabilities the agent already has, whether built in or provided through MCP, and add the missing layer: how to use them well.
How to choose
Ask what is actually missing. If the agent cannot reach something it needs, you have a capability gap — look at MCP. If the agent can reach everything but does the task inconsistently or wrong, you have a method gap — look for a skill, or write one.
When evaluating skills for that method gap, the criteria in how to evaluate agent skills apply directly: clear triggers, tight focus, and honest disclosure of any scripts or access. A skill that quietly bundles its own network calls blurs the line between skill and capability, and deserves extra scrutiny.
A worked example
Imagine you want your agent to keep your team's changelog updated whenever a release ships. The capability piece is reaching your version control and your release notes — that connection is naturally an MCP server's job, exposing the repository and the release data as tools the agent can call. The method piece is knowing your changelog conventions: which sections you use, how you phrase entries, what to omit. That belongs in a skill. With only the MCP server, the agent can read the release but writes the changelog however it likes. With only the skill, it knows your format but cannot reach the release data. Together, the agent reads the release through MCP and formats the entry through the skill, and the changelog stays correct without supervision.
Why the distinction keeps things clean
Keeping capability and method separate is not just tidy; it is practical. It lets the same skill work across different projects that expose similar capabilities, and it lets the same capability serve many different skills. A code-review skill does not care whether the diff arrives through a built-in editor or an MCP integration — it just needs the diff. This loose coupling is what keeps skills small, portable, and easy to reason about, while capabilities stay reusable across everything you build.