Back in April, I was building an agent for our finance team. It needed to do two things: pull live transaction data from Stripe and format the resulting invoice exactly the way our controller wanted it, down to the line-item order and the rounding rules. Simple enough on paper. I built both pieces the same way, as an MCP server, because MCP was the tool I’d used most recently, and it felt like the safe default.
It worked, but it was overkill for half the job. The formatting logic didn’t need a server. It didn’t need a live connection to anything. It needed to change how the agent behaved on a task it could already do, and I’d built infrastructure for that instead of just writing it down. That mistake is basically the whole reason I am writing this guide.
Why “vs.” Is the Wrong Frame
A lot of the content on the internet treats MCP and Agent Skills like two competing answers to the same question, which is understandable, since they showed up within a year of each other and both get filed under “the thing that makes AI smarter.” But they’re not competing. MCP is Anthropic’s open protocol for connecting an agent to external systems, Slack, a Postgres database, your internal API, whatever, through a standardized client-server bridge. A Skill is a folder with instructions in it that an AI agent loads when a task calls for it: no server, no protocol, just a SKILL.md file and maybe a script or two.
Treating them as alternatives is what gets people building an MCP server for something that should have been a two-page instruction file, or the opposite: writing a Skill that quietly reaches out to a live API with a hardcoded key sitting in a shell script. Neither mistake is really about the technology. It’s about not having asked the right question first.
The Actual Question: State and Trust
The question I should have asked before touching either was this: does this capability need to hold a live, credentialed connection to something outside the agent’s own process, or does it just need to change how the agent thinks about something it can already do?
The Stripe half of my agent needed the first thing. Pulling transaction data means authenticating with Stripe’s API, maintaining the session, and handling whatever comes back. That’s a real, ongoing relationship with an external system, and it belongs behind a server, not inside a prompt. The invoice-formatting half needed the second thing.
There’s no external state involved. The agent already has the transaction data by the time it formats an invoice. What it needs is a fixed set of rules: this column order, this rounding behavior, this header format. That’s not infrastructure. That’s judgment, packaged up so the agent doesn’t have to guess at it every time.
I split the two once I actually sat down and asked which one held state and which one didn’t. The Stripe pull stayed on an MCP server. The formatting logic became a Skill. It’s a fifteen-minute distinction to make once you know to look for it, and I didn’t look for it until I’d already built the wrong thing once.
The Token Bill Nobody Talks About
I didn’t seriously consider context cost until I checked how much of my window had already been lost before the conversation even started. A single MCP tool definition, the JSON schema describing its parameters, types, and examples, typically runs 5,000 to 6,000 tokens. Connect a handful of servers, say GitHub, Slack, and a monitoring tool, and you’re looking at around 40 tools between them. That’s over 50,000 schema tokens in context before the agent has read a single user message. One documented case put it at 55,000-plus tokens gone before anything useful happened, and that’s not a fringe setup; that’s three moderately-sized integrations.
Skills work completely differently, and this is the part I didn’t appreciate until I measured it myself. At startup, only a Skill’s frontmatter loads: the name and a one-line description, somewhere around 10 to 20 tokens per Skill. The full instructions load only after the agent determines that the Skill actually applies to the task at hand. You can have dozens of Skills sitting available and pay almost nothing for the ones that never get used.
The Governance Problem Nobody Wants to Own
I’ll push back a little on the tidy version of this story because it’s tempting to say MCP is the secure, enterprise-grade option and Skills is the loose, informal one. That’s only half true.
A Skill is a folder on disk. That’s exactly what makes it easy to build and easy to lose track of. Security researchers have started calling this problem “Shadow AI,” agent behaviors that touch real systems and real data while sitting completely outside normal review, version control, or audit processes. It’s serious enough that tooling vendors have shipped dedicated registries and signing systems this year specifically to bring Skills under the same governance discipline organizations already apply to code dependencies, and OWASP now maintains a dedicated top-ten risk list just for agentic Skills.
MCP isn’t the clean alternative here. It concentrates its risk somewhere else: in the server implementation itself. Between January and April of this year, more than 40 CVEs were filed against MCP implementations. An MCP server hides credentials behind a managed process instead of leaving them exposed in a script, which is a genuine advantage, but that process is now something you have to patch, monitor, and secure like any other piece of backend infrastructure, because it’s exactly that.
So the honest version isn’t “MCP is governed, Skills aren’t.” It’s that MCP concentrates risk in the infrastructure you’re running, and Skills concentrates risk in the content you’re trusting. Different failure modes are not a solved problem on one side and an unsolved one on the other.
Where I Got It Wrong
I’ll admit the mistake I almost made, because I think it’s a common one. Early on, before I’d properly split the Stripe agent, I considered having the Skill make the API call directly instead of standing up a server for it. It would have been faster. I’d have needed a shell script containing an API key, executed within the agent’s own environment.
The problem is obvious in hindsight and wasn’t obvious to me at the time: that key would have been sitting in a file, in the agent’s own process, one prompt injection away from being read back out or misused. An MCP server exists specifically to put a wall between the agent and the credential. The agent asks the server to do something, and only the server ever touches the actual key. Skipping that wall to save fifteen minutes of setup is exactly the kind of shortcut that shows up in a postmortem later. I didn’t take that shortcut, but I got close enough to it.
The Decision, Earned
Everything above collapses into three rules, and by this point.
| If the task needs… | Reach for |
|---|---|
| A live, credentialed connection to an external system has to work the same way across multiple agents | MCP |
| A fixed set of judgment or formatting rules, portable across tools, with no active connection required | A Skill |
| Both are in the same workflow | That’s normal. Split it; don’t force one tool to do both jobs. |
None of these are close calls once you know which question you’re actually answering. The mistake I made wasn’t picking the wrong tool. It was not stopping to ask which kind of problem I had before reaching for either one.
Back to the Invoice Agent
The finished version of that Stripe agent is boring in the best way. An MCP server handles the live connection to Stripe, authenticated, isolated, doing exactly one job. A Skill handles the formatting, the column order, the rounding, and the header layout our controller wanted, and is portable enough that I could hand the same Skill to a completely different agent tomorrow if I needed to.
It was never really a choice between two tools competing for the same job. They’re two different layers of the same system, one that reaches out into the world and one that decides what to do once it gets there. And yes, you can absolutely use both in the same agent; that’s not a compromise, it’s the normal shape of anything that does more than one kind of work.
