Agent Plugins 1.0: One Package for Skills and MCP

On August 12, 2026, Agent Plugins 1.0 became generally available in VS Code, Copilot CLI, the GitHub Copilot SDK, and the Copilot app, across all Copilot plans. A week earlier, on August 6, Google announced it was joining as a Core Maintainer of the same specification — a spec published by maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. The practical upshot: there is now one packaging format for agent capabilities instead of one per client.

The problem: the components were portable, the wrapper wasn't

A skill is, at its core, a text file of instructions. An MCP server is, at its core, a tool contract over a known transport. Both are client-neutral. What wasn't portable was the wrapper around them: every client expected a different directory layout, a different manifest format, and a different place for server configuration. Anyone supporting more than one client ended up forking the repository and maintaining two copies of components that were never different in the first place.

What changed

The specification — version 1.0.0, status Working Draft — defines a deliberate minimum. At the package root sits plugin.json, and exactly two fields are required: $schema, pointing at the canonical schema URL, and name, 1–64 characters of lowercase letters, digits, hyphens, and periods. Everything else is optional metadata: version, description, author, repository, license, keywords.

Version 1 recognizes two component types:

• Skills, discovered automatically from the skills/ directory, each subdirectory containing a SKILL.md.
• MCP servers, declared in mcp.json, over stdio, Streamable HTTP, or legacy SSE.

Anything specific to a single client is quarantined in a directory named after a reverse-domain namespace, such as com.github.copilot/, with a matching entry under the manifest's extensions field. The shared core stays shared; the vendor-specific parts stay contained — inside the same package.

A practical example

The smallest valid manifest:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin",
  "version": "1.0.0",
  "description": "Report generation skills and data tools",
  "license": "MIT"
}

The layout on disk:

reports-plugin/
├── plugin.json          # required
├── skills/
│   └── summarize/
│       └── SKILL.md
├── mcp.json             # optional
└── com.github.copilot/  # one client only

And the server declaration. Note the rule that plugin-relative paths must begin with ./ and must stay inside the plugin root:

{
  "mcpServers": {
    "reports-db": {
      "command": "./bin/reports-server",
      "args": ["--read-only"],
      "env": { "REPORTS_REGION": "eu-central-1" }
    }
  }
}

Real-world caveats

• Working Draft status. Version 1.0.0 is published and already implemented, but it is not a frozen final form. Details can still move.
• Narrow scope, on purpose. The spec defines no install mechanism, no distribution protocol, and no permission model. All three are left to individual clients, which means distribution and governance still differ from platform to platform.
• Security stays your job. A plugin can carry hooks and MCP servers that execute code on your machine. The VS Code documentation says so explicitly and advises reviewing the publisher first. At the organization level, enabledPlugins and strictKnownMarketplaces in managed-settings.json control what can be installed. Authenticating the servers themselves is the MCP specification's territory — covered previously in MCP's authentication update.
• Namespaced payloads stay namespaced. No other client will read com.github.copilot/. What became portable is the wrapper and the core, not everything inside the package.
• Forward compatibility is guaranteed. Unknown fields must not stop a client from loading the plugin, which lets the spec evolve without breaking existing packages.

Takeaway

The value here isn't a new agent capability — it's duplicated work disappearing: one component, one package, many clients. For anyone shipping skills or MCP servers today, the step is concrete: add a schema-conformant plugin.json, move components into skills/ and mcp.json, and keep client-specific material inside its namespace directory. A standard doesn't replace the people building the tooling; it multiplies them, by ending the maintenance of two copies of the same thing.

Primary source: the Agent Plugins 1.0 specification, and GitHub's announcement.