What Are Agent Plugins and How Do They Change AI Capability

Agent Plugins, an open standard announced on August 6, 2026, by OpenAI, Microsoft, Amazon, Cursor, and Vercel (with Google as a Core Maintainer from day one), defines a portable package format for distributing Agent Skills and Model Context Protocol (MCP) server configurations. In essence, it allows you to create an agent extension once and have it work across VS Code, Cursor, GitHub Copilot, ChatGPT, Codex, and any other compatible client, without rewriting integrations for each platform. It doesn't replace MCP but rather encapsulates it: MCP continues to manage the runtime connection with external tools, while Agent Plugins standardize how that configuration is packaged, versioned, and distributed.

If you've built with MCP, you already understand the problem. You create a server that connects your agent to a database, an internal API, or a browser, and it works perfectly in Claude Desktop. But when your teammate wants to use it in Cursor, or when you try to deploy it in an agent workspace like Buzz or Cloudflare OS, the configuration differs everywhere. Different paths, environment variables injected in various ways, incompatible manifests. Agent Plugins solves this by proposing a common folder structure, a plugin.json file describing the package's function, and an mcp.json configuring the associated MCP servers. The compatible client (the IDE, chatbot, or workspace) reads these files and sets up the environment without further intervention from you.

Why Are Agent Plugins Emerging Now, and Who Is Behind Them?

The context for Agent Plugins is the fragmentation that has accompanied the widespread adoption of MCP. Anthropic reported in August 2026 over 10,000 active public MCP servers and more than 97 million combined monthly downloads of its SDKs. When a protocol grows to this extent, a new layer of problems emerges: how to share configurations across teams, how to version them, and how to install them in a new client without ad-hoc documentation. Agent Plugins is the major players' answer to this social, rather than technical, scalability challenge.

The alignment of companies is remarkable. OpenAI, Microsoft, Amazon, Cursor, and Vercel form the initial technical committee. Google joined on the announcement day as a Core Maintainer, committing to integrate support into its products. This signifies a standard backed by all platforms where agents are truly used in production: from IDEs (VS Code, Cursor) to chatbots (ChatGPT, Copilot) and cloud infrastructure (AWS, Vercel). The official source for the standard is agent-plugins.org, featuring versioned JSON schemas and documentation for plugin authors.

The obvious question is why they aren't directly using the MCP format. The answer lies in the separation of responsibilities. MCP is a runtime communication protocol: it defines how an agent requests a tool and how the server responds. However, it says nothing about how that tool is packaged for distribution, how its dependencies are declared, or how a client installs it. Agent Plugins precisely fills this gap: it's the package.json or setup.py of the agent ecosystem, while MCP is the underlying REST API.

How Does an Agent Plugin Work Internally?

A valid plugin is simply a folder with a defined structure. The mandatory file is plugin.json, which follows this minimal schema:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-analysis-plugin"
}

The $schema key allows clients to validate the manifest and offer autocompletion. The name must be unique within the registry where it's published (though the standard doesn't mandate a single central registry, allowing for multiple).

If the plugin includes MCP capabilities, which is the primary use case, an mcp.json file is added to the root. This file declares the MCP servers the plugin needs, along with their transport type (stdio for local processes, streamable-http for remote services) and configuration:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "schema-validator": {
      "type": "stdio",
      "command": "./bin/validator",
      "args": ["--data", "${PLUGIN_DATA}/validator"],
      "env": {
        "CONFIG": "${PLUGIN_ROOT}/config.json"
      },
      "cwd": "${PLUGIN_ROOT}"
    },
    "deployment-api": {
      "type": "streamable-http",
      "url": "https://deploy.example.com/mcp",
      "headers": {
        "X-Tenant": "public-tenant"
      }
    }
  }

The standard defines environment variables that the client must expand: ${PLUGIN_ROOT} points to the plugin's folder, and ${PLUGIN_DATA} to a persistent data directory for that plugin. This ensures the same plugin works on Windows, macOS, or Linux without modifications, as paths are resolved at runtime.

In addition to these configuration files, the plugin can include Agent Skills: reusable instructions that tell the agent how to use the available MCP tools. For example, a skill might be a "dependency security audit" that combines the code analysis MCP server with a specific prompt about what to look for. Skills are placed in a skills/ folder with their own schema, allowing a plugin not only to connect tools but also to teach the agent how to use them effectively.

What's the Difference Between Agent Plugins, MCP, and Agent Skills?

This trio often causes confusion because they're announced together and address overlapping problem spaces. The key distinction lies in their architectural roles:

A plugin can contain zero, one, or multiple MCP servers. It can also contain zero, one, or multiple skills. A compatible client (such as Cursor, or VS Code with the appropriate extension) discovers the plugin, reads its manifest, starts the declared MCP servers, and loads the skills into the agent's context. From an end-user perspective, installing a plugin is a single step; from a developer's perspective, publishing it once reaches multiple clients.

It's crucial not to confuse this with OpenAI's former "ChatGPT Plugins," which were discontinued in March 2024 and replaced by GPTs. Those were specific integrations for the ChatGPT product, featuring a closed approval model and a particular OAuth authentication system. Agent Plugins, however, is an open, vendor-neutral standard that requires no approval from OpenAI or anyone else to function. If a client implements the standard, the plugins work; if not, they don't. It's a specification, not an app store.

Which Clients Support Agent Plugins Today?

According to the official announcement in August 2026, confirmed clients that are compatible or working towards compatibility include:

