Agent Plugins 1.0 Deep Dive: The Portable Standard for Skills + MCP

The Portability Problem Agent Plugins 1.0 Solves

Every agent developer who has shipped real products has hit the same wall. You build a tool that works beautifully in Cursor, then your customer asks for ChatGPT, and suddenly you are maintaining two integration paths. The MCP (Model Context Protocol) standard unified how tools are exposed to models, and Anthropic's Agent Skills format unified how procedural knowledge is authored — but nothing unified how the two get packaged and distributed together.

On August 6, 2026, the TSC Core Maintainers of the Linux Foundation's Agentic AI Foundation (AAIF) shipped Agent Plugins 1.0.0 to close exactly that gap. The spec is vendor-neutral, licensed CC-BY-4.0, and backed by maintainers from Amazon, Cursor, Microsoft, OpenAI, Vercel, and Google. It defines a single, portable directory that bundles Agent Skills and MCP servers under one manifest, so a plugin written once runs in every compliant client.

What Actually Ships in Agent Plugins 1.0.0

The whole spec reduces to one directory convention plus one manifest. A valid Agent Plugin looks like this:

my-agent-plugin/
├── plugin.json          # manifest: name, version, schema, entry points
├── skills/              # Agent Skills subdirectories
│   ├── sql-review/
│   │   └── SKILL.md
│   └── incident-triage/
│       └── SKILL.md
└── mcp.json             # per-server transport declarations

The manifest is the contract. A minimal plugin.json:

{
  "name": "devops-console",
  "version": "1.0.0",
  "description": "Incident triage skills plus GitHub and PagerDuty MCP servers",
  "schema": "agent-plugin/1.0",
  "entryPoints": {
    "mcp": "./mcp.json",
    "skills": "./skills/"
  }
}

The most consequential design decision is in mcp.json. Unlike early MCP setups where transport was implicit, Agent Plugins 1.0 makes the transport type explicit per server: stdio, streamable-http, or http-sse. A concrete example:

{
  "servers": [
    {
      "name": "github",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "transport": "stdio"
    },
    {
      "name": "pagerduty",
      "url": "https://api.pagerduty.com/mcp",
      "headers": { "authorization": "Bearer ${PD_API_KEY}" },
      "transport": "streamable-http"
    }
  ]
}

Declaring transport up front matters because it lets clients provision the right runtime — a local child process for stdio, an outbound HTTP client for streamable-http — without guessing. It also gives security tooling a deterministic surface to audit: every network egress point in a plugin is now visible in one JSON file.

How Agent Plugins 1.0 Relates to Everything Before It

The spec is deliberately a synthesis, not a green-field invention. It sits on top of several earlier efforts:

Google's contribution deserves extra attention. The AI Catalog treats application/agent-plugins+json as a first-class media type, which means package registries — npm, PyPI, a future agent plugins CLI registry — can advertise plugins as searchable, signed artifacts. Discovery becomes a standards problem instead of a marketplace cold-start problem.

plugin.json vs. the Pre-1.0 Status Quo

Before the spec, most teams distributed agents as either a bare mcp.json plus a docs folder, or an Agent Skill folder with no tool binding at all. The differences are not cosmetic:

The migration story is deliberately cheap. Because the spec is a directory layout plus a manifest, an existing MCP project migrates by adding plugin.json and normalizing the layout — the server definitions themselves are unchanged. Teams running a raw mcp.json today can think of it as 60 percent of an Agent Plugin: the new spec adds the packaging contract, the skills sidecar, and the discovery metadata.

Developer ROI: The Unit Economics of One Package

The business case for Agent Plugins 1.0 is most visible when you model the cost of client fragmentation. Consider a mid-size platform team shipping tool integrations for five clients — VS Code, Cursor, GitHub Copilot, ChatGPT, and Codex (all announced 1.0 clients, alongside Kiro and AWS's Agent Toolkit and Google's Data Agent Kit).

A conservative pre-1.0 model:

Per-client integration effort (setup, auth, transport quirks): 6-10 engineer-days
Five clients:                           30-50 engineer-days
Re-validation on every transport change: 3-5 days per client, every quarter

With Agent Plugins 1.0, the manifest is written once and the integration surface collapses to one directory per client import. That is roughly a 70-80% reduction in integration and maintenance effort, and it removes the single worst tax in the space: the fear that choosing a client locks you into its proprietary skill format.

Security and Governance Implications

Portability solves distribution, but it concentrates risk. A plugin that runs a stdio server executes local code by definition; a plugin that only talks streamable-http is safer in untrusted contexts. The explicit transport field turns this into a policy decision: security teams can gate approvals on transport type, require signed manifests, and lint mcp.json for accidental credential exposure before a plugin ever reaches an agent runtime.

For enterprises rolling out agents at scale, that auditability is the difference between "the platform team blessed a plugin" and "someone pasted a skills folder from a blog post." Treat transport type as a risk level, not an implementation detail.

Where Agent Plugins 1.0 Is Heading

Three trajectories are worth watching in the next 12 months:

1. Registry ecosystems. The application/agent-plugins+json media type plus a signed manifest format makes public registries viable. Expect npm-style plugin catalogs with provenance attestation.
2. Composite plugins. The current spec packages skills plus MCP servers; the natural next revision is plugins that depend on other plugins, with explicit dependency resolution.
3. Client convergence. With VS Code, Cursor, GitHub Copilot, ChatGPT, Codex, and Kiro all declaring support, the argument for a proprietary tool packaging format is close to dead.

Building Your First Agent Plugin

If you maintain an MCP server today, the fastest path to 1.0 compliance:

1. Lay out plugin.json at the plugin root with name, version, and schema.
2. Move any prompt/procedure assets into skills/ using the Agent Skills format.
3. Declare every MCP server in mcp.json with an explicit transport type.
4. Test in at least two clients (e.g., Cursor and Kiro) to catch client-specific quirks early.
5. Publish to a registry or distribution channel that honors application/agent-plugins+json.

# minimal scaffold
mkdir my-agent-plugin/skills my-agent-plugin/skills/onboarding
cat > my-agent-plugin/plugin.json <<'EOF'
{
  "name": "my-agent-plugin",
  "version": "0.1.0",
  "schema": "agent-plugin/1.0",
  "entryPoints": { "mcp": "./mcp.json", "skills": "./skills/" }
}
EOF

The Bottom Line

Agent Plugins 1.0.0 is the rare standard that lowers both integration effort and security risk at the same time, because it makes packaging deterministic and transports explicit. It does not replace MCP — it ships MCP servers in a way clients can actually agree on. For the latest on which clients and registries are adopting the spec, keep an eye on our latest AI news coverage, and for hands-on patterns that combine Agent Skills with MCP tooling, browse the workflows library.

By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.