What Are Agent Plugins and How Do They Change AI Capability

Short answer: Agent Plugins is an open standard for packaging Agent Skills and MCP servers into one folder that works across several AI agents. It was published on August 6, 2026, its initial steering committee brings together Amazon, Cursor, Microsoft, OpenAI and Vercel, and VS Code, GitHub Copilot, Cursor, ChatGPT and Codex, Kiro and other clients already load it.

Agent Plugins is an open standard that defines how to package an AI agent's capabilities so they work in different tools without rebuilding them. Think about how you add an extension to your browser: you install it once and you're done. An Agent Plugin does the same for your coding assistant or agent. It's a folder with a plugin.json file, some reusable instructions (Agent Skills) and, when needed, the configuration for MCP servers (Model Context Protocol, the protocol that connects an agent to outside tools). Version 1.0.0 shipped on August 6, 2026.

It doesn't replace MCP. It wraps it. MCP still handles how the agent talks to a tool while it runs. Agent Plugins handles something more boring and just as necessary: how that tool gets packaged so someone else can install it in a different client.

What problem does Agent Plugins solve?

If you've ever built an MCP server, you already know the pain. It works in your editor, your teammate uses a different one, and the setup changes: another folder, another file name, another way to declare variables. You end up maintaining several copies of the same thing.

The standard's own site puts it this way: every agent client built its own plugin format, even when the plugins held the same components inside. Agent Plugins defines a shared floor only for the parts that can be portable. Installation, permissions, distribution and user experience stay with each client.

That's a deliberately modest goal. The standard isn't trying to be an app store or a permission system. It's an agreement about where each file goes.

Who's behind the standard?

According to agent-plugins.org, the initial Technical Steering Committee has Core Maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel. In its launch post, Vercel says it started the proposal, and that representatives from AWS, Anysphere (the company behind Cursor), GitHub, Microsoft, OpenAI and Vercel refined it into version 1.0.0.

The project is openly licensed and developed in public. Proposals are discussed in GitHub Discussions, and governance lives in the specification repository.

One absence stands out. Anthropic, the company that created MCP and Agent Skills, isn't part of the group, as The Decoder pointed out when it covered the launch.

How does an Agent Plugin work inside?

A plugin is a folder with one required manifest and optional components in fixed locations:

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       └── SKILL.md
├── mcp.json
└── com.github.copilot/
    └── hooks/

Each piece has one job.

plugin.json identifies the plugin. Only two fields are required, the schema and the name:

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

You can add a version, description, author, license and keywords. The name uses lowercase letters, digits, hyphens and periods, up to 64 characters. An unknown field doesn't break the plugin: the client reports it and ignores it.

skills/ holds the Agent Skills. Each skill lives in its own subfolder with a SKILL.md file. In practice a skill is a written recipe: it tells the agent how to do a task, and it can bring scripts and reference files along. The Agent Skills specification defines that format, not Agent Plugins. If one skill is broken, the client skips it and loads the rest.

mcp.json declares the MCP servers. It supports three connection types: stdio for a program running on your machine, streamable-http for a remote service, and sse, the older HTTP+SSE transport, which the spec marks as deprecated and optional for clients.

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

The client fills in two variables: ${PLUGIN_ROOT}, the plugin folder, and ${PLUGIN_DATA}, a data folder that survives updates. One security detail matters here. HTTP headers in mcp.json are visible package data, so the spec forbids putting credentials there. Each client handles authentication on its own.

Folders named with a reversed domain are for one client's extras. For example, com.github.copilot/ holds hooks and custom agents that only Copilot understands. Other clients ignore that folder, so the package stays portable and loses nothing in Copilot.

What's the difference between Agent Plugins, MCP and Agent Skills?

They get announced together and mixed up a lot. The difference is what each one does:

A plugin can carry several skills, several MCP servers, or just one of the two. For the person installing it, it's a single step.

It also has nothing to do with the old ChatGPT plugins, apart from the name. Those were integrations for ChatGPT alone. Agent Plugins is an open specification any client can implement.

Which clients support Agent Plugins today?

As of October 19, 2026, the compatible clients page on agent-plugins.org lists VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot, NanoClaw and OpenHands. All of them load Agent Skills and MCP servers over stdio and Streamable HTTP. Support for the older SSE transport depends on the client.

Source: the agent-plugins.org compatible clients page, checked October 19, 2026.

Claude isn't on that list. Even so, VS Code reads Claude Code's plugin format (a .claude-plugin/plugin.json file), along with Copilot's own format and the standard.

How it works in VS Code

VS Code support is no longer "under development". Its documentation describes full support, and GitHub announced on August 12, 2026 that it was generally available on all Copilot plans in VS Code, Copilot CLI and the Copilot app.

What you can do today:

