A portable package removes some conversion work. It does not make every client implement every component, transport or permission model.
A published format with a compatibility boundary
The Agent Plugins specification defines a root plugin.json manifest and fixed component locations, including skills/ and mcp.json. Clients validate the manifest before discovering components. Unsupported component types are ignored; transport support is a separate capability. The project lists 1.0.0 as published and 1.1.0 as a working draft.
The client matrix shows the practical consequence: some clients list legacy SSE alongside stdio and Streamable HTTP, while others list only the latter two. A package that relies on legacy SSE therefore needs a compatibility check even when both clients recognize the package format. Check the matrix against the exact installed client version, rather than assuming a product name establishes support everywhere.
File containment is not a process sandbox
The specification requires discovered component paths to remain within the resolved package root, including through symbolic links and junctions. That blocks one class of package traversal. It does not confine a launched subprocess to that directory or grant permission to read arbitrary project files.
The illustration separates those boundaries. An accepted manifest answers “can this client interpret the package?” The transport answers “can it connect to this server?” Runtime permissions answer “what can the resulting process do?” A successful first step cannot substitute for the next two.
Test the workflow, not just installation
For a small incident-summary plugin, run the same synthetic incident notes through two target clients. Confirm that each discovers the intended skill, connects to the expected MCP endpoint and returns a result grounded in those notes. Record client and package versions beside the result. This is a suggested compatibility exercise, not a test we claim to have run.
Then repeat with the MCP server deliberately unavailable. The useful question is whether the workflow reports the missing source clearly, rather than silently presenting an unsupported answer. Portable packaging makes distribution easier; a documented dependency and understandable failure still determine whether the plugin is useful after installation.
September 8: check published 1.0 against the specification and client matrix; separate package containment, transport support and execution permissions.