Agent Plugins 1.0: package skills and MCP once, stop maintaining five client manifests

Introduction

I have been shipping the same skill plus the same MCP server into three or four client shapes for a year. Cursor wants one layout. Copilot wants another. Codex wants a third. VS Code grows its own. Every "portable" agent skill became a small packaging project. That tax is what Agent Plugins 1.0 is trying to kill.

On August 6 the standard shipped as 1.0.0 (Vercel announcement, agent-plugins.org, spec repo). On August 12 GitHub made 1.0 generally available in VS Code, Copilot CLI, and the Copilot app (changelog). I care about both dates. The first is the contract. The second is whether enterprises can actually manage it.

This is not a victory lap for standards committees. It is a migration note for teams that still maintain per-client manifests, plus an honest callout that Claude Code is absent from the launch client list. If your shop is Claude-first, you still need a dual path. If your shop is Cursor + Copilot + VS Code, this is the week to stop copying folders by hand.

What Agent Plugins 1.0 actually is

The portable core is small on purpose. A plugin is a package with a plugin.json manifest, a skills/ tree for reusable instructions and workflows, and an optional mcp.json that declares MCP servers the plugin needs. Client-specific extras sit under reverse-domain namespaces so Copilot can own com.github.copilot/ without forking the whole package. That is the right shape. Shared contract in the root. Vendor opinion in a namespace.

• Open standard, versioned 1.0.0.
• Maintainers / TSC participants named from AWS, Cursor, Microsoft, OpenAI, and Vercel; GitHub involved in development.
• Launch clients: ChatGPT / Codex, Cursor, GitHub Copilot, Kiro, VS Code.
• Not on the launch client list: Anthropic / Claude Code.
• August 12 GA adds Business / Enterprise managed settings: enabledPlugins, marketplaces, MCP allowlists.

If you already lived through MCP's July GA week, this should feel familiar. Protocol maturity is half the story. Client adoption and enterprise policy controls are the other half. My day-one MCP notes still apply for server behavior: MCP 2026-07-28 GA field notes. Header and auth hygiene still matter: MCP stateless header security checklist.

Minimal package layout

Here is the smallest layout I use when teaching teams the standard. Names are illustrative. Keep secrets out of the package. Point mcp.json at config that resolves tokens from the environment or a secret manager.

{
  "name": "acme.incident-triage",
  "version": "1.0.0",
  "description": "Incident triage skills and MCP servers for on-call agents",
  "skills": "./skills",
  "mcp": "./mcp.json"
}

# layout
# plugin.json
# skills/
#   triage.md
#   escalate.md
# mcp.json
# com.github.copilot/   (optional client extras)
# com.cursor/           (optional client extras)

The skills/ files are the portable instructions. The mcp.json is the portable tool wiring. Namespaced folders are where you put Copilot-only UI affordances or Cursor-only defaults without breaking other clients. If your "plugin" is only a namespaced folder with no root skills or MCP, you are still shipping a vendor lock-in package with nicer branding.

August 12 GA: why enterprise settings matter

Open standards fail in companies when anyone can install anything. The August 12 GA in VS Code, Copilot CLI, and the Copilot app matters because Business and Enterprise managed settings cover enabledPlugins, marketplaces, and MCP allowlists without inventing a separate Agent Plugins policy surface. That is the control plane I want before I tell a platform team "roll this out."

MCP allowlists are not optional decoration. A plugin that can pull an MCP server is a supply-chain path into tool execution. Pair plugin allowlisting with the same posture you use for agent autonomy gates in governing agent autonomy with Auto-review and pre-push review. If a plugin can install a server that can write to prod, that is not a packaging decision. That is an access decision.

The Claude Code gap (state it honestly)

Anthropic / Claude Code is not on the launch client list. I am not going to paper over that. If your production agents live in Claude Code, Agent Plugins 1.0 does not magically unify your packaging this week. You still maintain a Claude-side skill / MCP path, and you can still adopt Agent Plugins for the Cursor / Copilot / VS Code / Codex surface.

The workable pattern for mixed shops: keep the skill prose and MCP server implementations in one repo module, generate or hand-maintain Claude Code manifests from that source, and publish an Agent Plugins package for the launch clients. One source of truth. Two distribution adapters until Claude Code joins or you drop that client. Annoying. Better than five hand-edited trees.

Migration from per-client manifests

Most teams I see do not need a six-month platform program. They need a cleanup sprint. Here is the sequence I run.

1. 01
   Inventory every skill and MCP install path

   List Cursor rules/skills, Copilot custom instructions, VS Code agent assets, Codex packaging, and any ad-hoc zip people email around. Include who owns each.