• Turn it on or off with the chat.plugins.enabled setting.
• Install from a marketplace. In the Extensions view, search for @agentPlugins. The copilot-plugins and awesome-copilot marketplaces come by default, and you can add more with chat.plugins.marketplaces.
• Install from a Git URL with the Chat: Install Plugin From Source command.
• Manage plugins from chat with /plugin in a Copilot session: /plugin list, /plugin install, /plugin update and more.
• Reuse what you installed in the terminal. VS Code automatically picks up plugins installed with GitHub Copilot CLI.

One warning the docs call out: a plugin can include hooks and MCP servers that run code on your machine, and its MCP servers don't show a separate trust prompt at startup. Review the contents and the publisher before you install, especially from a community marketplace.

Nov 2026: when an app installs plugins for you

Plugins are easy to install, and that also means another app on your computer can install one for you. A public GitHub issue on the Postman app repository, postmanlabs/postman-app-support #14370, shows what that looks like in practice. Everything below comes from user reports in that thread, not from a security audit.

What users reported:

• Postman desktop 12.33.4 (October 2026). The original report quotes Postman's own log: after the app opened, an auto-existing-upgrade step recorded claude-code:installed and codex:installed.
• Postman desktop 12.35.1 (November 3, 2026). A second user saw the same step install the Claude Code and Codex plugins and the Postman CLI. Cursor already had the plugin from before, logged as cursor:already-installed.
• Copilot. Another user found a Postman marketplace and "postman@postman": true in ~/.copilot/settings.json.

Where the plugin showed up:

• Claude Code: postman@claude-plugins-official enabled in ~/.claude/settings.json.
• Codex: a [plugins."postman@postman"] entry with enabled = true in ~/.codex/config.toml, plus a Postman marketplace entry.
• A SessionStart hook: text injected when an agent session starts, telling the agent to load a Postman skill for most API work.
• A remote MCP server at mcp.postman.com, which asked for authentication.

A reply in the thread from a Postman account said the plugins and CLI are bundled with the desktop app to make setup easier, that the download page and update flow mention it, and that the team will "make the opt-in clearer, especially for existing users" and review the hook approval and session start behavior. The reporters were explicit about one limit: they found no evidence that data was uploaded.

How to check your machine:

1. Open ~/.claude/settings.json and look for postman under enabled plugins.
2. Open ~/.codex/config.toml and look for [plugins."postman@postman"] and [marketplaces.postman].
3. Open ~/.copilot/settings.json and look for postman in enabledPlugins or extraKnownMarketplaces.
4. In Cursor, check your installed plugins and MCP servers for Postman.

How to remove it: users point to the menu entry Help > Postman CLI and Plugins > Uninstall Postman Coding Agent Plugin inside the app. One user reported it did not remove the Copilot entry, so check each file again afterwards and delete any leftover Postman lines yourself. Also remove the postman executable from ~/.local/bin if you don't use the CLI.

The broader lesson applies to any plugin, not just this one: a plugin can carry hooks and MCP servers, and those change what your agent does. Check your agent config files from time to time, the same way you'd review browser extensions.

The verdict: who is Agent Plugins for?

It's for you if you build tools for agents that your team uses in different editors, or if you publish skills and MCP servers for other people. You package once, and everyone installs it where they work.

You can wait if you use a single client and its own system already covers you. Adding another layer doesn't buy you anything yet.

One obvious risk is fragmentation: each client adding its own extras until portability breaks. The 1.0 design answers exactly that. Extras live in reversed domain folders that other clients ignore, so a client can go further without breaking the shared core. That doesn't guarantee everyone follows the rule, but it does make clear where each thing belongs.

The other risk is security. Installing a plugin can mean running code, and the spec leaves permissions and installation to each client. Treat it like any dependency: check who publishes it and what it runs.

How do I start building an Agent Plugin?

1. Create a folder with a plugin.json that declares the 1.0.0 schema and a name.
2. Add a skill at skills/your-skill/SKILL.md.
3. If your plugin needs tools, declare your MCP servers in mcp.json.
4. Put extras for one client in its reversed domain folder, such as com.github.copilot/.
5. Test it in a compatible client. In VS Code, install it with Chat: Install Plugin From Source pointed at your repository.

If you're coming from a Copilot plugin, GitHub says migrating is mostly manifest work: add $schema, keep skills in skills/ and MCP in mcp.json, and move Copilot specific files into com.github.copilot/. The Agent Plugins example repository includes a skill that helps with that migration.

Go deeper

• What is Kitesurf, Cloudflare's browser built for agents
• What is Stagehand, the SDK for agents that drive a browser
• Our picks of tested AI tools, sorted by the job you need done

If you already code and want to build agents that use skills and MCP servers like these, see how AI Flex works. You learn at your own pace, with an AI tutor and mentors.