AgentSkills.site

Agent Skills vs MCP

Every explanation of this says the same thing: MCP is access, skills are know-how. That's right, and it's not enough to decide anything. Here's the relationship as it appears in real artifacts — a Codex skill declaring an MCP dependency, an OpenClaw skill for driving MCP servers, n8n hooks firing on MCP tool names, and a v1.0 standard that ships both together.

Published

AgentSkills.site editorial

Skills and MCP are two layers of the same stack, not two options. MCP gives an agent access to a system. A skill gives it the judgement to use that access well. You will normally want both, and the interesting question isn't "which one" — it's how they compose.

That framing is not new, and the pages already ranking for this question mostly get it right. What's missing from them is evidence. This page argues it from artifacts you can open yourself, and covers the part almost nobody has picked up: as of 2026, there is a published standard whose entire job is packaging skills and MCP servers into one distributable unit.

Scope: this page is about the relationship between the two layers. It is not an MCP tutorial, and it is not a list of MCP servers worth installing — that's a different site's job.

The structural difference, stated once

Agent Skill MCP server
What it is A folder with a SKILL.md file, plus optional scripts, references, and assets A process or remote endpoint speaking the Model Context Protocol
What it provides Instructions: procedure, judgement, constraints, worked examples Tools: typed, schema-validated operations
Where it runs Inside the agent's own environment Its own process or a remote service
How the agent uses it Reads it, then acts Calls it
Cost when unused Name and description only Configuration and, usually, a connection
Portability The same file works across many agents The protocol is shared; per-client configuration is not
How you review it Read the text and any bundled scripts Decide what you're willing to connect it to

The last row is the one that gets least attention and matters most in practice. Reviewing a skill is a reading exercise. Reviewing an MCP server is an authorisation decision. Those are different jobs with different failure modes, which is a large part of why treating them as alternatives goes wrong.

Four artifacts that show the layering

None of this is analogy. These are files in public repositories and fields in published documentation.

A Codex skill declaring an MCP server as a dependency

Codex skills can carry an optional agents/openai.yaml. Among its blocks:

dependencies:
  tools:
    - type: "mcp"
      value: "openaiDeveloperDocs"

The skill declares that it needs an MCP server present. It doesn't contain the server, replace it, or wrap it — it depends on it. See Codex skills.

An OpenClaw skill whose entire job is driving MCP servers

OpenClaw ships a bundled skill called mcporter. Its frontmatter, read from the repository:

---
name: mcporter
description: "List, configure, authenticate, call, and inspect MCP servers/tools with mcporter over HTTP or stdio."
homepage: http://mcporter.dev
metadata:
  { "openclaw": { "requires": { "bins": ["mcporter"] } } }
---

This is the relationship in its most literal form: a skill that exists to teach the agent how to work with MCP. Note also the gating — the skill only appears when the mcporter binary is present, which is the skills layer managing its own relevance rather than the MCP layer doing anything. See OpenClaw skills.

n8n hooks that fire skill guidance immediately before MCP tool calls

The most precise demonstration we found. n8n publishes an official skills pack for coding agents, and its hooks/hooks.json registers PreToolUse hooks matched against MCP tool names:

{
  "PreToolUse": [
    { "matcher": "^mcp__.*__validate_workflow$", "hooks": [ ... ] },
    { "matcher": "^mcp__.*__create_workflow_from_code$", "hooks": [ ... ] },
    { "matcher": "^mcp__.*__update_workflow$", "hooks": [ ... ] },
    { "matcher": "^mcp__.*__get_node_types$", "hooks": [ ... ] }
  ]
}

The pattern is unambiguous: MCP exposes the capability, and the skills layer injects the relevant guidance at the moment the agent is about to use it. The pack's own router skill states the reasoning plainly — n8n evolves faster than any model's training cutoff, so the agent should trust the skills and the live MCP tools over recollection.

Access and judgement, wired together, in a shipping repository.

A Cursor plugin that is MCP and nothing else

Cursor's official marketplace repository contains this, in full, as the Gmail plugin's mcp.json:

{
  "mcpServers": {
    "gmail": { "type": "http", "url": "https://gmailmcp.googleapis.com/mcp/v1" }
  }
}

