agent plugin
An agent plugin is an installable package that extends an AI agent by bundling reusable capabilities: typically skills (workflow instructions), one or more Model Context Protocol (MCP) servers or connectors, and harness-specific extras such as hooks, rules, commands, or subagents, so a team can distribute a whole capability in one install rather than wiring each piece by hand.
Through the Agent Plugins standard, an MCP host exposes capabilities. Cursor, Claude, and ChatGPT use a plugin to bundle that backend and related abilities, so any admin or user can grab it from a repo or marketplace.
What makes it a complication: “plugin” isn’t a single thing. Each harness, meaning the application that runs the agent and decides what loads, has its own manifest, its own component list, and its own marketplace, and the same word covers meaningfully different things across Cursor, Claude, and ChatGPT. A Agent Plugins spec defines one portable base all 3 now use more, while every harness still adds its own extras. This entry defines the shared idea, then spells out how each harness uses it.
How is an agent plugin different from an MCP server?
A server for MCP is software that’s active. It exposes functions, data, and prompts to a program through a protocol, runs on a channel (STDIO locally or Streamable HTTP at a URL), and performs the real task when the program invokes a function. A plugin isn’t an active application. It’s a directory holding its manifest, and contains an mcp.json entry that tells the system which hosts to use and how.
MCP shows what can be done and how. Plugins solve distribution: how those tools, plus the skills that teach the agent to use them well, plus whatever harness-specific configuration the workflow needs, reach a hundred machines with one install and stay updated together under one version.
What is the Agent Plugins standard?
The Agent Plugins specification is vendor-neutral and covers the software, issued at 1.0 during August 2026 from a team with maintainers at Amazon, Cursor, Microsoft, and OpenAI, plus Vercel. It fixes a setup any compatible harness can use: up top, a plugin.json manifest that identifies the plugin and pins its spec, plus an mcp.json with definitions for Streamable HTTP transports and STDIO, and folders in the skills/ directory using Agent Skills style. Harness-specific actions sit above it under reverse-domain namespaces like com.example.client, keeping the portable part portable.
The spec is kept tight. It standardizes the bundle, while each harness manages setup, sharing, marketplaces, permissions, and credential use. That divide explains why the parts below still vary. One conformant add-on installs for Cursor, Codex, ChatGPT, GitHub Copilot as well as Kiro and VS Code as is, but this harness sets which parts run later, who checked its page, and if any admin can make it mandatory. Claude plugins have a separate manifest, detailed below.
What is a Cursor plugin?
As the docs for Cursor plugins note, both formats work in Cursor:
- Agent Plugins are spec-conformant packages in the format described above, with
plugin.jsonat the plugin root, carrying skills and MCP servers. Cursor has read the portable format since version 3.13, so any conformant plugin loads without changes. - Cursor Plugins use a
.cursor-plugin/plugin.jsonmanifest and add Cursor-specific components: rules (.mdcguidance files), custom agents, commands, hooks, and variables.
Both come through Cursor Marketplace, with every page checked before it goes live, or via internal marketplaces for Teams and Enterprise. Marketplaces handle control: admins limit who gets every plugin and pick Required or either Default Off or Default On; under Required, it stays in place and can’t be uninstalled.
What is a Claude plugin?
A Claude plugin is a directory identified by a .claude-plugin/plugin.json manifest that bundles skills, connectors (Anthropic’s word for MCP servers in its apps), subagents, and hooks. In Claude Code, the same package can also carry LSP servers, background monitors, executables, and default settings, and plugins install from GitHub-backed marketplaces: Anthropic’s official and community catalogs, or a private repository a team controls.
In the Claude apps, the plugin surface is thinner in chat than in Claude Cowork. A plugin installs from the Customize menu, and its skills work in chat on the web, the desktop Chat tab, and Cowork, while hooks and subagents run only in Cowork (and in Claude Code). With Team and Enterprise, admins distribute plugins via company marketplaces and can set one as mandatory, so it installs for all users and prevents uninstalls.
What is a ChatGPT plugin?
For OpenAI’s setup now, each plugin sits in the directory shared by ChatGPT and Codex. A plugin can have procedures, an MCP server, or both: procedures show the AI a repeatable workflow, while the MCP server provides current information, authentication, and limited tasks. A MCP-backed plugin may also include UI assets for places that run MCP Apps. The manifest lives at .codex-plugin/plugin.json, with skills/, hooks/, and MCP configuration at the package root.
It carries baggage. The phrase “ChatGPT plugin” also means OpenAI’s 2023 OpenAPI manifests toolset, discontinued in 2024. They have only the name in common: the new setup uses MCP to handle tool access, while Agent Skills gives guidance, with one plugin from the current directory as those parts, rather than any OpenAPI wrapper.
How do plugins, skills, connectors, and hooks fit together?
The parts stack cleanly once the labels are split. A skill is workflow steps kept in the folder SKILL.md. The backend an assistant reaches out to is the connector or MCP. A lifecycle handler runs at set times during a session, as described by AI agent hooks. A plugin bundles any mix of them with one label and one release, so they distribute and update together.
| Harness | What “plugin” means | MCP role | Extra components |
|---|---|---|---|
| Cursor | Agent Plugins (portable) and Cursor Plugins (native) | Bundled mcp.json server definitions | Skills in both; Cursor Plugins add rules, agents, commands, hooks, variables |
| Claude | Installable package for Code, Cowork, and chat | Connectors are MCP servers | Skills, subagents, hooks; Code adds LSP servers and monitors |
| ChatGPT | Package in the shared ChatGPT and Codex directory | MCP server is an optional component | Skills, optional UI resources, lifecycle hooks |
In real terms, claiming “we support plugins” means very little unless you find out what a harness really runs. An add-on that runs end to end with Claude Code may load in a conversation with only its abilities on; for any Cursor Plugin’s guidelines or hooks, nothing moves to another harness.
Why do security teams care about agent plugins?
One marketplace setup dropping a config onto each machine can also drop an unreviewed MCP service or plugin onto each machine.
- They are the fleet-distribution mechanism. Hooks are the interface for governing coding agents from inside the agent, and a hook config on one laptop is worthless if the other 999 laptops lack it. Every major harness now has a required-install mode: Cursor’s Required plugins, Claude’s organization-required plugins, and managed settings that force-enable a marketplace. A required plugin is how agent hooks and observability reach every machine without a per-laptop setup step.
- They install local MCP servers. A plugin’s
mcp.jsoncan define a STDIO server that runs on the laptop and never crosses the MCP gateway, so a marketplace install can quietly widen the tool surface outside the governed path. That is the shadow MCP problem arriving through a sanctioned channel. - They carry ungoverned instructions. A plugin’s skills arrive as markdown, fire no procurement event, and steer agent behavior on every matching task. Skills governance covers why that surface needs an owner, a review, and a revocation path of its own.
Marketplace checks can help, but coverage varies with each harness, while in-house marketplaces leave the work with the company. When checking MCP hosts, defenders must know the same thing about plugins: what’s loaded, where, and holding which contents.
How does the Speakeasy AI Control Plane work with agent plugins?
The Speakeasy AI Control Plane uses plugins as its distribution layer rather than shipping a custom installer. From Distribute > Plugins, an admin bundles MCP servers and skills into managed plugins, assigns them to roles, and publishes them to Claude Code, Cursor, and Codex marketplaces through a GitHub-backed marketplace the platform hosts on the org’s behalf.
Compatible plugins publish in the Agent Plugins 1.0 format, so one portable package installs across agents that support the standard, with legacy per-harness manifests bundled for older releases. Credentials aren’t stored in bundles: portable mcp.json lists only service URLs and connection kinds, while authentication runs inside the app via OAuth. Those hook configurations powering policy and tool logging are what the platform’s observability plugin carries; since it ships through every harness’s plugin setup, an admin can make it mandatory, and all machines get controls at the following run, using MDM instead.
Use a single plugin release to distribute MCP know-how and rights across varied tools, then talk with us.