• VS Code: Native support is under development, with preliminary documentation available at code.visualstudio.com/docs/agent-customization/agent-plugins
• Cursor: Integration announced as a high priority, given Cursor's role as a Core Maintainer
• GitHub Copilot: Support planned within the existing extension ecosystem
• ChatGPT: Capability to load compatible plugins in work environments
• Codex (OpenAI): Direct integration into the coding agent
• Kiro: An emerging editor that has committed to the standard since its launch

The promise of the standard is that a plugin working in one of these clients should function across all of them, barring documented differences in optional capabilities. This contrasts with the previous situation where each platform had its own extension system: VS Code extensions didn't work in Cursor, ChatGPT's GPTs didn't work in Claude, and Claude's tools didn't work in Copilot. Agent Plugins aims to break down these silos without forcing users to abandon their preferred platforms.

Comparative Table: How Capabilities Are Installed on Each Platform

The practical advantage is clear for teams using multiple tools. Today, if your company has an internal API you want to expose to agents, you need to write one integration for Cursor, another for Copilot, and yet another for the CLI used by DevOps. With Agent Plugins, you write it once, package it as a plugin, and each team member installs it wherever they work. Maintenance is centralized, documentation is simplified, and internal adoption accelerates.

The Verdict: Who Are Agent Plugins For, and What Are the Risks?

This standard is ideal for developers and teams looking to streamline AI agent capabilities across diverse environments. It offers a unified approach to integrating internal tools and managing agent configurations, particularly beneficial for those working with multiple development setups or agent infrastructure.

This standard is for you if:

• You build internal tools that you want to expose to AI agents across multiple platforms (IDEs, chatbots, workspaces).
• You manage teams where different developers use different editors (one on Cursor, another on VS Code, another on Zed).
• You develop products that include agent capabilities and want to offer a unified installation experience to your users.
• You work with agent infrastructure like Cloudflare OS or Buzz and require configuration portability.

This standard is not for you (yet) if:

• You use a single platform, and its native extension system already meets your needs; adding another layer only complicates things.
• You work with agents that don't use MCP, such as legacy direct function calling configurations.
• You need functionalities that the 1.0.0 standard doesn't cover, such as complex end-user authentication or integrated billing; these are marked as "future" in the specification.

Real risks to consider:

1. Standard Fragmentation: While the announcement is multi-vendor, the history of open standards is rife with "embrace, extend, and extinguish" scenarios where each implementation adds proprietary extensions. It remains to be seen whether plugins will truly be portable or if each client will add "extras" that break compatibility.
2. Overlap with Native Systems: VS Code already has extensions, Cursor has project rules, and Claude has projects. Adding MCP plugins could create confusion about where configurations should reside. Teams will need clear internal guidelines.
3. Supply Chain Security: Installing a plugin means executing code (MCP servers are local processes). The standard does not define a plugin signing system or mandatory sandboxing; this is left to the client. We'll have to wait and see how each platform implements origin verification.
4. Adoption Dependency: A standard only works if it's widely adopted. If Claude Desktop never implements it, or does so incompatibly, the "write once, run anywhere" value erodes. The coming months will tell if this becomes the npm of agents or another forgotten attempt.

How Do I Start Building an Agent Plugin?

To begin building an Agent Plugin, the official documentation at agent-plugins.org recommends starting with the 1.0.0 schema and validating your plugin.json against it before distribution. For use cases involving MCP, the typical workflow involves several key steps.

1. Develop and test your MCP server locally using the official SDK (TypeScript or Python).
2. Create the plugin folder with plugin.json and mcp.json pointing to your server.
3. Declare skills in the skills/ folder if you want the agent to use specific patterns with your tool.
4. Test in a compatible client (Cursor and Codex CLI have the most mature support as of August 2026).
5. Distribute as a compressed file or publish to a registry when available.

For developers already working with Kitesurf or Stagehand, the combination is natural: you package your agent-first browser configuration as a plugin and share it with the team without each person having to reconfigure URLs and selectors.

Frequently Asked Questions About Agent Plugins

Does Agent Plugins replace MCP? No. MCP is the communication protocol; Agent Plugins is the packaging format. They work together: the plugin contains the MCP configuration that the client uses to connect.

Do I need to learn a new language to create plugins? No. Plugins are defined in JSON for the manifests. The MCP servers they contain can be written in any language that supports the SDK (Python, TypeScript, Rust, Go).

Is it free to use Agent Plugins? The standard is open and free. Clients that implement it (VS Code, Cursor, etc.) may have their own terms, but the plugin format itself has no cost or restrictive license.

Can I use plugins in Claude Desktop? As of August 2026, Anthropic has not announced official support for Agent Plugins in Claude Desktop. The platform continues to use its native system of manually configured MCP.

What is the difference between an Agent Plugin and a VS Code extension? A VS Code extension is specific to that editor, can directly touch the UI, and is distributed through the Microsoft marketplace. An Agent Plugin is client-agnostic, focuses on agent capabilities (MCP + skills), and theoretically works on any compatible platform.

Is there a central plugin registry? The 1.0.0 standard does not define a single mandatory registry. It allows for multiple registries or direct file distribution. Community or commercial registries are likely to emerge in the coming months.

Is Agent Plugins related to the old ChatGPT Plugins? None, except for the name. ChatGPT Plugins were discontinued in March 2024. Agent Plugins is a completely new, open, and neutral standard, not tied to any specific OpenAI product.

If you want to delve deeper into the AI tools ecosystem for developers, explore our AI Engineering for Developers program, where we work with MCP, code agents, and plugin architectures on real projects. You can also compare our AI specializations on the program comparison page.