No skills/ directory. Meanwhile Cursor's first-party plugins — thermos, cursor-team-kit, agent-compatibility — carry skills/ and no MCP server. One packaging format, two independent payloads, and plenty of plugins carrying only one of them.

The part that's missing everywhere: Agent Plugins

If skills and MCP servers are complementary layers, something has to ship them together. As of 2026 that something is a published standard.

Agent Plugins (agent-plugins.org) describes itself as "an open, vendor-neutral standard for packaging reusable components that extend AI agents into distributable plugins. It defines a portable package format for Agent Skills and MCP servers." Specification 1.0.0 is the current published release, and the initial technical steering committee lists core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel.

The portable layout:

my-plugin/
├── plugin.json          # identifies the plugin and the spec version it targets
├── skills/
│   └── greet/
│       └── SKILL.md     # Agent Skills format
├── mcp.json             # stdio, Streamable HTTP, or legacy HTTP+SSE servers
└── com.example.client/  # reverse-domain namespaces for client-specific extras

Two details make the design argument for you.

Both component types are optional. The specification's own quick-start example is a plugin.json and a single skill, with no mcp.json at all. A plugin can be all skills, all MCP, or both. That is what a genuine layering looks like in a format — independent, composable pieces, not one wrapped in the other.

Client-specific behavior is quarantined. Reverse-domain namespaces let a client add its own extensions "without changing the portable core," which is the same instinct that keeps SKILL.md portable while Cursor adds paths and OpenClaw adds command-dispatch.

Adoption is real but worth stating precisely: Cursor's documentation confirms that "Agent Plugins use a root plugin.json manifest and load in Cursor without modification." We have not verified conformant support in other clients, and TSC membership is not the same as shipped support — so treat this as a standard with one confirmed loader we checked, not a universal one.

The related pattern is visible elsewhere too. Claude Code documents that a skill folder with a .claude-plugin/plugin.json "loads as a plugin … so it can bundle agents, hooks, and MCP servers." Same idea, house format.

So when do you reach for which?

Given the above, "skills or MCP" is usually the wrong question. The useful ones:

Does the agent need to do something it currently can't reach? That's MCP. Query a database, call an API, read a SaaS system, act on live state with real auth. No amount of instruction gets an agent into a system it has no connection to.

Does the agent already have the access but keeps doing the job badly? That's a skill. It calls the right tool with the wrong parameters, skips validation, doesn't know your conventions, or reinvents a decision it should have inherited. That is a knowledge problem, and connecting another server won't fix it.

Both, usually. The n8n pack is the clean illustration: an MCP server exposing workflow operations, and a skills pack that makes an agent use them competently. Either half alone underperforms.

Two follow-on consequences worth planning around:

  • Portability. A SKILL.md written to the portable spec — name, description, optionally license, compatibility, metadata — runs across a long list of agents unchanged. Cursor even reads Claude Code's and Codex's skill directories directly. There is no equivalent for MCP server configuration, and a skill that assumes a particular server is present is only as portable as that server.
  • Review burden. A skill is text you can read in ten minutes; that's also its weakness, since a convincing paragraph is exactly what prompt injection looks like and no scanner catches prose reliably. ClawHub's audit framing names the whole class — "prompt injection, tool misuse, credential exposure, unsafe execution, memory or context poisoning, and excessive agency" — using the OWASP Agentic Skills Top 10 as its lens. An MCP server is the opposite: less prose to read, but a credential and a network boundary to decide about. See are OpenClaw skills safe? for how one registry handles the first half.

The one-line version

MCP decides what an agent can do. Skills decide what it should do, and how. Agent Plugins is how you hand someone both at once.

Caveats

  • We have not run any MCP server, installed any plugin, or used any of the skills referenced here. Every claim is documented behavior or read directly from a public repository, and the source is named in each case.
  • Agent Plugins 1.0.0 support is confirmed for Cursor from Cursor's own documentation. We did not verify conformant support in other clients, despite the breadth of the steering committee.
  • The n8n hook matchers are read from n8n-io/skills. That ecosystem's full treatment isn't published on this site yet; the file is cited here as evidence, not as a guide to using it.
  • The security and portability comparisons are our synthesis of separately documented facts, not vendor guidance.
  • Specification version, repository details, and documentation quoted here are current as of 16 August 2026.

Sources

Where these artifacts are documented in full