Agent Plugins 1.0 standardizes the package, not the trust decision

On August 6, 2026, Google said it was joining the Agent Plugins project as a Core Maintainer, represented by Kevin Hou. Google described Agent Plugins 1.0.0 as an open, vendor-neutral specification for packaging two existing component types into portable plugins: Agent Skills, which contain reusable instructions and resources, and Model Context Protocol (MCP) servers, which connect clients to tools and services. It said a technical steering committee of Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel published the specification. The version is 1.0.0, but the normative specification still has Working Draft status.

For an engineering or platform lead, the format can remove one source of client-by-client rework. Approval, permission parity, and universal runtime support stay outside its scope. The useful decision is narrower: identify which files can travel unchanged, then test the same bundle in two target clients before calling it reusable.

The portable unit is one directory with fixed component locations

The specification defines a plugin as one directory rooted at one filesystem location. A root plugin.json file is mandatory, and a client must load and validate it before component discovery or client-specific behavior. Skills go in skills/, while MCP server configuration goes in root mcp.json.

Those fixed locations remove several translation problems. A client does not need to infer where components live, read an alternate manifest shape, or guess an MCP transport from the structure of a configuration object. The manifest cannot move components or declare them inline.

Skills and MCP servers also have separate failure boundaries. If mcp.json is invalid, the client disables MCP for that plugin and continues to load other supported component types. If one MCP server cannot start, connect, authenticate, or complete its handshake, the client skips that server, continues loading, and should report the failure. A server failure does not make a valid skill unavailable.

This package shape is the portable part. Google says the format exists for components that belong together and need to travel together. A single skill does not need a plugin, and one MCP server for one client is usually simpler on its own.

The shared core ends where a client extension begins

The core contains plugin.json, skills under skills/, and MCP servers in mcp.json. A client can add its own behavior through a reverse-domain namespace, such as com.example.client. Client-specific manifest data goes under that name in the extensions object, and client-specific files can go in a top-level directory with the same name.

The namespace belongs to the client that defines it. The specification assigns no portable discovery, validation, loading, or failure behavior to extension files or data. A client that does not implement a namespace must ignore its manifest entry without validating its contents. This lets one package carry a shared core and local hooks without making those hooks part of the cross-client promise.

For a platform team, portability should describe the behavior that survives when an unsupported extension is ignored. If a required approval hook, command, or subagent exists only in one client namespace, that part of the workflow remains client-specific. The directory can still move, but the full operating behavior does not move with it.

A compatible client can support only part of the format

The project’s compatible clients page lists Cursor, Kiro, GitHub Copilot, VS Code, and ChatGPT & Codex. The same page says clients can adopt portable component types incrementally and document the components and MCP transports they support. A listing therefore shows format adoption, not full feature or runtime parity.

Transport support is one concrete source of difference. The specification says a client that supports plugin MCP servers must support at least one of stdio or Streamable HTTP and should support both. Legacy HTTP+SSE support is optional. Agent Plugins does not define transport fallback after a failed connection, so a server that works through one transport in one client can still require review in another.

Installation and exposure can differ too. One client can load a skill but present it to users or models in a different way. Another can accept the package while omitting an unsupported component type. Discovery remains a separate layer that happens before invocation, as explained in our article on agentic resource discovery; support for the package format does not create a common marketplace or installation flow.

Google says Agents CLI and Data Agent Kit supported the format on August 6. Its post says it expects to add support to more Google products, but gives no rollout schedule. The specification repository shows a July 24 publication commit, a July 27 merge of the 1.0.0 publishing change, and an August 6 commit that describes Agent Plugins as an open standard. As of August 7, the repository had no tags or published releases. Pin and review the source revision you test instead of treating the version number as proof of an immutable release.

Package containment does not restrict a running subprocess

Agent Plugins requires package-supplied paths to resolve inside the plugin root. The rule also applies through symbolic links and equivalent filesystem mechanisms. A package cannot use a relative path that escapes its root to supply another file.

The specification applies the narrowest failure boundary it can. An invalid plugin.json can reject the plugin. An invalid fixed component location invalidates that component type while other supported types continue to load. A skill that escapes the root is skipped, an invalid MCP entry is skipped, and other escaping package paths are denied.

These checks contain files supplied by the package. The specification explicitly says they do not sandbox a plugin subprocess or restrict paths supplied at runtime. A valid MCP server can still start a process, receive environment variables, make network requests, or access files according to the controls of the host client and operating system.

The same limit applies to trust. Agent Plugins 1.0 defines no installation mechanism, distribution protocol, permission model, sandbox requirement, trust or provenance check, or common user experience. OAuth discovery, credential storage, permission prompts, process isolation, logging, updates, and removal remain client-managed. Teams still need a separate inventory and security review and local AI workflow controls before a plugin reaches sensitive systems.

Test one unchanged bundle in two intended clients

The smallest useful compatibility test uses the two clients the team plans to support. For a constructed test, put one simple skill and one non-mutating MCP server in the same plugin. Make the skill return a known instruction and make the server return a fixed value without file writes, credentials, or network access. Add one optional extension for the first client, but do not make the shared workflow depend on it.

First, read each client’s support documentation and select a component set and MCP transport that both clients claim to support. If they have no common transport for the required server, the bundle has already found a real compatibility limit. Do not hide that limit with a different mcp.json for each run.

Next, load the same source revision and unchanged directory in both clients. Confirm that each client validates plugin.json, discovers the skill, starts the MCP server with the declared transport, and returns the expected fixed result. Confirm that the first client can use its extension and that the second client ignores the unknown namespace while the shared components continue to work.

Then cause the test MCP server to fail at startup for one run. Both clients should report the server failure and keep the skill available. This checks a specified failure boundary that matters when a bundle carries more than one component.

Finally, review the local behavior in each client. Record how the plugin is installed, which permission prompts appear, and what environment reaches the process. Check credential storage, filesystem and network access, sandboxing, updates, and removal. Differences are expected. Each local owner must decide whether those differences are acceptable.

A passing result means the same reviewed package revision delivered the required shared behavior in both clients, the optional extension stayed optional, and each client’s runtime controls passed local review. It does not prove that a third client will work or that the two tested clients enforce the same permissions. If the test moves toward a live business process, process automation should keep the first implementation bounded to one workflow, one owner, and explicit failure handling.

Use the format when related components need to travel together

Agent Plugins 1.0.0 gives skills and MCP servers a small, predictable package with clear component and path failure boundaries. That is useful when a team maintains related components for more than one client and wants one source-controlled core instead of divergent wrappers.

Use the format when those components belong together and need to travel together. Keep a lone skill or single-client MCP server in its simpler native form. Treat a bundle as reusable only after its unchanged core passes the two intended clients and each client’s owner reviews transport, permissions, provenance, sandboxing, and runtime access. Package portability reduces duplicate integration work. The trust decision still belongs to every destination.