Agent Plugins 1.0: A Portable Format for AI Coding Tools

Agent Plugins 1.0 gives developers a portable package format for AI-agent extensions. A plugin can carry reusable skills and MCP server configuration in a predictable directory, so compatible clients can discover the same capabilities without each project maintaining a different layout. The standard reduces packaging duplication; it does not make every plugin feature-equivalent, safe by default or universally portable.

What Agent Plugins 1.0 standardizes

GitHub says Agent Plugins 1.0 was published on August 6, 2026, with AWS, Anysphere, Microsoft, OpenAI and Vercel, while Google joined as a core maintainer. The format is designed to package agent skills and Model Context Protocol (MCP) servers into one installable plugin that is not governed by a single vendor.

The v1 specification defines exactly two portable component types:

Skills: instructions, scripts and reference material that an agent can load when needed.
MCP servers: configuration for external tools and data sources exposed through the Model Context Protocol.

A conforming package uses a root plugin.json manifest. Skills are discovered under skills/, and MCP configuration is discovered from mcp.json. The core specification does not put those component paths inline in the manifest.

A minimal package can look like this:

text

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       └── SKILL.md
└── mcp.json

This separation is the important idea: the package has one portable core, while clients can add their own extensions without changing the core format.

Why the format matters to developers

Before a shared format, a maintainer could reuse the same instructions and server but still need different manifests and directory conventions for different agent clients. Agent Plugins 1.0 makes the packaging boundary explicit.

GitHub’s announcement says a single plugin can be used across compatible clients. As of its August 12, 2026 changelog, support was generally available in VS Code, GitHub Copilot CLI, the GitHub Copilot SDK and the GitHub Copilot app, on all Copilot plans. GitHub’s weekly release notes repeated those four surfaces as generally available.

For a team, the practical benefits are narrower than “write once, run everywhere”:

maintain one source package for portable skills and MCP configuration;
make discovery and installation more predictable;
keep client-specific behavior in a namespaced directory;
review one package before distributing it across supported clients;
reduce migration work when a client adopts the standard.

Portability is therefore a maintenance advantage, not a guarantee that every client exposes identical controls or behavior.

The package layout: portable core, client extensions

Agent Plugins 1.0 uses reverse-domain namespaces for client-specific data. In VS Code’s implementation, Copilot-specific agents, commands, rules and hooks live under com.github.copilot/. Other clients can ignore that namespace while still reading the portable skills and MCP configuration.

A fuller layout might be:

text

my-plugin/
├── plugin.json
├── skills/
├── mcp.json
└── com.github.copilot/
    ├── agents/
    ├── commands/
    ├── rules/
    └── hooks/

This distinction is easy to miss. Skills and MCP server configuration are portable component types in v1. Custom agents, hooks and slash commands are client-specific. They can travel inside the same package, but they do not acquire universal semantics merely because the package follows Agent Plugins 1.0.

The standard also defines ${PLUGIN_ROOT} for packaged files and ${PLUGIN_DATA} for writable state that persists across plugin updates. A developer should verify how the target client expands and manages those paths before relying on them in production.

What the standard does not solve

Agent Plugins 1.0 is a packaging standard. It is not a sandbox, a permission model, a marketplace trust framework or a security certification.

The specification requires package paths to remain inside the plugin root, which limits path-escape mistakes in package references. But it explicitly does not sandbox a plugin subprocess or restrict paths supplied at runtime.

VS Code warns that plugins can include hooks and MCP servers that run code locally. Its documentation also states that plugin MCP servers are implicitly trusted when the plugin is installed, unlike workspace MCP servers that receive a separate trust prompt at startup.

That creates a clear review obligation. Before installing a plugin, inspect:

the publisher, repository and version history;
every SKILL.md and referenced script;
the commands, arguments, environment variables and working directories in mcp.json;
any hooks under a client-specific namespace;
network destinations, credentials and data flows;
the target client’s trust and update behavior.

An open format makes a package easier to inspect. It does not make the package trustworthy without inspection.

A migration path for plugin authors

GitHub describes adoption as mostly manifest and layout work for existing plugins:

Add the Agent Plugins 1.0 $schema identifier to plugin.json.
Keep portable skills under skills/.
Move MCP configuration to the root mcp.json.
Move Copilot-only files into com.github.copilot/.
Test installation and behavior in each supported client.
Document which capabilities are portable and which are client-specific.

The specification is closed around the core manifest: required fields include $schema and name, while metadata can include version, description, author, homepage, repository, license, keywords and extensions. Unknown top-level fields do not become an informal extension mechanism; client-specific data belongs under the relevant namespace.

Keep the package small and the permissions narrow. A plugin that combines a useful skill with an MCP server should explain exactly what the server can read or change, whether it runs locally or remotely, and which credentials it expects.

A decision rule for teams

Adopt Agent Plugins 1.0 when the main problem is distributing the same agent capability across compatible clients. Do not adopt it on the assumption that the format removes the need for client testing or governance.

A useful rollout sequence is:

start with a read-only skill or MCP server;
pin the specification, client and dependency versions;
test installation in a clean environment;
compare the package’s behavior across clients;
use allowlists and managed marketplaces where available;
log tool calls and review changes after updates;
give users a clear disable and uninstall path.

For enterprise Copilot customers, GitHub says existing managed settings can control which plugins are enabled, which marketplaces are available and whether installation is restricted to managed marketplaces. That is a client governance feature, not a property guaranteed by the open format itself.

FAQ

Is Agent Plugins 1.0 a replacement for MCP?

No. MCP defines the protocol used to connect an AI application with tools and data sources. Agent Plugins 1.0 defines a portable way to package MCP server configuration together with skills.

What is portable in Agent Plugins 1.0?

The v1 core standardizes skills and MCP server configuration. Custom agents, hooks, commands and rules may be included as client-specific extensions, but their behavior depends on the client that owns the namespace.

Does a plugin run safely because it follows the specification?

No. The specification includes package-path containment rules, but it does not sandbox subprocesses or create a universal permissions model. Review the package, publisher, scripts, server configuration and trust behavior of the target client.

Should a small team install plugins from any marketplace?

No. Start with a known source, inspect the files, use the narrowest permissions possible and test the plugin in an isolated environment before connecting real credentials or business data.

Sources

For practical implementation starting points, explore the SignorCrypto Toolkit. If your team is assessing how to package or govern AI-agent capabilities, contact SignorCrypto.