Agent plugins 1.0: How to build once, use across clients

Agent Plugins 1.0 gives Agent Skills and MCP servers a portable package layout. Permissions, installation, user interface, and runtime behavior remain client-specific.

Until now, a team that combined a reusable skill with an MCP server often had to wrap the same components differently for every AI client. The instructions and server could travel, while the directory layout, manifest shape, transport configuration, and extension conventions changed by client. One capability became several packages that drifted apart.

Agent Plugins 1.0.0 is the new open, vendor-neutral specification for putting Agent Skills and MCP servers in one predictable directory. The initial core-maintainer group includes Amazon, Cursor, Microsoft, OpenAI, and Vercel; Google joined as a core maintainer at launch on August 6, 2026. Google's launch announcement frames the problem as package portability. The protocols inside the package remain unchanged.

Build one plugin when a skill and one or more MCP servers belong together and need to travel together. Keep the portable core small, put client-specific behavior in an extension, and document which parts each target client supports.

The package contract in Agent Plugins 1.0

An Agent Plugin is a directory rooted at one filesystem location. At its minimum, it contains a plugin.json manifest at the root. It can then contain two portable component types:

• Agent Skills, in skills/, with one skill per subdirectory; and
• MCP server definitions, in mcp.json.

A minimal package looks like this:

support-operations/
├── plugin.json
├── skills/
│   └── investigate-ticket/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

The manifest deliberately contains little beyond a schema identifier and a name. Fixed component locations give a compatible client one predictable place to look for a skill and one for MCP configuration. The Agent Plugins specification defines the package model, required root manifest, component locations, and client-conformance rules.

The mcp.json file also requires each server entry to name its transport explicitly. That avoids each client trying to infer whether a configuration represents stdio, Streamable HTTP, or legacy HTTP plus SSE from the shape of a JSON object. The specification supplies a common package for existing agent tooling.

Why the common box matters

Consider a reporting plugin with a skill that defines weekly active customers and an MCP server that queries the reporting system. The skill explains the metric but cannot fetch current data. The server returns data but lacks the operating guidance needed to interpret it.

Packaging those pieces together does three useful things:

1. It gives authors one release artifact across compatible clients.
2. It lets a client load a usable skill even if an optional MCP server fails to start.
3. It gives clients an agreed boundary for the parts that are shared while leaving room for differentiated features.

Agent Plugins reserves reverse-domain extension namespaces, such as com.example.client/, for a particular client's hooks, agents, commands, or metadata. Clients that do not recognize an extension ignore it. The portable core remains readable and stable while a client adds behavior without changing the shared format.

That is a better trade-off than stuffing every client's needs into one manifest. A universal manifest tends to become an accidental platform. A small manifest makes it clear which behavior will travel and which behavior will not.

Build the portable core first

First decide whether the components genuinely belong together. The manifest records that decision.

Use an Agent Plugin when a skill, server, scripts, and reference material together implement one recognizable capability. A customer-support investigation plugin is a good fit: it may contain a SKILL.md that explains the investigation method and a server that can retrieve authorized ticket, account, and product data. A single skill does not need a plugin merely because the new format exists. A single MCP server for a single client may be simpler as mcp.json alone.

Once the boundary is clear, follow this sequence:

1. Write the skill as a standalone component. It should tell a compatible agent what job it owns, what inputs it expects, how it uses available tools, and what a useful result looks like.
2. Add only the MCP servers that the capability needs. Keep tool descriptions, schemas, errors, and side effects inside the server's contract. Agent Plugins packages the server configuration; it does not rewrite MCP's execution semantics.
3. Create the minimal plugin.json. Use the 1.0.0 schema and a stable name. Do not turn the manifest into a second configuration language.
4. Add client extensions last. Use a reverse-domain namespace for a client-only integration. Keep the plugin usable when that directory is ignored.
5. Test it in each claimed client. A package can conform to the format while a particular client lacks a feature the package relies on.

This order matters because it keeps the reusable artifact honest. If the capability only works after a client-only extension runs, it is not yet portable in the way the package suggests.

The boundaries of the v1 specification

