Agent Plugins vs Standalone MCP Servers (2026): Portable Packaging vs Per-Client Deployment
Agent Plugins 1.0.0 vs standalone MCP servers in 2026: a portable packaging spec backed by Vercel, AWS, Microsoft, OpenAI and Google compared with per-client packaging. Portability, governance, maturity and when each fits.
Adopt Agent Plugins for any extension that needs to travel across more than one compatible client. The spec is one day old, but the problem it solves is real and well-understood: repackaging the same MCP server for every client is the default failure mode of the agent-extension ecosystem, and the six launch clients plus Google's day-one products cover enough surface area that a plugin packaged today will reach the majority of the market without modification. Stay with direct per-client MCP deployment when you are shipping to a single client, when you need client-specific capabilities that the portable contract does not cover (commands, hooks, agents), or when the absence of a trust and permissions model in the spec is a disqualifier rather than a deferred item. The spec is deliberately honest about what it does not define — no install mechanism, no distribution protocol, no sandboxing, no trust verification — and for regulated or enterprise environments those gaps matter today, even if they close in future versions. The pattern Context Studios favours is a hybrid one: package the portable parts (Agent Skills, MCP server declarations) as an Agent Plugin, and keep client-specific behaviour in the namespaced extension directory. When the portable contract is too narrow, ship directly. When it is wide enough, ship once. The spec's scope discipline is its strongest feature — it standardises only what genuinely travels, and leaves the rest where it belongs.
Detailed Comparison
A side-by-side analysis of key factors to help you make the right choice.
| Factor | Agent PluginsRecommended | Standalone MCP Servers | Winner |
|---|---|---|---|
| Cross-client portability | One plugin directory with a plugin.json manifest, skills/ folder and mcp.json works across every compatible client — ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code at launch — without repackaging. | Each client expects different top-level metadata, discovery paths and MCP configuration shapes, so the same MCP server must be repackaged for every target client. | |
| Component independence and fault isolation | Skills and MCP servers are validated independently after the manifest is checked, so one invalid component does not disable unrelated ones in the same plugin. | A single misconfigured MCP server can break the entire extension load because there is no shared contract for independent component validation. | |
| Client-specific optimisation | A namespaced extension directory (com.example.client/) lets each client add hooks, agents or commands without polluting the portable core, but the extension is invisible to other clients. | Direct deployment gives full control over how the MCP server is configured, discovered and presented for one specific client, with no abstraction layer in the way. | |
| Discovery and loading contract | The spec defines fixed paths — plugin.json at root, skills/ for Agent Skills, mcp.json for MCP servers — giving client implementers a small, deterministic contract for discovery, validation and loading. | Discovery is whatever each client invents: different top-level metadata, different config shapes, different transport inference rules, so there is no single contract to implement against. | |
| Distribution, trust and permissions | The spec deliberately defines no install mechanism, no distribution protocol, no permission model, no sandboxing requirements and no trust or provenance verification — all explicitly named as future considerations. | Each client implements its own installation, permission and trust model, so security properties differ per client but exist today rather than being deferred. | |
| Governance and vendor neutrality | The Technical Steering Committee includes Core Maintainers from AWS, Cursor, Microsoft, OpenAI and Vercel, with Google joining at launch — no single company's product roadmap sets the format's direction. | Packaging conventions are set by each client vendor unilaterally, so the format's direction follows whichever client you deploy to first. | |
| Implementation maturity and production track record | The specification shipped as version 1.0.0 on 6 August 2026 — one day old at the time of writing — with Google's Agents CLI and Data Agent Kit as the only shipping plugin examples beyond the launch clients' own support. | Direct MCP server deployment has a multi-year head start, a large body of production deployments, and mature tooling across every major AI client that already speaks MCP. | |
| Scope discipline and extensibility | Version 1 focuses on two component types — Agent Skills and MCP servers — and explicitly defers commands, hooks and agents to clients until portability needs emerge and consensus forms. | Per-client packaging can include whatever the client supports — commands, hooks, agents, custom UI — with no need to wait for a multi-vendor consensus process. | |
| Total Score | 4/ 8 | 4/ 8 | 0 ties |
Key Statistics
Real data from verified industry sources to support your decision.
GitHub API
Vercel Blog
Agent Plugins Specification
Google Developers Blog
Agent Plugins Specification
Vercel Blog
All statistics come from verified third-party sources. Source, year, and direct link are shown on each metric.
When to Choose Each Option
Clear guidance based on your specific situation and needs.
Choose Agent Plugins when...
- You build extensions that need to run across multiple AI clients — ChatGPT, Cursor, GitHub Copilot, VS Code or Kiro — without repackaging for each one
- You ship both Agent Skills and MCP servers together and want them discovered as one unit, with independent validation so a broken MCP server does not disable the Skills
- You want your plugin to remain portable as new clients adopt the spec, without rewriting your packaging for each new client
- You are building for the ecosystem floor: one directory, one manifest, one contract that any compatible client can load
Choose Standalone MCP Servers when...
- You ship a single MCP server to a single client and mcp.json alone is the simpler answer — a plugin wrapper adds overhead without benefit
- You need client-specific capabilities the portable contract does not cover — commands, hooks, agents or custom UI — and waiting for a multi-vendor consensus is not practical
- Your environment requires a trust, permissions or sandboxing model that the spec explicitly does not define, and per-client deployment gives you that today
- You need production maturity that a one-day-old specification cannot offer, and your MCP server already works across your target clients
Our Recommendation
Adopt Agent Plugins for any extension that needs to travel across more than one compatible client. The spec is one day old, but the problem it solves is real and well-understood: repackaging the same MCP server for every client is the default failure mode of the agent-extension ecosystem, and the six launch clients plus Google's day-one products cover enough surface area that a plugin packaged today will reach the majority of the market without modification. Stay with direct per-client MCP deployment when you are shipping to a single client, when you need client-specific capabilities that the portable contract does not cover (commands, hooks, agents), or when the absence of a trust and permissions model in the spec is a disqualifier rather than a deferred item. The spec is deliberately honest about what it does not define — no install mechanism, no distribution protocol, no sandboxing, no trust verification — and for regulated or enterprise environments those gaps matter today, even if they close in future versions. The pattern Context Studios favours is a hybrid one: package the portable parts (Agent Skills, MCP server declarations) as an Agent Plugin, and keep client-specific behaviour in the namespaced extension directory. When the portable contract is too narrow, ship directly. When it is wide enough, ship once. The spec's scope discipline is its strongest feature — it standardises only what genuinely travels, and leaves the rest where it belongs.
Frequently Asked Questions
Common questions about this comparison answered.
Need help deciding?
Book a free 30-minute consultation and we'll help you determine the best approach for your specific project.