MCP vs Agent Skills: what each does and when to use both

MCP and Agent Skills are not competing standards, so the choice is rarely one or the other. MCP is a protocol for connecting an agent to systems it cannot otherwise reach: its documentation calls it "an open-source standard for connecting AI applications to external systems", and an MCP server exposes tools, resources and prompts the agent can call. Agent Skills is a file format for instructions: a directory with a SKILL.md file that tells the agent how to carry out a task. If you need live data or an action against a real system, you need MCP. If the agent has the access it needs but keeps doing the work badly, you need a skill. Most real extensions end up using both, and since SEP-2640 reached Final status one MCP server can serve skills as well as tools.

#What is the actual difference?

	MCP	Agent Skills
What it is	A protocol: "an open-source standard for connecting AI applications to external systems"	A file format: a directory containing, at minimum, a SKILL.md file
What it exposes	Tools ("executable functions that AI applications can invoke"), resources ("data sources that provide contextual information") and prompts ("reusable templates")	Markdown instructions, plus optional scripts/, references/ and assets/ directories
How it reaches the agent	A running server the host connects to over stdio or Streamable HTTP, speaking JSON-RPC 2.0	Files the host discovers and loads into the model's context
What runs	A program, local or remote, that the host calls during the conversation	Nothing by itself. The host reads the files; any scripts/ run only if the host runs them
Required metadata	Server identity and capabilities, advertised through server/discover	name (max 64 characters, lowercase letters, numbers and hyphens) and description (max 1024 characters)
How much context it costs	Tool and resource listings are fetched and cacheable, with a ttlMs freshness hint	Progressive: around 100 tokens of metadata at startup, the body on activation, supporting files on demand
Where the spec lives	modelcontextprotocol.io, revision 2026-07-28	agentskills.io/specification
What it cannot do alone	Tell the agent how or when to use what it exposes	Reach anything. A skill fetches nothing by itself

The row that matters most is the last one. A tool list is a menu with no recipe, and a skill is a recipe with no ingredients.

#What does MCP give you that a skill cannot?

An MCP server runs. That is the whole difference. The architecture documentation describes three primitives a server can expose: tools, which are "executable functions that AI applications can invoke to perform actions (e.g., file operations, API calls, database queries)"; resources, which are "data sources that provide contextual information to AI applications (e.g., file contents, database records, API responses)"; and prompts, which are "reusable templates that help structure interactions with language models".

Because the server is a program, it can hold credentials, enforce its own authorisation, and answer differently every time it is called. The protocol's transport layer supports stdio for local processes and Streamable HTTP for remote servers, with "standard HTTP authentication methods including bearer tokens, API keys, and custom headers", and the documentation says "MCP recommends using OAuth to obtain authentication tokens". None of that has an equivalent in a file format. If the answer your agent needs did not exist when the files were written, a skill cannot produce it.

For a fuller tour of the protocol itself, see what MCP is.

#What does a skill give you that an MCP server cannot?

A skill is read, not called, and that is its advantage. Its structure is deliberately plain: a directory whose SKILL.md carries YAML frontmatter with name and description, followed by a Markdown body with "no format restrictions", plus optional scripts/ for executable code, references/ for documentation the agent reads on demand, and assets/ for templates and data files.

The loading model is the part people underuse. The specification describes it as progressive disclosure in three stages: metadata, around 100 tokens, where "the name and description fields are loaded at startup for all skills"; instructions, with under 5,000 tokens recommended, where "the full SKILL.md body is loaded when the skill is activated"; and resources, loaded "only when required". It advises keeping the main SKILL.md under 500 lines and moving detail into separate files. A hundred skills can therefore sit in front of an agent for the cost of a hundred descriptions, which is not something a hundred MCP servers can claim.

The format is also portable in a way a server integration is not. Microsoft's own documentation for Copilot Cowork says its skills "use the Agent Skills open standard", naming it as "the same format supported by Claude Code, Visual Studio Code Copilot, Gemini CLI, Cursor, JetBrains Junie, and 30+ other AI tools". Our guide to where each agent looks for skills covers the paths, and what a SKILL.md file is covers the format in detail.

#How do you use both in one package?

Microsoft 365 Copilot Cowork is the clearest published example of the two standards side by side, because its plugin format names them separately. Its documentation lists two kinds of extension: "Skills: Prompt-based workflows that teach Cowork new domain expertise, such as financial analysis, legal research, or HR workflows" and "Connectors: Remote servers that give Cowork access to external data sources and APIs". A plugin package holds a skills/ folder of SKILL.md files registered in agentSkills[], and connector entries in agentConnectors[], where a remote connector is configured as a remoteMcpServer with an mcpServerUrl.

Microsoft also states the decision rule plainly, and it is the same rule this article arrives at: "If your extension needs access to external data, add a remote MCP server. This step is optional. Skills-only packages work well for prompt-based workflows."

One detail from the same page is worth copying into your own design: Cowork "discovers tools dynamically from your MCP server" rather than reading a packaged tool-description file, even when that file is present. The server is the live source of what it can do; the skill is the standing instruction for how to use it.

A note on the name, because it has caught people out. Microsoft 365 Copilot Cowork is Microsoft's product. Anthropic's Claude apps also have a Cowork, which Claude Code's permissions documentation refers to as "a Cowork session in the Claude Desktop app". They are different products from different vendors that share a word, so check which one a page is about before you follow its instructions.

#What is Skills over MCP (SEP-2640)?

