What is Agent Plugins, and how is it different from MCP and Agent Skills?

The shortest distinction

MCP defines how an agent talks to an external tool or service. Agent Skills defines reusable instructions and resources an agent loads on demand. Both were already portable on their own. What was not portable was the package around them, and every client had invented its own.

Agent Plugins fills exactly that gap and nothing more. It is a directory layout plus a manifest plus a set of discovery and failure rules. The specification does not redefine SKILL.md and does not redefine MCP wire behaviour; it points at the Agent Skills specification and the Model Context Protocol specification as the sources of truth for those.

If you have been building agent tooling and wondering whether this obsoletes what you already wrote, it does not. A working skill and a working MCP server stay exactly as they are. What changes is where they sit relative to each other on disk.

What is actually in the package

A plugin is one directory. At its root sits plugin.json, which is the only required file. Skills live in a skills/ folder, one immediate subdirectory each, every one containing a SKILL.md. MCP servers are declared in a single mcp.json at the root. A reverse-domain directory such as com.github.copilot holds client-specific files that other clients ignore.

The manifest schema is closed. The only permitted top-level fields are $schema, name, version, description, author, homepage, repository, license, keywords, and extensions. Only the first two are required. If you have been putting hooks, agents, commands, or an mcpServers block at the top level of a plugin manifest in some other format, none of those belong in a conformant plugin.json.

The rule that does the most work is that plugin.json cannot relocate components or declare them inline. There is no configurable discovery path and no precedence order. Skills are found at skills/ or they are not found. MCP configuration is read from root mcp.json or from nowhere. That constraint is what makes a package readable by a client that has never seen it before.

Each mcp.json server entry declares its transport explicitly with a type field: stdio, streamable-http, or the deprecated sse. A client never infers a transport from the shape of the config. A conformant MCP-capable client must support at least one of stdio and streamable-http; sse support is optional.

Failures are scoped, and that is the useful part

The specification defines narrow failure boundaries rather than all-or-nothing loading. A fatal plugin.json violation rejects the whole plugin. An invalid top-level mcp.json disables MCP for that plugin while the skills still load. An invalid individual server entry skips only that entry. A server that fails to start, connect, or authenticate affects only itself. An invalid individual skill is skipped while its siblings load. A missing fixed location is not an error at all, it is a valid absence.

In practice this means one broken credential or one unavailable remote endpoint does not take down a bundle of otherwise working instructions. If you have ever had an entire tool configuration refuse to load because of one bad entry, that is the specific pain this addresses.

There is also a hard containment rule. Every file or directory the client reads or executes from the package must resolve inside the plugin root, and clients must reject package paths that resolve outside it even through symlinks, junctions, or reparse points.

What version 1.0.0 deliberately leaves out

This is the section to read before you treat a plugin as a security boundary. The project's own FUTURE_CONSIDERATIONS document, which is explicitly non-normative and commits to nothing, records the gaps openly rather than hiding them.

Version 1.0.0 defines no trust model, no permission system, and no sandboxing requirements. It does not specify how a client or user can verify the origin or integrity of a plugin, so there is no cryptographic signature verification and no attestation chain in the standard. It does not specify how secrets or API keys should be provided, stored, or scoped for MCP servers that need them. It defines no enterprise allowlist, blocklist, or approval workflow. Plugins cannot declare dependencies on other plugins, and no test harness or validator command is specified.

There is no install mechanism and no distribution protocol either. Agent Plugins tells you how a package is laid out once it is on disk. Getting it there, deciding whether it should be trusted, and deciding what it is allowed to touch all remain the client's job, and the project says so directly.

The practical read for a builder: a plugin that bundles an mcp.json stdio server is a package that will launch a local executable when the client enables it. VS Code documents that plugin MCP servers start automatically when the plugin is enabled. Install plugins from sources you would already trust with a shell command, because at v1.0.0 the format itself gives you no additional guarantee.

Who is actually loading these

The specification site publishes a compatible-clients page, which is the honest place to check rather than any vendor's announcement. As of the check on September 6, 2026 it lists VS Code, GitHub Copilot, Cursor, ChatGPT and Codex, Kiro, Grok Bot, Hermes Agent, OpenClaw, and NanoClaw.

Every listed client supports Agent Skills. Transport coverage differs: VS Code, GitHub Copilot, Cursor, Kiro, Grok Bot, and OpenClaw document stdio, Streamable HTTP, and legacy SSE, while ChatGPT and Codex, Hermes Agent, and NanoClaw document stdio and Streamable HTTP only. The site notes clients can adopt component types incrementally, so a client appearing on the list is not a promise that every part of your package will load.

Governance is worth noting because it affects how durable the format is likely to be. The Technical Steering Committee's initial Core Maintainers are Amazon, Cursor, Microsoft, OpenAI, and Vercel, and Google announced on August 6, 2026 that it was joining as a Core Maintainer. That is unusually broad for a format this young, which is a reason to take it seriously, though breadth of sponsorship is not the same as long-term stability.

When you should not make a plugin

Google's engineering post is unusually direct about this and it is worth repeating. If you are shipping a single MCP server to a single client, a plain mcp.json is still the simpler answer. If you have a single skill, you do not need a plugin.

The format earns its place when you have components that belong together and need to travel together: a skill that knows how to do something plus the MCP server that gives it the data, maintained as one unit and shipped to more than one client. That is the fork-and-drift problem it was designed to end.

Adopting one layer does not obligate you to the next. You can publish a plugin with no catalog entry, and you can keep running skills with no plugin at all.

Limits of this answer

This is a description of a specification and its documented client support, not a hands-on review. RepoRadar has not built and shipped a conformant plugin across every listed client, and client conformance in practice can lag published documentation.

The compatible-clients list and the transport coverage per client are point-in-time facts checked on September 6, 2026. Both will change, and the specification repository lists 1.1.0 as a working draft, so details here describe 1.0.0 specifically.

The FUTURE_CONSIDERATIONS items are explicitly non-normative. Nothing in them is committed for a future release, so do not plan a security posture around permissions or signatures arriving on a schedule.

A useful next action

If you already maintain a skill and an MCP server that belong together, build the minimum package once and see whether it loads in a second client. Create a directory, add a plugin.json containing only the canonical $schema value for 1.0.0 and a name, and move the existing skill into skills/<name>/SKILL.md. That is a valid plugin.

Add mcp.json only if the plugin actually ships MCP servers, and give every entry an explicit type. Then load it in two of the listed clients and note what each one silently ignored. The gap between what you packaged and what loaded is the real answer for your setup.