The short answer
MCP gives an agent hands: a standard way to call external tools and read external data. A skill gives it know-how: a folder of instructions, and optionally scripts, that tells the agent how to do a task well. They answer different questions, so in MCP vs skills the usual answer is “both.” That holds for Claude skills vs MCP servers in Claude Code, and for the same pair in Codex. Claude Code’s own documentation puts it the same way: MCP connects Claude to external services, while skills extend what Claude knows, including how to use those services.
Pick MCP when the agent needs access it does not have: a database, a browser, Slack, a SaaS API. Pick a skill when the agent already has access and keeps getting the procedure wrong, or when you keep pasting the same checklist into chat.
What MCP is
The Model Context Protocol is an open standard that Anthropic announced on November 25, 2024 for connecting AI assistants to the systems where data lives. A developer exposes tools and data through an MCP server, and an agent acts as the client.
In Claude Code you add a server with claude mcp add, and the MCP docs list the transports it supports:
- HTTP, recommended for remote servers.
- stdio, for local processes on your machine.
- SSE, which is deprecated.
- WebSocket, for servers that push events.
Servers can be scoped to a single project (stored in ~/.claude.json), shared with a team through .mcp.json in the repository, or enabled for all your projects. Remote servers that need sign-in use OAuth through the /mcp command.
Codex works the same way in spirit. Its MCP configuration lives in config.toml, where each server gets a [mcp_servers.<name>] table, and codex mcp add writes the entry for you. The server code runs either as a local process or at a URL, and it is code someone else wrote.
What a skill is
A skill is a directory with a SKILL.md file. The Agent Skills format, which Anthropic created and released as an open standard, requires a name and a description in the file’s frontmatter and allows scripts/, references/ and assets/ folders next to it. Claude Code adds its own extensions, such as invocation control and running a skill in a subagent, in its skills docs.
A skill is not a network service. The agent reads the file and follows it, and if the skill ships scripts, the agent can run them with whatever permissions you have given it.
Skills load in three steps: the agent sees each skill’s name and description at startup, reads the full SKILL.md when a task matches, and opens referenced files only when it needs them. That is why a hundred skills can sit on disk without filling the context window.
MCP vs skills at a glance
| MCP server | Skill | |
|---|---|---|
| What it provides | Tools and data access | Instructions, workflows, reference material |
| What it is on disk | A running process or a remote URL | A folder with SKILL.md |
| Standard | Model Context Protocol | Agent Skills (agentskills.io) |
| Needs a runtime | Yes, a server must start and stay connected | No, the agent reads files |
| Context cost | Tool names at start, full schemas on demand | Descriptions every turn, body when used |
| Can reach outside services | Yes, that is its job | Only through tools the agent already has |
| Setup | claude mcp add, OAuth or API keys | Copy a folder into a skills directory |
| Main security risk | Third-party code and prompt injection from fetched content | Instructions and bundled scripts you did not write |
| Portable across agents | Yes, any MCP client | Yes, any agent that reads the format |
| Typical failure | Server down, auth expired, tool output too large | Description too vague, so the skill never triggers |
Where they differ in practice
Capability versus procedure
An MCP server can do something the agent could not do before, like query a Postgres database or drive a browser. A skill cannot add a capability by itself. A “database migration” skill with no database access can only describe what to do.
The reverse also holds. An MCP server tells the agent which tools exist and what arguments they take, but not that your team never runs migrations on Fridays, or that column names follow a particular convention. That knowledge goes in a skill.
Context cost
The two load differently.
Claude Code puts skill descriptions in context on every request and loads the body only when the skill is used. Setting disable-model-invocation: true removes a skill’s description from context entirely and makes it run only when you type its name. For MCP, the features overview says Claude Code loads tool names and server instructions at session start and defers full schemas until a tool is needed, because tool search is on by default. You can run /context all to see how many tokens each loaded MCP tool uses.
An idle skill costs a description, and an idle MCP server costs tool names. A big skill body or a chatty tool result costs far more, but only when used. Claude Code warns when MCP tool output exceeds 10,000 tokens and caps it at 25,000 by default.
Determinism
Neither guarantees behavior. A skill is text the model interprets, and the docs say outcomes can vary. An MCP tool runs fixed code, but the model still decides whether to call it. If something must happen every time, such as blocking an edit to .env, the docs point to hooks instead.
Portability
Both travel between agents. Skills follow one folder format, though install paths differ: Claude Code reads ~/.claude/skills/ and .claude/skills/, while Codex reads .agents/skills and $HOME/.agents/skills. See our platform pages for each agent’s paths. MCP config also differs by client, as the .mcp.json and config.toml examples show, even though the protocol is shared.
What each can access, and what to check
Most comparisons skip this part, and it is why we review skills instead of just listing them.
An MCP server is a program. It can hold your tokens, make network calls and return text the model will read. The Claude Code docs warn to verify you trust each server, because servers that fetch external content can expose you to prompt injection. Project-scoped servers in .mcp.json ask for approval in interactive sessions, but not in claude -p runs or Agent SDK sessions, where they load without a prompt.
A skill looks harmless because it is Markdown, but it can do more than it seems. Its allowed-tools field pre-approves tools for the turn. That field does not restrict anything; it only skips the permission prompt. A skill can also run bundled scripts, install packages and change config files.
Our own data shows how often that happens. Across the 195 repositories in our index, 8 got “No issues found,” 123 got “Review before installing,” and 64 got “Broad access” under the rules on our methodology page. In our flags, 34 repositories pre-approve broad shell access, 94 run unpinned remote code, 69 modify user config and 12 install hooks. Those numbers describe skill packs, not MCP servers, and many packs ship both. See security for the full breakdown.
Two examples from the index:
- google-labs-code/stitch-skills is a set of skills built to work with the Stitch MCP server. We rated it “Broad access”: most of its skills pre-approve unrestricted
Bash, and its upload skill has the agent pull your Stitch API key from agent MCP config files after you confirm. - microsoft/azure-skills is a plugin that bundles skills with MCP server configuration for Azure. It is also “Broad access,” because its helper scripts run
az,azdandkubectlagainst your own subscription, and the README documents telemetry with an opt-out.
Both examples follow the same pattern: the skill supplies the procedure, the MCP server supplies the access, and the risk sits in the overlap.
Using skills and MCP together
The Claude Code docs list “Skill + MCP” as a standard pattern: the server provides the connection, and the skill teaches the agent to use it well. A database server plus a skill holding your schema and query patterns is the docs’ own example.
Codex supports this directly. A skill can declare MCP servers it depends on in an optional agents/openai.yaml, so the skill and its tools travel together. In Claude Code, a plugin can bundle skills and MCP servers as one installable unit, and its .mcp.json adds the server alongside the skill.
When building your own setup, start with a skill if the agent can already reach the system through the shell or a CLI. Add an MCP server when you need authenticated access, structured results or a service with no usable CLI. Write a skill on top of the server once you notice the agent misusing its tools.
When to use which
Use MCP when the data lives in another system and you keep copying it into chat, when the agent must act in that system, or when several agents and teammates should share one maintained connection.
Use a skill when you paste the same playbook into chat for the third time, when the knowledge is a convention, checklist or style guide, or when you want a /name command for a repeatable workflow.
Use both when the workflow touches an external system and has house rules. A release checklist that posts to Slack is the standard case.
Frequently asked questions
Can a skill replace an MCP server?
Sometimes. If a CLI already does the job, a skill that documents its commands can replace a server. If the system needs OAuth or structured tool schemas, a skill alone will not be enough.
Is MCP only for Claude?
No. It is an open protocol, and Codex has its own MCP setup. Skills are likewise an open format, with a client list on agentskills.io.
Which is safer?
Neither by default. An MCP server is running code with network access. A skill is text plus whatever scripts it carries. Read the files, check what a skill pre-approves, and look at our security notes before installing either. For a longer comparison with subagents, plugins and commands, see skills vs subagents.