Open Plugin Spec
https://github.com/vercel-labs/open-plugin-spec- Category
- AI Agents
- Rank
- No. 1302Tools index
Previous survey · No. 1309 ·
- Pricing
- Open Source
- Type
- TOOL
- Builder
- vercel-labs
- GitHub
- 1.3k stars
- Date
About
Minimal standard for packaging agent extensions into distributable plugins.
What it does
It gives agent clients a shared directory layout and validation contract for loading skills and MCP servers. A plugin carries a JSON manifest, optional conventionally located components, and client-specific extensions kept outside the portable core.
Why it's ranked here
The specification is unusually disciplined about interoperability boundaries. It defines deterministic discovery, validation, path containment, and failure behavior while leaving presentation and client policy alone. That makes it credible as a common contract, though not a complete plugin platform.
What's good
The closed manifest catches typos, while extension namespaces preserve room for client-specific features. Path containment blocks package files from escaping the plugin root. Narrow failure boundaries let clients skip a broken skill or server without necessarily rejecting unrelated components.
Tradeoffs
It does not define installation UX, permissions, sandboxing, provenance checks, secret handling, enterprise policy, dependencies, audit events, or a standard test harness. Its containment rules protect package paths, but they do not sandbox subprocesses or restrict runtime paths.
How to use it well
Use it when plugin authors and agent-client builders need the same package to travel across implementations. Pair it with client-owned installation, consent, security, secrets, updates, and execution controls. It is a portability contract, not a marketplace or runtime.
Technical notes+
README.md provides the non-normative introduction, while spec/1.0.0.md is authoritative over schemas. schemas/1.0.0/plugin.schema.json defines a closed manifest requiring $schema and name; schemas/1.0.0/mcp.schema.json models stdio, streamable HTTP, and legacy SSE servers. The specification requires resolved package paths to remain under the plugin root and assigns distinct rejection or skipping behavior by failure scope. FUTURE_CONSIDERATIONS.md explicitly leaves permissions, provenance, secrets, enterprise controls, audit schemas, dependencies, and standardized testing outside the published contract.
Observed
- Licensing
- Documentation and specification material use CC BY 4.0; schemas, source code, and scripts use Apache 2.0.
- Package surface
- A plugin is a directory containing a root JSON manifest and optional skills, MCP servers, and client extensions.
- Component interfaces
- The portable component types are Agent Skills and MCP servers.
- MCP transports
- The MCP schema supports stdio, streamable HTTP, and legacy HTTP plus SSE server entries.
- Machine-readable surface
- JSON Schemas define closed structures for the plugin manifest and MCP configuration.
- Governance
- A community-governed technical steering committee oversees the vendor-neutral specification.
Read from README.md, AGENTS.md, LICENSE.md, GOVERNANCE.md, MAINTAINERS.md, CONTRIBUTING.md, FUTURE_CONSIDERATIONS.md, spec/1.0.0.md, LICENSES/CC-BY-4.0.txt, LICENSES/Apache-2.0.txt, schemas/1.0.0/mcp.schema.json, schemas/1.0.0/plugin.schema.json.
What it can do
Package agent extensions into plugins
Agent extension code and configuration → Distributable plugin package
Define plugin interface standards
Plugin requirements and specifications → Standardized plugin interface definition
Validate plugin compatibility
Plugin package and specification requirements → Compatibility validation results
Enable plugin distribution
Packaged plugin following the standard → Distributable plugin ready for installation
Standardize plugin metadata
Plugin information and properties → Formatted plugin metadata following specification
Tags
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.