MCP is useful, but most of the time you do not actually need it. It gives an agent a clean way to discover tools, call APIs, and work with external systems. In practice, a skill file can describe the same usage path without dragging the whole MCP surface into context.

But MCP is not free; rather than MCP itself, the real issue is the habit of loading a big MCP surface into every session, no matter what the session is actually about. Once a Claude Code or Codex run pulls in a bunch of servers, the model sees those tool definitions right away, even if the job is just writing docs or fixing a small bug. That is where the waste starts.

The hidden cost of always-on MCP

Every MCP server brings metadata with it: tool names, descriptions, argument schemas, nested parameters, enums, examples, and sometimes prompts or resources. While useful, this is still context.

If you connect a handful of lightweight tools, the overhead is annoying but manageable. If you connect a real stack of services, the cost compounds fast.

In practice, you end up paying for:

• tool discovery before the task starts
• schema text the model may never use
• repeated loading across unrelated sessions
• extra context pressure that pushes out the actual work

That last point matters more than people think. Context acts as the active working set the model uses to reason. The more of it you burn on static tool catalogs, the less room you have for the user request, the repo state, prior reasoning, and the actual answer.

Anthropic has already written about this problem directly in the context of MCP. Their engineering post on code execution with MCP calls out tool-definition bloat and shows how direct tool calls can consume a lot of context before the model even starts doing the real job. The tool list is not just setup noise; it is part of the session cost.

Why skills are cheaper

Skills take a different path. A skill file keeps the always-loaded portion tiny. Usually that means just the skill name and a short description in the frontmatter. The detailed instructions stay in SKILL.md and only load when the model actually needs them. This progressive disclosure is the whole trick:

1. The model sees a lightweight skill name and description up front.
2. If the task matches, it loads the skill file.
3. If the skill needs supporting files, those are read only when needed.

For repeated operational knowledge, that is a much better tradeoff than dumping a full MCP tool surface into every session. You get the guidance when it matters, and you do not spend tokens on it when it does not.

This is why skills are a better default for:

• team-specific procedures
• prompt templates
• review checklists
• internal conventions
• reusable task instructions
• “how we do this here” knowledge

They are not trying to be live integrations. They are trying to be cheap, reusable context.

Skills can replace the MCP layer

Skills are for instructions, decision-making, and the actual usage pattern, while MCP is usually just extra protocol surface. In practice, that means skills can replace MCP for the part humans actually interact with. The model does not need a full tool catalog in context just to know how to use a service.

If the agent needs to use a database, hit a SaaS API, or make authenticated requests in real time, the skill can still describe the flow clearly and keep the model on the narrow path it needs.

If the agent just needs to know how your team wants it to behave, a skill is the better shape. Most of the time, that is the whole job.

The mistake is to keep a heavy protocol layer around when a skill file can do the same job with far less context.

A simple rule

Use skills by default.

Treat MCP as optional, not foundational.

That sounds obvious, but a lot of agent setups blur the line. They stuff every possible tool into every session, then wonder why the model gets slower, more expensive, and harder to steer.

What this looks like in practice

If you have a service that exposes 40 or 50 MCP tools, it might be fine for a developer who uses it every day. But most sessions do not need all 50 tools. A lot of the time, the agent just needs one narrow procedure, such as looking up a user, updating a record, creating a ticket, or formatting a request safely.

The skill can tell the model exactly how to handle the task, what fields matter, what not to do, and which edge cases to watch for. The model does not need a giant always-on MCP tool catalog to do that well.

That is the real token saving. You stop paying for the full runtime surface when all you needed was the operating playbook.

How to convert MCP into a skill

If you have an MCP server that mostly behaves like a reusable API wrapper, you should turn the useful parts into a skill.

The easiest way to inspect what you actually need is to use MCPViewer tool.

Here is the workflow:

1. Open the MCPViewer tool.
2. Paste the MCP server URL.
3. Click Analyze.
4. Scroll down and click Download spec.
5. Copy the downloaded JSON.
6. Paste it into a SKILL.md file as the skill’s content reference.
7. Set the skill description to something like How to use APIs for <service name> service.

This flow extracts the useful service knowledge into a lighter, reusable skill that the model can load only when needed, rather than trying to preserve every tool forever.

If the service changes often, keep the skill narrow and update it when the API changes. If the service is stable, the skill becomes a better long-term home for the instructions than the full MCP surface.

A good pattern for teams

For most teams, the best setup is skills everywhere, using skill files for the things that must be remembered:

• how to format requests
• how to review output
• team conventions
• approval rules
• safe operating procedures

If a service still needs live execution, the skill can describe that path without dragging its whole protocol surface into every session. This keeps the agent lean and makes the system easier to maintain, because procedural knowledge is no longer spread across a large tool registry.

It is also easier to reason about failure. If the skill is wrong, you update instructions. If you need to change how a service is used, you update the skill. Those are different jobs, and it helps to keep them separate.

The real goal: less context waste

The problem is not just token cost in the billing sense. It is context waste. Every extra tool definition you stuff into a session is one more thing the model has to carry around while solving the actual task.

Skills let you defer that cost until the model really needs the information. They are a good fit for repeated workflows, company knowledge, and reusable operating rules.

If MCP is the transport, skills are the memory.

Related reading

• How to Use Claude Code with a Team: Shared Context, Permissions, and MCP
• The Complete Guide to Claude Code: Setup, Skills, Hooks, and the Agent Loop
• Why Your AI Agent Should Never See Your API Keys

FAQ

Is MCP bad?

MCP is not the main problem. The problem is loading it into sessions that do not need it when a skill file would do the job with far less context.

Do skills replace MCP?

Yes, for most practical cases. If the goal is to teach the agent how to use a service, a skill can replace MCP and keep the context much smaller.

Why do skills save tokens?

Because the always-loaded part is small, the model sees the skill name and description first, then loads the full SKILL.md only when the skill is relevant.

What kind of content belongs in a skill?

Reusable instructions, procedures, checklists, formatting rules, and team-specific guidance. If the content is mostly about how to behave, it belongs in a skill.

What kind of content belongs in MCP?

Very little, unless you have a special case, as the same operational knowledge usually fits better in a skill.

Can I keep both MCP and skills for the same service?

Yes. That is often the best setup. MCP handles the runtime connection. The skill handles the playbook for using it well.

Why use mcpview.teamcopilot.ai?

Because it lets you inspect the actual MCP surface before you decide what should stay as MCP and what should become a lighter skill. That makes the conversion less guessy.

What if the MCP spec changes?

Update the skill the same way you would update any other documentation or wrapper. If the API changes often, keep the skill narrow so maintenance stays easy.

What is the best short description for a converted skill?

Something specific and boring, such as How to use APIs for <service name> service. This pattern tells the model exactly what the skill is for without wasting words.