Speakeasy now ships plugins in the Agent Plugins format

This week, OpenAI, AWS, Microsoft, GitHub, Cursor, and Vercel released Agent Plugins 1.0, an open standard that packages the two building blocks of agent customization, agent skills and MCP servers, into a single distributable plugin.

Speakeasy now publishes managed plugins in this format. If you distribute skills and MCP access to your team through Speakeasy, your next publish produces one portable package that installs across compatible agents, starting with Cursor and Codex. Nothing about your publish flow, marketplace entries, or existing installs changes.

What is the Agent Plugins standard?

Agent Plugins defines a common package format for agent extensions. A plugin is a directory with a manifest and fixed locations for its components:

my-plugin/
├── plugin.json          # plugin identity and spec version
├── mcp.json             # MCP server definitions
└── skills/
    └── deploy-runbook/
        └── SKILL.md

The manifest is minimal. A $schema field pins the spec version and a name identifies the plugin:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "acme-platform",
  "version": "0.1.42",
  "description": "Acme's internal platform skills and MCP servers"
}

Agents that support skills discover them under skills/, in the standard Agent Skills format. Agents that support MCP read server definitions from mcp.json, which covers stdio and Streamable HTTP transports. Agent-specific behavior layers on top through reverse-domain namespaces (for example com.example.client), so the portable core stays portable.

The spec is deliberately narrow. It standardizes the package and leaves installation, distribution, marketplaces, permissions, and credential handling to each agent. Governance is shared: core maintainers come from Amazon, Cursor, Microsoft, OpenAI, and Vercel, and the project charter prevents any single vendor from holding a majority of seats. Agents shipping support at launch include ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code.

What's changing in Speakeasy

Until now, publishing a plugin from Speakeasy generated a separate package for each agent your org uses: one for Claude Code, one for Cursor, one for Codex, one for OpenCode. Each package restated the same skills and MCP configuration in a different agent-specific format.

Compatible plugins now publish as one shared Agent Plugins package instead:

• One package per plugin. The portable core (plugin.json, mcp.json, skills/) is generated once and consumed by every agent that supports the standard.
• Backwards compatible by default. Cursor has recognized the portable format since version 3.13, and Codex began shipping support in 0.146. Older releases of both install through legacy manifests (.cursor-plugin/plugin.json, .codex-plugin/plugin.json, and a legacy .mcp.json) bundled in the same package directory, so teams that lag on agent updates keep installing without any conditional logic on our side or yours.
• Same marketplace entries. Your existing Cursor and Codex marketplace entries keep their names and identities. They now point at the shared package, so users see one plugin, not a duplicate "portable" variant.
• Direct download. Compatible plugins can be exported as a standards-conforming Agent Plugins ZIP from the dashboard or the API. The archive is flat, with plugin.json at the root and no agent-specific manifests inside. The package is yours to take anywhere the standard is supported.
• Pinned to the published spec. Packages are generated and validated against an exact published revision of the 1.0.0 spec and its JSON schemas, from a local copy. An upstream edit can't change what your publish produces.
• Compatibility is explicit. If a plugin can't be represented faithfully in the 1.0 format, the dashboard says so and that plugin stays on the provider-native path. Export is all or nothing. We never publish a partial package that silently drops one of your servers, and requesting a ZIP of an incompatible plugin returns an error rather than a partial archive. Compatibility is reevaluated on every publish, so a plugin that gains an incompatible server falls back to the provider-native packages under the same marketplace identity, and returns to the shared package once it's compatible again.

Claude Code and OpenCode packages remain provider-native for now, as do observability hooks, which sit outside the 1.0 component model. As agents adopt the standard, plugins you've already published through Speakeasy become installable there without any regeneration work.

Credentials never ship in the package

A plugin package gets copied, cached, and committed to repositories, so the standard treats everything in it as visible data. We follow that strictly. Portable mcp.json files contain server URLs and transport types only:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "acme-platform": {
      "type": "streamable-http",
      "url": "https://mcp.example.com/acme-platform"
    }
  }
}

No API keys, no Authorization headers, no environment variable placeholders. Authentication happens in the agent through OAuth, where the user completes the flow and the agent stores the token. A private MCP server without OAuth support makes the whole plugin ineligible for portable export, and so does a server that requires user-supplied credential headers, because the 1.0 format has no safe way to reference a secret. The dashboard flags every affected plugin. A skills-only plugin is always eligible, since an empty server list is valid.

Get started

There's nothing to migrate. The next time you publish, compatible plugins ship in the new format automatically, and the compatibility status of every plugin is visible in the dashboard. To export a plugin for an agent we don't yet manage, use the Agent Plugins ZIP download on the plugin's detail page.

Distributing skills and MCP servers across a team of mixed agents? Book time with our team and we'll walk through it.