Back to feed
News Story
APriority81
THE DECODER
2 sources

Amazon, Cursor, Microsoft, OpenAI, and Vercel Unite on Shared Standard for AI Agent Plugins

Amazon, Cursor, Microsoft, OpenAI, and Vercel have jointly created Agent Plugins, an open standard that defines a single package format for AI agent extensions. Version 1.0.0 uses a plugin.json manifest file and supports both agent skills and MCP servers. This initiative aims to foster interoperability in the AI agent ecosystem.

SynthePulse Insight · AI deep reading

Agent Plugins Open Standard: A New Paradigm for AI Agent Plugins—Build Once, Run Everywhere

Version 1 · 1 source

OpenAI, AWS, Cursor, GitHub, VS Code, and Vercel have jointly launched the Agent Plugins open standard, packaging Agent Skills and MCP server configurations as portable plugins, aiming for 'build once, run everywhere.'

  • Agent Plugins is an open standard driven by OpenAI, AWS, Cursor, GitHub, VS Code, and Vercel.
  • Core model: A plugin is a plain filesystem directory, not an archive or registry entry.
  • v1 only supports two component types: Skills and MCP servers, excluding client-specific types like commands and hooks.
  • Security-critical constraint: Path containment—any file must resolve within the plugin root directory to prevent directory traversal.
  • Runtime isolation and data persistence are achieved via PLUGIN_ROOT and PLUGIN_DATA environment variables.
  • Client extensions are mounted via reverse-domain namespaces, avoiding centralized registries.
Open section navigationStandard Background and Core Goals

Standard Background and Core Goals

Agent Plugins is an open standard jointly promoted by OpenAI, AWS, Cursor, GitHub, VS Code, and Vercel. Its core goal is to package Agent Skills and MCP server configurations into portable plugins, enabling a plugin built once to work across multiple AI agent clients.

The standard is published via agent-plugins.org, emphasizing the 'build once, run everywhere' philosophy, aiming to solve plugin interoperability issues in the AI agent ecosystem.

Core Model: Directory as Plugin

The specification defines that a plugin is not an archive or registry entry but a plain filesystem directory. This design allows inspection with standard tools like ls, cat, and git, and supports in-place editing and version control.

The plugin directory structure includes a required plugin.json manifest file, plus optional skills/ directory, mcp.json file, and client extension directories (e.g., com.example.client/).

Three key constraints: fixed-location discovery (skills/ and mcp.json locations are not configurable), path containment (all files must reside within the plugin root), and v1 only supports two component types: Skills and MCP servers.

Manifest File and Error Handling

plugin.json uses a closed schema, allowing only ten top-level fields, of which only $schema and name are required. Naming constraints: 1-64 characters, only lowercase letters, digits, hyphens, and dots, and must start and end with alphanumeric characters.

Error handling is tiered: unknown top-level fields are non-fatal (reported and ignored), while other schema violations are fatal (reject the entire plugin). Clients must not fetch schemas over the network during loading to avoid network dependencies and supply chain risks.

Failure isolation principle: if plugin.json escapes the root, the entire plugin is rejected; component type errors disable only that component; a single non-compliant SKILL.md skips only that Skill; an invalid MCP server skips only that entry.

Component Handling and Runtime Model

Skills components do not redefine the format; they directly reference the external Agent Skills specification, only specifying discovery location (SKILL.md in direct subdirectories of skills/) and failure isolation.

MCP servers are defined via mcp.json with a closed union of transport types: stdio, streamable-http, and sse (deprecated, optional support).

The runtime model centers on PLUGIN_ROOT and PLUGIN_DATA environment variables: PLUGIN_ROOT points to the plugin root directory, and PLUGIN_DATA is a client-managed writable persistent directory that survives updates. Placeholders are expanded only in args, env, and cwd, and env must not override these two variables.

Client Extensions and Decentralization

The portable core remains minimal; client-specific capabilities are mounted via reverse-domain namespaces, such as com.example.client. Manifest data goes in the extensions field of plugin.json, and files go in a top-level directory with the same name.

Clients ignore and do not validate namespaces they do not implement, avoiding centralized registries, consistent with Java package names and Android application IDs.

Credibility boundary

This report is based on a repost by user meng shao on platform X, with the original source being the agent-plugins.org specification page. All technical details come from that reposted text and have not been directly confirmed by officials, but the content is detailed and consistent with common open standard designs.

Insight takeaway

The Agent Plugins standard provides a pragmatic solution for AI agent plugin interoperability through its directory-as-plugin model, strict path containment, and failure isolation, but v1 only supports Skills and MCP, and future expansions are worth watching.

Primary report

THE DECODER

Primary source

Same-event coverage

Also covered by 1 sources