EN
Book a call

Development Approach

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.

Reviewed by Michael Kerkhoff, as of

Definition
Agent Plugins 1.0.0 shipped on 6 August 2026 as an open, vendor-neutral standard for packaging Agent Skills and MCP servers into one portable directory. Five companies — Vercel, AWS, Anysphere (Cursor), GitHub, Microsoft and OpenAI — refined the proposal; Google joined the Technical Steering Committee the same day. Six clients support it at launch: ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code. The alternative is the status quo: each AI client develops its own plugin format, with different top-level metadata, discovery paths and MCP configuration shapes, even when the underlying Skill or MCP server is identical. Extension authors adapt and duplicate the same components for every client, and the copies drift. This comparison is for developers and teams who build agent extensions — MCP servers, Agent Skills, or both — and need to decide whether to adopt the new packaging standard or continue shipping per-client.
Category
Development Approach
Options
Agent PluginsStandalone MCP Servers

Detailed Comparison

A side-by-side analysis of key factors to help you make the right choice.

Agent Plugins vs Standalone MCP Servers
FactorAgent PluginsStandalone MCP Servers
Cross-client portabilityOne 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. WinnerEach 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 isolationSkills and MCP servers are validated independently after the manifest is checked, so one invalid component does not disable unrelated ones in the same plugin. WinnerA single misconfigured MCP server can break the entire extension load because there is no shared contract for independent component validation.
Client-specific optimisationA 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. Winner
Discovery and loading contractThe 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. WinnerDiscovery 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 permissionsThe 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. Winner
Governance and vendor neutralityThe 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. WinnerPackaging 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 recordThe 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. Winner
Scope discipline and extensibilityVersion 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. Winner
Provider gating (where MCP access is granted)Plugins ride on the MCP connection of their host client (ChatGPT, Codex, Cursor, Copilot, Kiro, VS Code). Where a tool provider like Figma gates access, the gate is on that client: a packaged server that runs inside an allowlisted client inherits the client's approved slot. WinnerStandalone per-client deployment leaves the choice of MCP client to you — and non-catalogued clients get rejected at the provider's edge: Figma answers clients outside its allowlist (for example Pi) with HTTP 403, so packaging freedom does not buy endpoint access.
Total Score · 0 ties5 / 94 / 9

Key Statistics

Real data from verified industry sources to support your decision.

  • The Agent Plugins specification repository on GitHub has 348 stars and 18 forks, with the most recent push on 6 August 2026 — the day of the 1.0.0 release. — GitHub API (2026)
  • Six AI clients support Agent Plugins at launch: ChatGPT and Codex, Cursor, GitHub Copilot, Kiro and VS Code. — Vercel Blog (2026)
  • The Technical Steering Committee includes Core Maintainers from AWS, Cursor, Microsoft, OpenAI and Vercel, with Google joining as a Core Maintainer on launch day. — Agent Plugins Specification (2026)
  • Google shipped two products supporting Agent Plugins on day one: Agents CLI and Data Agent Kit, the latter providing skills and MCP servers for BigQuery, Spanner and Cloud SQL in a portable plugin format. — Google Developers Blog (2026)
  • The Agent Plugins manifest requires only two fields — $schema and name — making the portable contract intentionally minimal so that adoption cost is near zero for plugin authors. — Agent Plugins Specification (2026)
  • Anthropic, which created both Agent Skills and MCP, does not appear as a contributor, TSC member or launch client in the Agent Plugins 1.0.0 specification. — Vercel Blog (2026)
  • Figma's remote MCP server (mcp.figma.com/mcp) is allowlist-only: only clients listed in the Figma MCP Catalog (Cursor, Claude Code, VS Code, Codex, Windsurf and similar) can complete OAuth — all other clients are rejected at the edge with HTTP 403 during dynamic client registration, as documented in the closed pi-mcp-adapter issue #49 (October 2026). — pi-mcp-adapter GitHub issue #49 + Figma developer docs (2026)
  • Figma caps MCP read traffic per seat: View/Collab seats get 6 MCP tool calls per month (20 on Starter); Dev/Full seats get 200 calls/day at 10/min on Pro and Organization plans and 600 calls/day at 20/min on Enterprise. Write tools such as add_code_connect_map, create_new_file and whoami are exempt from the rate limits. — Figma developer docs — Rate limits & access (2026)
  • The Hacker News thread of 1–2 October 2026 ("Figma restricts MCP access to whitelisted clients, excluding Pi") reports firsthand that the gate operates per client application — Copilot CLI was approved while Copilot Desktop initially failed — and Figma's enterprise-managed authorization (Okta Cross App Access) currently supports only Claude, so brokered access is itself gated client by client. — Hacker News discussion 49922729 (2026)

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.

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.

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

Common questions about this comparison answered.

Frequently Asked Questions

(01)Do Agent Plugins replace MCP servers?
No. Agent Plugins is a packaging format that bundles MCP servers and Agent Skills into one portable directory. The MCP server inside a plugin is the same MCP server you would deploy directly — the spec explicitly does not redefine MCP.
(02)Does the Agent Plugins spec define how plugins are installed or trusted?
No. Version 1 deliberately leaves installation, distribution, permissions, sandboxing, trust verification and user experience to each client. These are named openly in the project's future considerations, not quietly omitted.
(03)Should I package a single MCP server as an Agent Plugin?
If you are shipping one MCP server to one client, mcp.json on its own is still the simpler answer. Agent Plugins earn their keep when you have components that belong together and need to travel across multiple compatible clients.
(04)Is Anthropic involved in the Agent Plugins specification?
Anthropic does not appear as a contributor, Technical Steering Committee member or launch client in the 1.0.0 specification, despite having created both technologies the spec packages — Agent Skills and the Model Context Protocol. The spec is vendor-neutral and open, so Anthropic could join at any time.
(05)Does packaging as an Agent Plugin exempt me from tool providers that gate MCP access (like Figma)?
No. The gate lives at the provider's endpoint, not in the packaging format: Figma restricts its remote MCP server to clients on its allowlist (others get HTTP 403 at client registration) and caps read calls (6 per month on View/Collab seats, 20 on Starter). What decides your practical access is which MCP client you execute on — packaged or not, a non-allowlisted client still hits the wall, and an allowlisted one inherits its slot.

Need help deciding?

Book a free 30-minute consultation and we'll help you determine the best approach for your specific project.

Book Free ConsultationEmail Us

Free consultation · No obligation · Personal reply