Agent Skills vs MCP Servers: Stop Treating Them as Alternatives

Every team that has spent a few months building agents on Claude eventually asks a version of the same question: should this be an Agent Skill or an MCP server? It gets framed as a fork in the road, and teams spend real time debating it as though picking wrong means rebuilding.

The framing is wrong. MCP servers and Skills are not competing answers to one question. They are answers to two different questions, and the confusion is expensive because the two mechanisms load into the context window on completely different terms. One is charged to you on every single request whether you use it or not. The other is not.

This post covers what each mechanism actually gives you, the loading model that separates them, why adding a single MCP server can invalidate your entire prompt cache, how tool search and deferred loading change that math, and a decision rule that holds up in production. If you have already read our post on choosing between MCP and the CLI, this is the layer above it.

What an MCP Server Actually Gives You

The Model Context Protocol is an open standard for connecting models to external tools and data through a common interface. An MCP server is a running program that exposes capabilities the model could not otherwise reach: your Linear workspace, a Postgres database, a Sentry project, an internal service behind your VPC.

The key word is reach. MCP solves a connectivity problem. It gives the model typed, schema defined tools with real inputs and outputs, and it gives you a place to enforce a permission policy, so a tool that writes data or spends money can be marked to require human approval before it runs while lower risk tools run automatically.

What MCP does not give you is judgment. Connecting a Linear server tells Claude that it can create an issue. It says nothing about how your team writes issues, which fields are mandatory, what your triage conventions are, or when creating an issue is the wrong move.

What an Agent Skill Actually Gives You

An Agent Skill is a folder containing a SKILL.md file and, optionally, scripts and reference material. It is procedural knowledge, packaged: how to do a specific kind of work, the way your organisation does it.

A Skill is where the judgment lives. It is the difference between a model that can technically create an issue and a model that creates the issue your team would have created. It carries the conventions, the checklists, the house style, the edge cases you learned the hard way, and the scripts that encode a repeatable process.

So the two are complementary in the most literal sense. MCP is the hand. The Skill is the training. A team that connects five MCP servers and writes no Skills has an agent with excellent reach and no taste, which in practice means an agent that does the wrong thing efficiently.

The Real Difference Is When Each One Loads

This is the part that decides your bill, and it is where the two mechanisms genuinely diverge.

Tool definitions load eagerly. Every tool you declare, including every tool exposed by every connected MCP server, is rendered into the request before anything else. The order is fixed: tools first, then the system prompt, then the conversation. Those schemas sit in the context window on every single request, whether Claude touches them or not.

Skills load progressively. A Skill's description sits in context so Claude knows the Skill exists, but the body of the SKILL.md file is only read when the task actually calls for it. The full procedure, the checklists, the reference material, all of it stays out of the way until it is relevant.

That asymmetry is the whole story. Ten MCP servers with a dozen tools each means one hundred and twenty tool schemas rendered into the front of every request for the entire life of the session. Ten Skills means ten descriptions, with the substance pulled in on demand. This is why teams that instrument their token usage tend to converge on the same shape: a small, deliberate set of MCP servers, and a much larger library of Skills.

Why One New MCP Server Can Invalidate Your Whole Cache

The loading order has a second consequence that is easy to miss and expensive to learn.

Prompt caching on the Claude API is a strict prefix match. The cache key is derived from the exact bytes of the rendered prompt, and a single byte of difference anywhere in that prefix invalidates every cached token that comes after it. Because tools render first, at the very front of the prefix, adding, removing, or reordering a single tool invalidates not just the tool definitions but the system prompt cache and the entire conversation cache behind them.

The economics make that hurt. A cache read costs roughly a tenth of a normal input token. A cache write costs about 1.25 times a normal token on the default five minute TTL, and about twice on the one hour TTL. So a stable tool surface is close to free to carry across a long session, while a tool surface that changes between requests keeps paying the write premium over and over, on the full prefix, every time it shifts.

