On August 12, GitHub published the migration guide for Agent Plugins 1.0 — a spec that had actually launched a week earlier, on August 6, with AWS, Anysphere (Cursor), Microsoft, OpenAI, and Vercel as launch partners, and Google joining the same day as a core maintainer. That’s a wider coalition than most “open standard” announcements manage, and it’s worth understanding why: this solves a real, annoying problem that anyone shipping agent tooling across more than one client has hit.

The problem: every agent client wants its own manifest

If you’ve built a skill or an MCP server and tried to distribute it to more than one AI coding tool, you already know the pain. Copilot CLI wants one directory layout. The Copilot app in VS Code wants slightly different metadata. Cursor has its own config format. Claude Code has its own. The underlying capability — “here’s a skill that knows how to triage flaky tests” or “here’s an MCP server that talks to our internal deploy API” — is identical across all of them. But you end up maintaining three or four near-duplicate manifests just to distribute the same thing, and every time you update the skill, you update it in three or four places and hope you didn’t typo one of them.

Agent Plugins 1.0 packages skills and MCP servers into a single installable unit that any conforming client can consume. One plugin, one repo, one source of truth, works across VS Code’s Copilot extension, the Copilot CLI, the Copilot app, and — per the multi-vendor launch list — an expanding set of third-party clients.

What the package actually looks like

The migration guide lays out the shape plainly. A plugin gets:

{
  "$schema": "https://github.com/schemas/agent-plugin-1.0.json",
  "name": "flaky-test-triage",
  "version": "1.2.0",
  "description": "Diagnoses and proposes fixes for flaky tests",
  "skills": "./skills",
  "mcp": "./mcp.json",
  "vendor_extensions": {
    "com.github.copilot": {
      "categories": ["testing", "ci"]
    }
  }
}

Four things worth calling out for anyone about to do this migration:

1. $schema isn’t decorative. It’s how clients validate the plugin actually conforms to 1.0 rather than some earlier draft or a client-specific dialect. If you skip it, expect inconsistent behavior across clients rather than a hard failure — which is a worse debugging experience.
2. Skills live under skills/, not scattered at the repo root. This is the single biggest structural change if you’re migrating an existing Copilot-only extension — expect to physically move files, not just add a manifest.
3. MCP config is a separate mcp.json, not inlined into the plugin manifest. This is a sane separation: your MCP server config can be versioned, tested, and reasoned about independently of the skill packaging around it.
4. Vendor-specific behavior goes in a namespaced block (com.github.copilot/, presumably com.anysphere.cursor/ and similar for other vendors) that conforming clients from other vendors simply ignore. This is the part that makes the standard actually work as a standard instead of a lowest-common-denominator format — you don’t lose vendor-specific richness, you just fence it off so it doesn’t break portability.

Discovery and governance: this is where it gets interesting for a lead

Two things in the spec are aimed squarely at engineering leadership, not individual developers.

Discovery happens through marketplaces — GitHub’s own “Awesome Copilot” marketplace being the reference implementation, but the spec supports extraKnownMarketplaces as a first-class governance setting, meaning your org can register an internal marketplace for proprietary plugins without needing them public.

Governance is handled through managed-settings.json, which an enterprise admin controls, not individual developers:

{
  "enabledPlugins": {
    "flaky-test-triage": "auto-install",
    "experimental-refactor-agent": "blocked"
  },
  "extraKnownMarketplaces": ["https://plugins.internal.acme.com"],
  "strictKnownMarketplaces": true
}

strictKnownMarketplaces: true is the setting I’d expect most regulated orgs to flip on immediately — it restricts installation to only the marketplaces you’ve explicitly approved, closing off the “developer installs a random plugin from a random GitHub repo” risk that’s been an open question in agent tooling since MCP servers started proliferating. Combined with MCP-level allowlists, you get two layers of control: which plugins can be installed at all, and which MCP servers those plugins are allowed to talk to.

If your org has been putting off a policy for “which agent skills and MCP servers are engineers allowed to install,” this is the first time there’s a standard mechanism to actually enforce one instead of relying on tribal knowledge and code review vigilance.

How this relates to MCP

Worth being precise about the layering here, because it’s easy to conflate the two. MCP standardizes how an agent talks to a tool or data source at runtime — the protocol for tool calls, resource access, and so on. Agent Plugins 1.0 standardizes how you package and distribute a bundle of skills and MCP server configuration so that installing it is a single action across clients. MCP is the wire protocol; Agent Plugins is the packaging and distribution layer sitting one level above it. You’ll still write MCP servers the same way you do today — Agent Plugins just gives you one manifest to ship them alongside your skills instead of duplicating that shipping logic per client.

The honest caveat: it’s a 1.0

A six-vendor launch is a strong signal of intent, but a 1.0 spec with that many independent implementers is also where you should expect edge-case divergence. Watch for:

• Client-specific interpretation of vendor_extensions. The namespacing convention prevents outright breakage, but it doesn’t guarantee every client handles unknown top-level fields identically — test on every client you actually support, don’t assume spec compliance equals behavioral parity.
• Marketplace trust is still bootstrapping. strictKnownMarketplaces is only as good as your org’s discipline in curating the allowlist. A shiny new standard doesn’t remove the need for someone to actually vet what’s on it.
• Migration cost is nonzero. Moving an existing extension’s skills into skills/ and splitting out mcp.json is mechanical but not zero-effort — budget it as a real migration task, not a config tweak, if you maintain plugins today.

What I’d actually do this week

If your team publishes any internal Copilot extensions, skills, or MCP servers today: read the migration guide, and if you support more than one AI coding client across your engineering org, this is worth prioritizing over most other agent-tooling backlog items — it’s the difference between maintaining N manifests forever and maintaining one. If you’re purely a consumer of plugins rather than a publisher, the actionable item is standing up managed-settings.json with strictKnownMarketplaces: true before your engineers start installing things from marketplaces you haven’t reviewed.

Source: GitHub Changelog — Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app