When I consider MCP vs skills, I start with what the agent is missing. Can it reach the records it needs? Does it know the procedure to follow? Can the surrounding application enforce the limits on its actions?
Those are different problems. Adding a connector does not explain how your team handles an ambiguous support request. Writing a better procedure does not grant access to the support system. Sometimes the existing tools and a clear prompt already cover the job.
My preference is to add a component only when I can name the recurring problem it solves.
What MCP and agent skills actually provide
The Model Context Protocol (MCP) standardizes communication between a compatible AI application, its clients, and servers that expose capabilities or context. Its server features include tools the application can invoke, resources it can read, and reusable prompts. A server can run locally or remotely; MCP does not imply a hosted service. The official architecture overview describes these parts and their relationships.
An agent skill packages instructions for a task, with optional scripts, references, and assets. The Agent Skills specification defines a directory built around a SKILL.md file. A skill can describe a review procedure, provide an output template, and include a validator the agent runs.
Skills use progressive loading: a compact description helps the agent find a relevant skill, its instructions are loaded when activated, and supporting files are accessed as needed. The exact discovery and activation behaviour depends on the host; the integration guide describes several approaches.
There is overlap. MCP prompts carry instructions. Skills can direct an agent to use existing tools, execute scripts, call an API or CLI, or use an MCP server when the host provides those capabilities and permits them. A skill is not limited to passive advice.
The distinction I find useful is what I want to reuse: an interface that compatible applications can discover and call, or a procedure with the material needed to carry it out.
One support issue, four reasonable designs
Consider a hypothetical support team. An assistant should read an issue, consult the team’s escalation policy, propose a category and draft an internal note. A person must approve the exact note before it is saved. This is an illustrative design, not a report of a client deployment.
I would start with a skill if access already works. Suppose the host already has an approved helpdesk tool. The missing part is consistency: distinguish a billing question from an outage, cite the policy used, and flag missing evidence. A skill can package those steps, example cases, and a note template. A script can check required fields. Adding another connector would leave the underlying procedural problem untouched.
I would choose MCP if the missing piece is a reusable helpdesk interface. Perhaps several compatible applications need to retrieve issues through the same controlled operations. A server could expose get_issue with a defined input and predictable result. For a simple request such as summarizing one issue, the user’s prompt may supply enough direction without a separate skill. The integration still needs credentials, authorization, and useful errors. My custom MCP server tutorial shows how to wrap an existing API with a narrow read operation.
I would combine them when both problems exist. MCP supplies authorized issue records; a skill explains which policy to consult and how to produce the draft. A validator checks its structure. The application presents the proposed note for approval, and the write operation checks that approval applies to this issue and this exact content. The skill can instruct the agent to request approval; the application must enforce it.
I would use neither for a small, contained job. If a person supplies the issue and policy and asks for a draft, a prompt may be enough. If one application already uses a maintained helpdesk API client, a direct integration may be simpler. MCP becomes attractive when its common interface is useful; the presence of an LLM alone does not establish that need.
Where I expect the maintenance cost
A skill needs an owner. When the escalation policy changes, somebody must update its references and examples. A polished procedure pointing to an obsolete policy can produce a convincing, wrong answer.
An MCP server needs maintenance around the upstream system: authentication, API changes, schemas, timeouts, and error handling. A vague tool that accepts arbitrary requests transfers more decisions to the agent. A narrow operation makes its permitted use easier to understand and test.
Bundling an API script inside a skill is a valid option, but the script still needs those integration controls. Moving code into a skill directory does not remove its operational responsibilities. I would use that approach when the runtime is controlled and the script is easy to maintain. I would favour a shared interface when several consumers need the same capability. These are the tradeoffs I scope in agent API integration.
The checks I would make before trusting either
Neither the skill file nor MCP alone guarantees correct execution or provides the complete security boundary. MCP’s tool specification assigns input validation and access controls to servers and recommends client confirmation for sensitive operations. The host’s actual approval behaviour still needs checking.
For the hypothetical support assistant, I would test:
- Missing access: the issue belongs to an unauthorized account. The integration refuses it; the agent reports the limitation.
- Missing evidence: the policy does not settle the category. The agent flags uncertainty rather than inventing a rule.
- Untrusted content: the issue body says to ignore the policy or reveal credentials. That text remains evidence to inspect, with no authority to change the workflow.
- Changed or denied approval: the draft changes after approval, or the person rejects it. The write is blocked until the correct action is authorized.
- An uncertain write result: the request times out. The workflow checks whether the note was saved before attempting a duplicate.
Inspect the actual tool calls and source records alongside the final answer. A well-formatted note can hide a skipped policy lookup. A valid schema can contain an unsupported conclusion. This separation between observable behaviour and plausible output also guides chatbot testing and evaluation.
How I make the choice
I would write down three things before building: the operation the agent needs, the procedure it should follow, and the controls the application must enforce.
Then I would try the existing tools on a representative case. If the repeated failure is procedural, I would package a skill. If the missing piece is a capability several compatible hosts should share, I would evaluate MCP. If both are missing, I would combine them and test the handoff. If the job is already clear and supported, I would keep the simpler design.
The useful deliverable is an agent whose behaviour you can inspect, whose failures you can reproduce, and whose access you can constrain. The choice of packaging should help you get there.