MCP vs Skills: a practical decision guide for builders
I need my agent to do X. Skill or MCP?
If you build agents on Claude or anything MCP-compatible, this is the question that actually matters. The two patterns get pitched as alternatives. They are not. They solve different problems. Most production agents need both.
Here is the decision rule, the framing for each, and the anti-patterns I keep seeing.
The two patterns in 60 seconds
MCP (Model Context Protocol). A wire protocol. Your agent talks to an MCP server over JSON-RPC. The server exposes tools, resources, and prompts. The runtime is separate from the agent. Anything live, anything stateful, anything that needs auth or a real connection lives behind MCP.
Skills. A folder of markdown that gets loaded into the agent's context. No extra runtime. No protocol. The agent reads the SKILL.md, follows the instructions, executes the steps. Skills are procedural knowledge in a format the agent already knows how to read.
That is the whole shape. MCP is a connection. A Skill is a doc the agent treats as a playbook.
The decision rule
I use one rule and it has held up across every agent I have shipped this year:
- Live data or live state? Ship MCP. Database queries, third-party APIs, file system access, anything that has to hit the wire and come back with fresh data. MCP.
- Reusable how-to? Ship a Skill. Procedures, conventions, multi-step workflows the agent should follow consistently. Things you would write in a runbook. Skill.
- Both? Ship both. This is the common case for any tool that wraps a real system.
That is it. The rule sounds obvious. It still gets violated constantly.
AgentGuard ships both. Here is why.
I write AgentGuard, a budget and rate limiter for AI agents. It is a useful worked example because it has the textbook MCP+Skill split.
The Skill side. The AgentGuard SDK is the in-process piece. You install the package, decorate your agent function with @guard(budget_usd=2.00), and the decorator handles token counting and budget enforcement on every call. That logic runs locally in your agent's process. There is no live system to talk to. There is just code that needs to execute deterministically. A SKILL.md teaches Claude Code how to detect a project that uses LLM APIs and add the decorator with sensible defaults. That is procedural know-how. Skill.
The MCP side. The AgentGuard dashboard is a separate service. It tracks spend across runs, surfaces alerts, lets you set org-wide budgets. The agent needs to query it: how much have I spent this hour? Is this user over their cap? That requires a live connection to a stateful backend. MCP.
Same product. Two patterns. Each does the job the other could not.
Anti-patterns I keep catching in code review
Wrapping an API call as a Skill. A Skill that says "step 1: send an HTTP request to api.example.com with this payload, step 2: parse the response" is a Skill pretending to be MCP. The agent can technically follow the steps, but you have given up everything MCP gives you: typed schemas, authentication handled once, error semantics, observability. Wrap that endpoint as an MCP tool and let the protocol do its job.
Building an MCP server for a procedure. I have seen teams stand up an MCP server whose only job is to return a string of instructions. That is a Skill in a trench coat. You added a deployment, a runtime, and a network hop to deliver markdown the agent could have read directly. Move it to a Skill.
Skipping the Skill on a live system. You shipped an MCP server for your production database. Good. But the agent is still going to write bad queries because nobody told it your conventions. Add a Skill: which tables are append-only, what the soft-delete pattern is, when to use the read replica. The MCP server gives the agent the connection. The Skill gives it the judgment.
How to decide in practice
When a task lands on my desk, I ask three questions in order:
- Does this require fresh data or live state? If yes, MCP is in scope.
- Does this require the agent to follow a specific procedure or convention? If yes, a Skill is in scope.
- Does it require both? If yes, ship both, and make sure the Skill references the MCP tools by name so the agent knows when to call them.
Most non-trivial agent capabilities answer yes to two or all three. The teams I see struggle are the ones picking one pattern and forcing it. Pick both when both apply. That is the whole game.
What this means for small-business agent builders
If you are shipping AI automation for clients, the practical version of this is:
- Your client's CRM, billing system, and inventory database go behind MCP servers. One server per system if they are big enough, otherwise grouped sensibly. Auth lives there. Schemas live there.
- Your client's playbooks, sales scripts, escalation rules, and reporting conventions go in Skills. One Skill per workflow, written as markdown the agent can read end to end.
- The agent gets pointed at both. The Skill tells it what to do. The MCP servers let it do it.
That stack scales. It is also the stack that survives an agent swap. If you switch from Claude to a different MCP-compatible runtime tomorrow, the MCP servers move with you. The Skills are markdown, so they move with you too. You did not lock yourself into a single vendor's framework.
The CTA
If you ship agents in production and you have not put a budget ceiling on them, that is the next thing to fix. AgentGuard is the cheapest way to do it: one decorator, hard cap, no surprise bills.