Updated 18 Aug 2026: Adds concrete cross-client adoption evidence, current VS Code/Copilot behavior and enterprise MCP controls; corrects the canonical Agent Plugins site and repository URLs.
Agent Plugins 1.0 now has a concrete cross-client compatibility layer for Skills and MCP
Agent Plugins 1.0 has moved beyond a merely proposed portability layer: its official compatibility matrix now spans major coding agents and general-purpose assistants, while real host differences still limit how much behavior is truly portable.
Reviewed and published by Lars JansenUpdated 7 min read
First published
Key details
Agent Plugins 1.0.0 is the published canonical specification for packaging Agent Skills and MCP servers into distributable plugins.
The official compatibility matrix currently lists nine clients: VS Code, Cursor, GitHub Copilot, ChatGPT/Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot and NanoClaw.
Every client in the matrix supports Agent Skills plus stdio and Streamable HTTP MCP; legacy SSE support varies.
VS Code explicitly recognizes Agent Plugins 1.0 packages and separates portable Skills/MCP from client-specific agents, hooks and slash commands.
VS Code automatically discovers plugins installed by GitHub Copilot CLI, reducing duplicate installation work across those two surfaces.
GitHub enterprise and organization MCP controls still govern Copilot CLI, including registry and allowlist restrictions.
The canonical project site is agent-plugins.org and the canonical specification repository is github.com/agentplugins/agent-plugins-spec.
What builders should take away
If you ship reusable agent capabilities, put Agent Skills and MCP server definitions in the portable Agent Plugins core first; add host-specific agents, hooks or commands only where they create real product value.
Choose target clients from the official compatibility matrix and maintain automated smoke tests per client and MCP transport. Do not infer identical behavior from format conformance alone.
For VS Code and Copilot CLI users, test the single-install workflow because VS Code can discover plugins installed by Copilot CLI; this can simplify onboarding and release documentation.
Keep security documentation host-specific. State which MCP servers run, what credentials and network access they need, and how enterprise allowlists or registries affect installation.
Validate plugin.json against the canonical 1.0.0 schema in CI and preserve the portable directory layout so host-specific extensions do not silently become dependencies.
Update old links and tooling references to the canonical agent-plugins.org site and agentplugins/agent-plugins-spec repository.
What changed
Since BTN's initial dossier, Agent Plugins has published a canonical compatibility matrix showing support across VS Code, Cursor, GitHub Copilot, ChatGPT/Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot and NanoClaw. The project's canonical site and repository are now agent-plugins.org and agentplugins/agent-plugins-spec. VS Code's current documentation also explicitly recognizes Agent Plugins 1.0 packages, can discover plugins installed by GitHub Copilot CLI, and distinguishes the standard's portable Skills/MCP components from client-specific agents, hooks and slash commands.
Why it matters
The strongest uncertainty in the original story was whether a stable package format would attract enough meaningful clients to create network effects. There is now concrete multi-client adoption, including large developer surfaces and general-purpose assistants. That makes Agent Plugins more credible as release and distribution plumbing for teams shipping the same Skills and MCP servers into multiple hosts. The boundary is still important: the common layer does not make every plugin capability portable, and security/governance remain host-specific.
The adoption question now has a concrete answer
The official Agent Plugins compatibility matrix lists VS Code, Cursor, GitHub Copilot, ChatGPT/Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot and NanoClaw. All listed clients support Agent Skills and at least stdio plus Streamable HTTP MCP; several also support legacy SSE. This does not prove identical behavior across clients, but it materially reduces the risk that Agent Plugins remains a specification without implementers.
1.0 still standardizes a narrow portability floor
The 1.0.0 specification defines a plugin root with plugin.json plus fixed locations for Agent Skills and MCP configuration. The project deliberately leaves distribution, installation, permissions, user experience and client-specific capabilities to hosts. Reverse-domain extension namespaces give clients room to add proprietary behavior without changing the portable core.
VS Code shows how the portable and proprietary layers coexist
VS Code recognizes Agent Plugins 1.0 packages when plugin.json declares the canonical Agent Plugins schema. Skills and MCP servers are portable components, while custom agents, hooks and slash commands remain client-specific. VS Code can also discover plugins installed through GitHub Copilot CLI, so one installation can surface in both tools even though the host-specific capabilities may differ.
MCP governance remains separate from package portability
Enterprise controls still apply at the host layer. GitHub documents organization and enterprise MCP registry and allowlist policies for Copilot CLI, allowing administrators to constrain which MCP servers users can run. A portable Agent Plugin package therefore does not bypass runtime governance: organizations still need host-specific policy, credential and trust controls.
Builders should now treat compatibility as a testable matrix, not a future possibility
The practical implementation pattern is to keep Skills and MCP definitions in the Agent Plugins portable core, add host-specific extensions only where necessary, and test each claimed client and transport combination. The official matrix makes target selection easier, while client documentation remains the source of truth for installation, extension behavior and security controls.
Timeline
2026-08
Agent Plugins specification reaches 1.0
The project publishes the canonical 1.0.0 specification for portable packages containing Agent Skills and MCP servers.
2026-08-18
Cross-client support is documented
BTN review finds the official compatibility matrix listing nine supporting clients and current VS Code/Copilot documentation showing concrete installation, compatibility and enterprise-control behavior.
What to watch next
Whether additional major agent clients adopt Agent Plugins 1.0 natively and whether existing clients expand beyond the current portable Skills/MCP floor.
Whether registries and marketplaces converge on Agent Plugins metadata for distribution rather than keeping format support behind client-specific catalogs.
Whether the specification adds portable provenance, signing or permission declarations without expanding into a full runtime standard.
Whether differences in MCP transport support, environment variables or extension namespaces become meaningful compatibility pain points in real deployments.
Whether enterprise management products expose Agent Plugin-level policy in addition to existing MCP server controls.
Still unclear
The compatibility matrix establishes implementation breadth, but it does not measure active usage, plugin catalog depth or how consistently packages behave across clients.
Agent Plugins deliberately leaves important runtime and security behavior to clients, so 'portable' still means a common packaging floor rather than identical execution semantics.
Canonical project site describing Agent Plugins 1.0.0, the portable package model, governance and the boundary between portable and host-specific behavior.
Documents VS Code support for Agent Plugins 1.0, portable versus client-specific components, marketplace/source installation and discovery of Copilot CLI-installed plugins.
Google Cloud’s Developer Device Platform is now in public preview with remote physical-device streaming, parallel emulator testing, smart sharding and an agent skill that can drive multi-step journeys, inspect visual issues and feed fixes back into coding agents. It is billed per active device minute and remains a pre-GA service.
GitHub Copilot can now turn Slack or Teams threads into collaborative cloud-agent sessions. Teammates can add context and steer the work in public, while repository permissions, agent budgets and optional extra PR approvals remain the main control boundaries.
Custom Flows became generally available in GitLab 19.2; 19.3 adds the missing authoring layer. Flow Creator reads current Flow Registry docs, applies known failure rules and generates a runnable flow from plain English. Builders still need to review, register and govern the automation rather than treating generated YAML as trusted infrastructure.