Agent Plugins vs Agent Skills vs MCP Servers: What's the Difference?

The agent ecosystem keeps producing new formats, and the names blur together: Agent Skills, MCP servers, Agent Plugins. Are they competing? Complementary? Here's a clear mental model.

The short version

• MCP servers are a protocol for agents to call external tools and data — a wire format and lifecycle contract.
• Agent Skills are a file format for packaging instructions, scripts, and reference material an agent can use.
• Agent Plugins are a packaging standard that bundles skills and MCP servers into one distributable unit.

They sit at different layers. An Agent Plugin is not a third component type — it's the box that carries the other two.

MCP servers: capabilities over the wire

The Model Context Protocol defines how an agent connects to a server that exposes tools, resources, and prompts. It answers: how does the agent talk to this capability?

• Transport: stdio, Streamable HTTP, legacy HTTP+SSE.
• Best for: live external capabilities — databases, APIs, browser automation, anything with runtime state.
• Cost: you run the server, or connect to a hosted one.

MCP is about connection, not distribution. It says nothing about how a server is packaged, advertised, or installed.

Agent Skills: instructions and files

An Agent Skill (per the Agent Skills specification) is a directory with a SKILL.md file — frontmatter metadata plus markdown instructions — and optional scripts/, references/, and assets/ folders.

• Best for: procedural knowledge the agent should follow — workflows, guidelines, prompts, small scripts.
• No runtime server needed; the agent executes the instructions itself.
• Distribution was the pain point: every client had its own way to discover and install skills.

Agent Plugins: the portable package

Agent Plugins (v1.0.0) defines the package format: a plugin.json manifest plus fixed component locations — skills/ for Agent Skills and mcp.json for MCP servers, with reverse-domain directories for client extensions.

• Best for: distributing a coherent toolset — "this plugin gives your agent summarizing skills and a search server."
• One layout that every conforming client can load; no per-client repackaging.
• Backed by a steering committee including Amazon, Cursor, Microsoft, OpenAI, and Vercel.

When to use which

You want to...	Use
Give the agent step-by-step know-how	Agent Skill (or a skill inside a plugin)
Connect the agent to a live service	MCP server
Ship a ready-made capability bundle to many clients	Agent Plugin
Share a standalone skill with a specific client	That client's native format, but prefer a plugin for portability

The practical pattern: author components as skills and MCP servers, distribute them as Agent Plugins.

Why this matters now

Fragmentation was the norm: a plugin packaged for one client needed adaptation before another could use it. Agent Plugins establishes a small interoperability floor — shared components use one predictable structure, while distribution, permissions, and client-specific features stay under each client's control.

The ecosystem is moving fast: the specification is open and developed in public, proposals start as GitHub Discussions, and thousands of repositories already reference the official schema. Directories like AIMCP's Agent Plugins directory validate entries against the official JSON schema, summarize them in multiple languages, and link back to source — making discovery as standardized as packaging.

Bottom line

MCP is the protocol, Skills are the content, Plugins are the package. If you're building agent components today, the highest-leverage move is to write them once as skills and MCP servers, ship them as an Agent Plugin, and let every compatible client load them as-is.