Earlier this month, Vercel released Agent Plugins 1.0.0 with core maintainers from AWS, Cursor, Microsoft, and OpenAI, joined the same day by Google. The format solves a genuine pain point: developers no longer need to fork and maintain separate versions of a skill or MCP server when shipping to multiple clients. But the specification standardizes where components live, not what they do, handing skill format to the Agent Skills specification and wire behavior to MCP, both of which Anthropic released openly but for which it holds no steering committee seat. The project's own documentation calls the outcome "a small interoperability floor," and Google's announcement describes v1 as "a package format and nothing more."
A plugin is a directory with a plugin.json file at its root, skills in a skills/ folder with one subdirectory per skill, and MCP servers declared in mcp.json. Those locations are fixed, killing the discovery indirection and precedence rules each client would otherwise invent separately. The manifest requires only two fields: $schema and name, with everything else optional metadata. Section 7.1 states explicitly that the Agent Skills specification governs the SKILL.md format, frontmatter fields, and directory layout, while Agent Plugins defines only how skills are discovered inside a plugin. Section 7.2 does the same for MCP. Nothing forced that choice—a specification can constrain implementations by defining a profile, mandating a subset, or prohibiting optional features—but Agent Plugins declines to, treating Agent Skills and MCP as separately governed contracts and standardizing addresses rather than layering behavioral requirements on top.
The minimum for a conformant client is support for at least one component type: skills or MCP servers. Section 11.2 spells out that a skills-only client can conform without supporting MCP at all, and transport support follows a similar approach: an MCP-capable client must implement at least one of stdio or Streamable HTTP, while legacy HTTP+SSE stays optional. Clients must skip server entries for which they don't implement transport and continue loading everything else. Stack those together, and the range of things a conformance claim can mean gets wider: Client A and Client B can share nothing, yet both pass. A plugin containing a skill and a bundled stdio server runs in full on neither one, because A loads only the skill and B loads only the server, and in each case the client behaves exactly as the specification requires. The compatible clients page lists VS Code, Cursor, GitHub Copilot, ChatGPT, Codex, Kiro, Hermes Agent, OpenClaw, and Grok Bot, each supporting Agent Skills plus MCP with transports itemized, and the list has grown well past the launch-week six. The bare claim of Agent Plugins conformance doesn't predict interoperability—what predicts it is the per-client capability matrix, and that matrix is documentation, not part of the conformance claim itself.
Section 8 defines client extensions, which are reverse-domain namespaces for anything outside the portable core. A client can claim manifest data under extensions["com.vendor.client"], a top-level com.vendor.client/ directory, or both. Agent Plugins assigns no portable discovery, validation, loading, or failure semantics to client extension data or files—each client defines the contents and behavior of its own namespace. Commands, hooks, agents, rules, and LSP servers all live outside v1, on the stated grounds that their formats haven't converged. Every one of them is something developers actually build plugins for. When Adam Dalloul of EmpirioLabs warned that useful behavior ending up inside vendor namespaces would leave the standard open on paper while fragmentation moved elsewhere, he was describing the escape-hatch section 8 documents. Whether that matters depends on how much of your plugin's value lives in hooks: if it's most of it, the portable part is the wrapper, and the fork you were trying to avoid is still there under a different directory name.
The project's future considerations document lists permission declarations, cryptographic signature verification, attestation chains, a secrets mechanism, organization allowlists, audit event schemas, dependency resolution, and a conformance test suite. A conformance suite would make implementation claims testable, establishing that a client correctly does what it claims to do. A machine-readable capability profile would make the remaining optional surface predictable, turning today's compatible-clients page into something a build can check. Signatures and permissions matter more than either: a permission model forces every client to agree on what a plugin may touch, and an IDE, a CLI, and a managed enterprise platform each answer that differently today. Agent Plugins does the narrow thing its authors set out to do, and the restraint is deliberate rather than an oversight. The specification governing the semantics of its two portable component types is governed somewhere else, so read the compatibility page as a capability list rather than a promise. Organizations betting on plugin ecosystems should recognize that alignment on directory structure buys time but doesn't resolve the harder question of whether competing platforms will converge on permissions, secrets, and execution models—or whether they'll retreat into namespaced extensions the moment those features matter.