The Skills extension is how a skill travels over the protocol rather than over your filesystem. Its identifier is io.modelcontextprotocol/skills, and the MCP documentation says the extension "allows MCP servers to expose workflow instructions and supporting files to clients", with clients able to "discover available skills, retrieve their metadata, and read their contents using the existing Resources primitive". The stated reason to use it is that "serving them over MCP keeps those instructions with the service they describe".

The mechanics, in the specification's own terms:

• A server "MUST declare both the resources capability and the io.modelcontextprotocol/skills extension" in its server/discover response, and servers that declare it "MUST implement skills/list and skills/get". Skill files are served through resources/read.
• A listing entry carries the skill's URI, all of its YAML frontmatter unchanged, and a complete file manifest. That manifest "MUST include SKILL.md and every supporting file, with each file's URI, SHA-256 digest, and byte size". Generated content that has no stable digests uses "resources": "dynamic" instead, and "hosts MAY decline these skills".
• Reading the file is not the same as using it. "Reading SKILL.md through resources/read does not itself activate a skill." The host routes the read through its own skill-loading path, which verifies the content and applies any approval first.
• Hosts must verify what they get: restrict reads to URIs in the retained manifest, "verify each file's raw byte size and SHA-256 digest before use", and compare the frontmatter "field-by-field" with the entry. Content that fails verification must not be used.
• Approval is bound to content, not to a name. "Persisted approval MUST bind to the complete set of file URIs and digests. A changed, added, or removed file revokes that approval", and the host must ask again.
• Servers "SHOULD NOT exceed 512 files or 16 MiB per skill", and hosts must support at least that much.

The security requirements are the part to read twice if you are about to serve skills to other people's agents. Hosts must "treat skill content as untrusted input", must prevent same-named skills from "silently replacing one another", must tag loaded content with its originating server, and must require "explicit per-call approval naming both servers" for a cross-server read. If you install skills from anywhere, our skill security audit walks through reading one before you trust it.

#Which hosts actually support it?

Thinly, and the documentation says so: "SDK and host support is still being implemented". The extension support matrix on modelcontextprotocol.io has a Skills column with four entries. ChatGPT, fast-agent and the MCP Inspector are marked Partial; the mcpc MCP CLI is marked as supported. Every other client listed in that matrix, including Claude on web and desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Cursor, Goose, Postman, MCPJam, Archestra.AI and PostHog Code, has no entry in the Skills column at all, although most of them do support MCP Apps. The page notes that "This list is maintained by the community", so read it as a community record rather than a vendor commitment.

ChatGPT is the one mainstream product in that list, and its own documentation is specific about how narrow the support is. OpenAI says it "currently supports a bounded, static subset of the draft SEP-2640 Skills extension", that imports come in at submission time, and that "Skills imported from MCP are submission-time snapshots, not live runtime resources". The importer "accepts up to five uniquely named skills across 10 catalog pages", each skill may hold up to 100 files, and the size caps are 256 KiB for SKILL.md, 1 MiB per supporting file, 5 MiB of resources per skill and 8 MiB of generated archives per scan. OpenAI also notes it "does not recognize the earlier experimental declaration", so a server declaring the extension the old way is simply not seen.

Two sources disagree on the extension's status, and the disagreement is worth knowing about rather than smoothing over. The MCP project's own pages say SEP-2640 is Final: the SEP page carries a Final badge with Status: Final in its metadata table, and the Skills overview states "SEP-2640 is Final". OpenAI's page, read on 14 October 2026, describes it as "the draft SEP-2640 Skills extension" and says "This proposal is not yet part of the stable MCP specification". This article follows the MCP project, which is the body that decides the status of its own proposals. The practical reading is that OpenAI's page has not been updated since finalisation, and that its implementation targets the earlier draft, which is also why its support is a subset.

#Which should you reach for first?

Work from the failure you actually have.

1. The agent cannot see or do something. That is MCP. No amount of instruction will let a file read your issue tracker.
2. The agent can reach everything and still produces the wrong shape of work. That is a skill. Write the workflow down, name the tools it should use, and put the long reference material in references/ so it loads only when needed.
3. Both. Ship the server for access and the skill for method. If your host supports Skills over MCP you can serve both from one place; if it does not, the skill goes wherever that host looks for skills, and nothing is lost.
4. You are publishing for other people's agents. Prefer the skill for anything that is instructions, because the format is read by many more hosts than the Skills extension is. Then decide whether the extension buys you central distribution worth the narrow support.

Validate before you ship either one. The Agent Skills reference library checks a skill's frontmatter and naming with skills-ref validate ./my-skill, and the MCP Inspector's CLI is one of the three partial Skills implementations, which makes it a reasonable way to see what a client gets back from your server.

For the equivalent choice inside one product rather than across standards, our comparison of skills, subagents, plugins and MCP servers in Claude Code covers how a single host frames it.

#What this comparison does not settle

Three things we could not establish from the sources we read, and did not guess at.

The date SEP-2640 reached Final is not stated on the SEP page, the Skills overview or the specification changelog. The SEP page records Created: 2026-04-23 and a Final status, with no finalisation date, and the protocol changelog covers revision 2026-07-28 rather than extensions, which "evolve independently of the core protocol".

Whether any host beyond the four in the matrix has shipped support is not something the matrix can answer, since it is community-maintained and an absent entry means no one has filed one, not that support is absent.

How the partial implementations differ from each other is documented per client rather than centrally, and we read only OpenAI's. The matrix links implementation notes for fast-agent and the MCP Inspector, and those are the pages to check before assuming a behaviour is shared.