It is worth knowing precisely which changes cost you what. Changing the tool definitions or switching the model rebuilds everything. But changing tool_choice, or toggling thinking on and off, only invalidates the message level cache and leaves your tools and system prompt cached. Teams often over engineer around the second category while casually doing the first.

The practical rule that falls out of this: do not swap MCP servers per task or per user if you can avoid it. A per user tool set means no two users ever share a cached prefix, and you pay full price on the front of every request forever.

Tool Search and Deferred Loading Fix the Eager Load Problem

Anthropic addressed the eager loading cost directly with the tool search tool. You mark tools with defer_loading, and their full schemas are not rendered into context until Claude actually searches for and finds them.

The detail that makes this genuinely useful, rather than just a different way to pay, is that discovered tool schemas are appended to the request rather than swapped in. Appending does not disturb the existing prefix, so the cache survives. This is the one sanctioned way to have a large, dynamic tool surface without torching your cache on every change.

Two constraints to know before you turn it on. The search tool itself must not be deferred, and at least one tool in your request must remain non deferred. Defer everything and the API returns a 400 telling you exactly that.

There is also a quiet safeguard worth knowing about: if an MCP tool call returns more than 100,000 tokens, the result is automatically offloaded to a file rather than dumped into the conversation, and Claude receives a preview plus the file path. That this safeguard needs to exist tells you how easily an unmanaged MCP integration can flood a context window.

Code Execution Changes the Token Math Again

There is a third option that most teams have not reached for yet, and it changes the arithmetic more than either of the above.

With standard tool use, every call is a round trip. Claude calls the tool, the entire result lands in Claude's context, Claude reasons about it, then calls the next tool. Three sequential lookups means three round trips, and the intermediate data, most of which is never needed again, sits in the context window permanently paying rent.

Programmatic tool calling inverts this. Claude writes a script that calls the tools as functions. The script runs in the code execution container, and when it calls a tool the result returns to the running code, not to Claude's context. The script filters, loops, and branches over that data with ordinary control flow, and only the final output comes back to the model.

The consequence is that token cost scales with the size of your final answer rather than the size of everything you had to read to produce it. For any workflow that fans out across many calls or pulls large intermediate payloads, this is the difference between an agent that is viable and one that is not. Anthropic's engineering team wrote this up in detail in code execution with MCP, and it is the piece of the picture most teams are still missing.

A Decision Rule That Holds Up

• Reach for an MCP server when the model needs to touch a system it cannot otherwise reach, or when an action needs typed inputs and a human approval gate before it runs. Pin one server per external system and resist the urge to add more.
• Reach for a Skill when the model can already technically do the thing but keeps doing it the wrong way. Skills encode judgment, conventions, and process, and they cost you almost nothing until they are used.
• Reach for the CLI first when the capability already exists as a command line tool and the tool set will stay stable for the session. That argument is unchanged and covered in our MCP or CLI post.
• Turn on tool search with defer_loading before your connected tool count grows past what any single task needs, not after your bill tells you to.
• Reach for code execution when the agent is making many calls or handling large intermediate results that Claude does not need to see.

The Failure Mode Is Almost Always the Same

In practice, the teams that struggle here are not the ones who picked wrong between MCP and Skills. They are the ones who never separated the two questions in the first place. They connect servers to solve a behaviour problem, which does not work, because no amount of connectivity teaches an agent your conventions. Then they write documentation to solve a reach problem, which also does not work, because no amount of instruction gives an agent access to a system it cannot call.

Ask the diagnostic question before you build anything. Is the agent failing because it cannot reach something, or because it does not know how you want the work done? The first is an MCP problem. The second is a Skill problem. They are almost never the same problem, and the fix for one will not touch the other.

The same discipline we apply to prompt systems applies here, and it is the reason we push teams to design the workflow before selecting the tooling, exactly as covered in our post on building AI systems rather than one off prompts.

If your team is working through agent architecture, tool surface design, or the token economics of a system that is starting to get expensive, our AI training and consulting service works through precisely these tradeoffs with teams building on Claude. You can see how we approach this kind of work at Growthtrait, or contact us if you want a second opinion on your setup.