2. 02
   Extract the portable core

   Move shared instructions into skills/. Move shared server declarations into mcp.json. Delete duplicated prose that drifted between clients.
3. 03
   Park vendor-only bits under namespaces

   Copilot-specific settings under com.github.copilot/. Cursor-only defaults under a Cursor namespace. Do not shove vendor UI into the portable skill text.
4. 04
   Publish one plugin version and pin it

   Cut 1.0.0 (or your semver). Install on one pilot squad across two launch clients. Confirm skills resolve and MCP servers still authenticate.
5. 05
   Turn on managed settings before broad rollout

   Set enabledPlugins, approved marketplaces, and MCP allowlists for Business / Enterprise. Prove a denied plugin and a denied MCP server fail closed.
6. 06
   Retire the old per-client copies

   Delete or archive the duplicate manifests so they cannot silently diverge. Leave a short README that points authors at the plugin package.

Common mistakes

• Calling it "portable" while leaving the real logic only in a namespaced vendor folder.
• Baking API keys into mcp.json inside the plugin archive.
• Shipping MCP servers without updating enterprise allowlists, then blaming the standard when installs fail.
• Assuming Claude Code support because Anthropic is adjacent to the agent ecosystem. It is not on the launch client list.
• Skipping supply-chain review because the file looks like markdown skills.
• Maintaining the old per-client manifests "just in case" until they drift and break the whole point.
• Rolling out marketplace installs org-wide before enabledPlugins and MCP allowlists are set.

The supply-chain angle is the one I push hardest in reviews. Plugins are a distribution channel for tools. If you care about agentic AI supply chain security, treat plugin authors like dependency authors: signed or reviewed sources, pinned versions, least-privilege MCP scopes.

How this changes authoring workflows

Before 1.0, authors optimized for one IDE and shrugged at the others. After 1.0, the authoring unit should be the plugin. Write the skill once. Declare MCP once. Test on two launch clients before you call it done. That is a slightly heavier local loop and a much lighter org loop.

Platform teams should own the marketplace and allowlist policy. Feature teams should own plugin semver and changelog. Mixing those responsibilities is how you get "the platform team edited our skill on Friday and on-call broke Saturday."

I also want a smoke test in CI that loads plugin.json, asserts skills/ paths resolve, and greps mcp.json for hard-coded secrets. It is boring. It catches the two failure modes that waste the most time: a broken relative path after a rename, and a token someone pasted "just for the demo."

What "done" looks like for a plugin PR

• One portable skills/ change, reviewed once, lands in every launch client on the next install.
• mcp.json references env-backed credentials only.
• Namespaced extras are documented in the PR body so reviewers know they are client-local.
• Managed settings already allow the plugin id and any MCP servers it declares.
• Changelog line states whether this is skills-only, MCP-only, or both.

Relation to MCP GA and autonomy gates

Agent Plugins does not replace MCP. It packages how agents discover skills and servers across clients. You still need solid MCP server design, stateless header discipline, and runtime allowlists. You still need autonomy gates when those tools can change real systems. Think of Plugins as the box, MCP as the tools inside the box, and Auto-review / pre-push review as the door locks.

If your MCP servers are still sticky-session era or still skip header security checks, fix that before you scale plugin distribution. Packaging a weak server into five clients faster is not progress. Topic hub for the protocol side: MCP.

What I would do this week

Pick one skill that already exists in two clients. Convert it to an Agent Plugins package. Install it in VS Code or Copilot CLI under managed settings with a tight MCP allowlist. Keep Claude Code on the dual path if you need it. Measure whether authors stop opening three PRs for one prose change. That single metric tells you if the standard is earning its keep.

I do not need every vendor on day one to call 1.0 useful. I need enough launch clients that the portable core is worth maintaining, plus enterprise controls so security does not veto the rollout. August 6 and August 12 together clear that bar for Cursor / Copilot / VS Code / Codex / Kiro shops. Claude-first shops get a partial win and a remaining adapter. That is the accurate status, not the keynote status.

Conclusion

Agent Plugins 1.0 is the packaging contract agent teams needed: skills and MCP in one versioned unit, vendor extras namespaced, enterprise allowlists on the GA path for VS Code and Copilot. Use it to kill per-client drift. Do not pretend Claude Code is included. Do not treat mcp.json as documentation. Pin, allowlist, and review plugins like the executable dependencies they are.

Sources: vercel.com — introducing agent plugins ; agent-plugins.org ; GitHub ; github.blog