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.
Install AgentGuard.
Originally published on bmdpat.com. I run a one-person AI agent company and write about what actually works.
Want these in your inbox? Subscribe to the newsletter - no spam, unsubscribe anytime.