Agent Plugins 1.0 deliberately excludes installation, distribution, permissions, sandboxing, trust and provenance verification, and user experience. Treat those areas as unresolved future work. Google's announcement is unusually direct about that boundary.

This changes how teams should evaluate the format.

Question	Agent Plugins 1.0 answer
Where do skills and MCP server definitions live?	Fixed, portable locations in the package.
How does a user discover or install the plugin?	Not specified.
Which client can run it?	Only clients that support the needed components and transports.
Who may call a write-capable tool?	The MCP server and product access model decide.
Is an extension trusted or sandboxed?	Not specified. Client policy decides.

For a security review, treat a plugin as a distribution unit with no permission boundary. Continue enforcing identity, tenant isolation, authorization, input validation, approval, audit logging, and write safety inside the underlying product and MCP server. A SKILL.md can instruct an agent to seek approval; it cannot enforce approval. A client can present a consent screen; it cannot replace server-side authorization.

For a product decision, it means compatibility claims need specifics. Say “supports Agent Plugins 1.0 skills plus stdio MCP” if that is what a client supports. Do not say “works everywhere.” The specification permits incremental adoption and recognizes that a client may support only part of the standard's component or transport surface. Check the official compatible-clients page and the client's own documentation before publishing support claims.

The relationship to Agent Skills, MCP, and discovery

Agent Plugins packages Agent Skills and MCP; it does not change either protocol.

Agent Skills hold reusable instructions, scripts, and reference material. MCP connects an agent client to tools, data, and services. Agent Plugins provides the directory structure that lets those components ship together. Discovery is another layer again: a catalog can describe and point to a plugin, but a catalog entry is not required to create or use the package.

That layering is useful for planning:

• Use Agent Skills to define how the agent should approach a recurring job.
• Use MCP to expose the tools and data that job needs.
• Use Agent Plugins when those components should be installed and updated as one artifact.
• Use a catalog or marketplace when you need users to find the artifact.

Keeping the layers separate avoids a common implementation error: putting runtime policy in packaging metadata or trying to solve discovery by adding more fields to a plugin manifest.

Version the artifact and test the failure paths

Agent Plugins 1.0 uses a schema version for format conformance and leaves the plugin's own version to authors. Treat both as public contracts. Changing a skill's expected inputs, replacing a server transport, or removing a tool can break an agent workflow even when the directory still loads.

For each release, test the package in the clients you claim to support. Include a missing optional directory, a malformed manifest, an unsupported extension, an MCP server that fails to start, unavailable credentials, denied permissions, and a write that needs user approval. The specification requires clients to handle unsupported components and failures without making the entire plugin disappear. Verify that behavior in every supported client.

The right operational target is not “the zip installed.” It is “the skill loaded, the expected server connected, authorization behaved correctly, and a failure produced a useful diagnostic.”

Where Ginger Labs fits

Agent Plugins is most relevant to Ginger Labs' MCP-as-a-service offering when a SaaS company wants to distribute a set of product skills and selected MCP capabilities as one package for compatible external AI clients. Ginger Labs can manage the MCP infrastructure while the customer decides which product capabilities belong in the package.

The customer still owns the product API, data model, domain rules, user permissions, tenant boundaries, allowed actions, and customer experience. Agent Plugins can make the packaging portable; it does not make those product decisions portable or optional.

Start with one coherent capability and one or two compatible clients. Package the skill and MCP server together only when they form a useful unit. Declare any client-only feature as an extension, verify the runtime and authorization behavior in each client, and keep the security controls in the product layer. That is the promise of Agent Plugins 1.0: build the package once, then reuse it where the underlying components are actually supported.

If you want to expose selected product capabilities to external AI clients without operating the MCP infrastructure yourself, bring the workflow to a 20-minute Ginger Labs demo. We can scope the package, the server boundary, and what your product should continue to enforce.

Sources

• Agent Plugins package your skills, tools, and more, Google Developers Blog, August 6, 2026.
• Agent Plugins Specification 1.0.0, Agent Plugins. Accessed August 7, 2026.
• Compatible Clients, Agent Plugins. Accessed August 7, 2026.