Agent Skills vs MCP vs AGENTS.md: What's the Difference?

Quick answer
AGENTS.md is always-on context: rules and conventions the agent reads at the start of a session.
An Agent Skill is on-demand procedure: a SKILL.md the agent loads only when a task matches its description.
MCP is a protocol that gives the agent tools and data through a server process, with credentials and network access.
Confusing them produces two common failures: a huge AGENTS.md that nobody maintains, and a skill that tries to do what an MCP tool should.
Use AGENTS.md for constraints, skills for repeatable procedures, and MCP for capabilities the agent does not have.

What is the difference between AGENTS.md, Agent Skills, and MCP?

The three sit at different layers. AGENTS.md is a file of standing instructions that the agent reads before it starts work: build commands, conventions, things never to touch. A skill is a procedure the agent loads when a specific kind of task appears. MCP is an interface to external tools and data, usually running as a separate process.

Put another way: AGENTS.md says how we work here, a skill says how to do this one job, and MCP says what the agent is allowed to reach. A repository can use all three, and most mature ones do.

| Question                | AGENTS.md                  | Agent Skill                | MCP server                     |
|-------------------------|----------------------------|----------------------------|--------------------------------|
| Loaded when             | Start of every session     | Task matches description   | On connect                     |
| Written in              | Markdown                   | Markdown + optional files  | Code (JSON-RPC server)         |
| Gives the agent         | Rules and conventions      | A procedure                | Tools, resources, prompts      |
| Uses credentials        | No                         | Inherits the session's     | Yes, its own or the session's  |
| Typical bloat failure   | Grows until ignored        | Descriptions overlap       | Over-broad tool scopes         |
| Review as               | Documentation              | Code-ish instructions      | Network service                |

When should a rule go in AGENTS.md instead of a skill?

If the rule must apply to every task, put it in AGENTS.md: the test command, the package manager, the directories that are generated and must not be edited. If the rule only applies when doing one kind of work, put it in a skill, because loading it every session wastes context and dilutes attention.

The failure mode is a 900-line AGENTS.md that restates the entire style guide. Long instruction files get skimmed, and instructions buried in the middle are followed less reliably than a short file with the rules that matter.

When do you need an MCP server rather than a skill?

When the agent needs a capability it does not have: querying a production read replica, creating a ticket, reading a design file, calling an internal API. A skill cannot invent a tool; it can only describe how to use one that exists.

The reverse mistake is also common: wrapping a shell command in an MCP server when the agent already has a terminal. That adds a process, credentials, and an attack surface for no new capability. Prefer the smallest mechanism that provides the capability.

How do the three interact in practice?

A typical setup has a short AGENTS.md that names the build and test commands and the files not to edit, two or three project skills for procedures like releases and migrations, and one MCP server for the issue tracker. The agent reads the rules, loads a skill when the task matches, and calls the tracker through MCP.

Governance follows the same split: AGENTS.md and skills are reviewed in pull requests like code, while an MCP server is reviewed like a service, with its scopes, credentials, and network reach documented.

Where this bites vibecoders
An assistant asked to set up agent configuration will often produce all three at once: a 400-line AGENTS.md, five overlapping skills, and an MCP server for something the terminal already does. Start with the smallest set, and add a layer only when a specific task keeps failing without it.

Where AI coding assistants get this wrong

Putting task-specific procedures in AGENTS.md so they load on every request.
Writing a skill that describes calling a tool the agent does not have.
Standing up an MCP server to wrap a command the shell already provides.
Letting AGENTS.md grow into an unfocused document nobody reads to the end.
Giving an MCP server broader credentials than the tasks it supports.
Assuming a skill and AGENTS.md are interchangeable because both are markdown.

Checklist

List the rules that apply to every task and keep them in AGENTS.md.
Move any procedure longer than a few lines into its own skill.
Check whether the capability already exists before adding MCP.
Keep skill descriptions distinct so triggering is unambiguous.
Review all three in pull requests, not in a chat thread.
Delete any layer that no longer earns its context cost.

FAQ

Can a skill replace AGENTS.md?

Not for rules that must always apply. A skill loads only when its description matches, so a constraint placed in a skill can be missed entirely. Keep non-negotiable rules in AGENTS.md and use skills for procedures that apply to some tasks and not others.

Does MCP replace skills?

No. MCP provides tools and data; a skill describes how to use them well. A team can have an MCP server for its issue tracker and still need a skill that explains which labels to apply and how to write the ticket body.

Which one should I write first?

Start with a short AGENTS.md, because every session benefits from accurate build and test commands. Add a skill the second time you explain the same procedure to the agent. Add MCP only when the agent needs data or actions it cannot get from the shell.

Are all three now governed by the same foundation?

Agent Skills, AGENTS.md and MCP are all hosted by the Agentic AI Foundation under the Linux Foundation as of late 2026. They remain separate specifications with separate maintainers, but the governance is now vendor-neutral rather than owned by one tool vendor.