Agent Plugins: Why Packaging Is the Next Step After MCP

Ask your IT department how many MCP servers are currently running in your organisation. In most companies the honest answer is: unknown. The Model Context Protocol solved something that had been open for years – an assistant can reach the ticket system, the file share and the line-of-business application without a bespoke connector for every model. What MCP never addressed: how that access is distributed, versioned and withdrawn as a unit.

This is exactly where a new standard comes in. On 6 August 2026 the Agent Plugins Specification 1.0.0 was published – a vendor-neutral format that bundles Agent Skills and MCP servers into a single, distributable package. It is governed by a Technical Steering Committee whose Core Maintainers include Amazon, Cursor, Microsoft, OpenAI and Vercel; Google joined on the day of the announcement.

For IT leaders in mid-sized companies this is not a developer footnote. It is the first answer to a question that is already on your desk: how do you roll out a vetted AI capability to 300 employees without configuring it 300 times by hand?

What the standard actually defines

Agent Plugins does not reinvent MCP or Agent Skills. The specification deliberately describes only how a client finds both component types together inside one package. That sounds modest – and that is precisely the point.

A plugin is a directory, not an archive and not an installer. It contains:

• plugin.json – the manifest at the plugin root. The only required fields are $schema (the canonical identifier of the specification version) and name. Optional fields are version, description, author, homepage, repository, license, keywords and extensions. The schema is closed: any other top-level field must be reported and ignored by the client.
• skills/ – every immediate child directory containing a SKILL.md counts as one skill. Format and frontmatter follow the Agent Skills specification; deeper descendants are deliberately not searched.
• mcp.json – the MCP server definitions under the mcpServers key, each with an explicit transport: stdio, streamable-http, or the deprecated sse. stdio servers use command, args, env and cwd; the HTTP variants use url and headers.
• Reverse-domain directories such as com.example.client/ – where each client stores its own extensions without touching the portable core.

More interesting than the field list are the safety rules the standard already ships with. Every path a client reads or executes from the package must resolve inside the plugin root – symlinks pointing outside it must be rejected. command must be a single executable token, explicitly not a shell string. Remote endpoints must use HTTPS unless they point at loopback. And the specification states twice, unambiguously: credentials do not belong in env or headers. Those values are visible package data, not a secret mechanism.

For runtime paths there are exactly two placeholders: ${PLUGIN_ROOT} points at the shipped package, ${PLUGIN_DATA} at a client-managed data directory that persists across updates. Installed dependencies and caches belong in PLUGIN_DATA; bundled scripts and binaries in PLUGIN_ROOT. Anyone who has ever shipped an update that wiped a tool’s state knows why this separation is normative.

The failure model is equally telling: an invalid skill leaves the other skills loading. A broken MCP server entry disables that entry only, not the package. Only an invalid manifest causes the whole plugin to be rejected. These graduated failure boundaries are the difference between a standard that survives operations and one that takes down half a department on the first typo.

What the standard deliberately leaves open

This is where it gets relevant for decision-makers. Version 1.0.0 defines no trust model, no permission system and no sandboxing requirements. It covers neither distribution nor installation. There is no signature verification, no provenance check, no portable secret mechanism and no organisational policy layer.

That is a documented design decision, not an oversight – and the project names these gaps itself as areas for future versions: permission declarations in the manifest, graduated trust levels, cryptographic signatures and attestation chains, client-mediated secret injection, allow- and blocklists for organisations, and a standardised audit event schema are all listed as possible extensions. None of it is committed; version 1.1.0 currently exists as a working draft.

The only permission-shaped thing inside a package is the allowed-tools field in SKILL.md – and the Agent Skills specification itself marks that field as experimental.

The conclusion is straightforward: the standard packages the parts; the trust decision stays with you. Reading Agent Plugins as “vetted because standard-compliant” misreads the specification. A fully conformant plugin can start a stdio process on your application server. Conformance says nothing about whether it should.

Why packaging is the next step after MCP

MCP standardised access. Agent Plugins standardises the building block.

The difference is the one between a network protocol and a package format. HTTP settled how data moves, but container images made software genuinely distributable – because they bound application, configuration and dependencies into one unit with a name and a version. That unit has been missing from the AI landscape.

Take a concrete case. Your legal team has developed a contract review procedure – review steps, standard clauses, a checklist, plus access to the document management system. Today that lives as a prompt collection in a wiki, a server entry in a YAML file, and knowledge in two people’s heads. As an Agent Plugin it becomes a directory with a name, a version, a licence and a repository reference – something you can deploy, update and withdraw.

That shifts the conversation from “which tools may the AI call?” to “which capabilities do we provide, who owns them, and which version runs where?” That is a lifecycle question – and therefore, finally, a question your IT organisation already has processes for.

The marketplace idea – and why it starts internally

Public discussion quickly equates the standard with an app store. At launch, according to the initiative, supporting clients include ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code; Google ships its own packages through the Agents CLI and the Data Agent Kit.

For mid-sized European companies, though, the value is not primarily in consuming public plugins – that brings exactly the supply-chain and provenance risks version 1.0.0 leaves open. The value lies in the internal catalogue: vetted packages owned by your business units, centrally approved and delivered through your existing version control. An internal registry with an approval workflow, rather than pulling packages off the open internet. The standard makes this feasible at reasonable effort for the first time, because the format is small and easy to implement – and because a package description is a readable JSON manifest, not a proprietary bundle.

What this means for CompanyGPT and the AI Gateway

CompanyGPT, our GDPR-compliant enterprise AI assistant, is built on LibreChat. The package format has already arrived there: since version 0.8.8-rc1 there are experimental Agent Plugins that implement the 1.0.0 format and load every immediate child directory of a configured plugin folder as one plugin at startup. LibreChat additionally uses the reserved extension namespace for optional command hooks – which are disabled by default and must be switched on deliberately by the operator.

For us this means: CompanyGPT already supports Agent Plugins experimentally at the platform level, and we will support the format in the environments we operate once it leaves the experimental phase. We deliberately name no date – putting an experimental feature that executes processes on the application server into production without a maturity review would contradict our own advice. The existing integrations library with its MCP connectors is the natural foundation: what is configured today as an individual integration can in future be bundled and distributed as a packaged building block.

For the AI Gateway we see the division of roles as follows: a plugin describes which tools an agent may reach – the gateway controls which models it uses to do so, under which budget and against which cost centre. The two interlock without replacing one another. We plan to take packaging into our governance layer once the standard moves the pieces it needs – signatures, permissions, audit events – from future considerations into normative text.

What you should do now

You do not need to migrate anything today. You should, however, prepare four things:

1. Inventory your MCP servers. Which servers run where, who set them up, which systems do they reach? Without that list you cannot assemble a package – and without it you also do not know how large your attack surface is today.
2. Define ownership per capability. A plugin needs a business owner, not just a technical administrator. Settle that assignment now, while it concerns ten building blocks rather than a hundred.
3. Set your approval criteria before the standard supplies them. Provenance, review, secret handling, update path, withdrawal path. The specification explicitly leaves these to you – use the time instead of closing an open flank later.
4. Treat command hooks as what they are. Execution of third-party code on your server. Off by default, on only case by case and only for packages you built yourself.

Conclusion

Agent Plugins is a deliberately small standard with a large effect: it turns scattered configuration into a nameable, versionable, distributable building block. For companies using AI beyond isolated pilots, that is the move from tinkering to lifecycle management.

At the same time the gap is honestly stated: trust, permissions and provenance are not covered by version 1.0.0. Anyone who establishes internal governance for AI building blocks now will be caught up by the standard rather than run over by it – and will later be able to admit public packages under control instead of inheriting them unchecked.

Our recommendation: start with the MCP inventory and a handful of internally owned packages. The technical details are available in the specification at agent-plugins.org. If you would like to think the governance through with us, get in touch.