Agent Plugins 1.0 Brings Portable Skills and MCP to AI Tools

Agent Plugins 1.0.0 defines a vendor-neutral directory format for packaging Agent Skills and MCP servers so compatible AI clients can load the same components without repackaging them. Google joined Amazon, Cursor, Microsoft, OpenAI, and Vercel as a core maintainer on August 6, 2026.

The specification is intentionally small. It standardizes where a manifest, skills, and MCP configuration live while leaving installation, permissions, sandboxing, trust, and user experience to each client. That narrow scope is why it has a realistic chance of adoption.

What Is Agent Plugins 1.0?

Agent Plugins 1.0 is a portable package format for reusable instructions and tools that extend AI agents. A plugin is a directory with a required plugin.json file and optional skills/, mcp.json, and client-specific extension folders.

A minimal package looks like this:

reports-plugin/

plugin.json

skills/

summarize/

SKILL.md

scripts/

references/

mcp.json

com.example.client/

The manifest can be nearly empty:

{

"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",

"name": "reports-plugin"

}

Fixed locations remove the adapter code that currently accumulates around otherwise portable components. An Agent Skill already has reusable instructions. MCP already connects models to services. Agent Plugins standardizes the box that carries them together.

Which Companies Maintain the Standard?

The initial technical steering group includes core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel, with Google joining in August 2026. That membership gives the format reach across cloud platforms, coding agents, deployment infrastructure, and model providers.

Google launched support in two products:

• Agents CLI, which packages skills for agent building, evaluation, deployment, observability, and publishing.
• Data Agent Kit, which ships plugins connecting agents to BigQuery, Spanner, Cloud SQL, and data-pipeline workflows.

Support from maintainers does not mean every product is fully compatible today. Teams should verify the client matrix and avoid assuming that a plugin will install identically everywhere. The 1.0 standard defines package structure, not distribution or runtime behavior.

How Agent Plugins Relates to MCP and Agent Skills

Agent Plugins packages MCP servers and Agent Skills; it does not replace either standard. Each layer handles a different problem.

This separation is healthy. A team can use one skill without creating a plugin, run one MCP server with mcp.json, or publish a plugin without enrolling it in a catalog.

The latest MCP 2026 migration guide explains the protocol changes underneath remote tool connections. Agent Plugins operates one layer above that transport.

Why Portability Matters for Developer Teams

Portability matters because AI-agent adoption is fragmenting across IDEs, command-line tools, cloud runtimes, and enterprise assistants. The useful business logic often stays the same while every client invents a different wrapper.

Consider an internal release plugin that:

• Reads deployment status through an MCP server
• Uses a skill to summarize risk
• Runs a script that checks migrations
• Includes references for the company rollback policy

Without a shared package format, developers maintain separate layouts for each agent client. Those copies drift, security fixes land unevenly, and ownership becomes unclear. Agent Plugins creates one canonical portable core.

The reverse-domain extension directory preserves client innovation. A client can add hooks or commands under a namespace such as com.example.client/; other clients ignore what they do not understand. This is more sustainable than forcing every vendor-specific feature into the common schema.

What Agent Plugins Deliberately Does Not Solve

Agent Plugins 1.0 does not define installation, registries, signing, provenance, permissions, sandboxing, approval flows, or trust policy. A valid plugin can still contain a dangerous script or point to a malicious MCP server.

That omission is not a hidden security feature. It is a boundary.

Enterprises must therefore validate both the package and the runtime. A standardized directory makes scanning easier, but standardization does not make unknown code trustworthy.

Our AI agent security guide covers the prompt-injection and tool-trust risks that remain after packaging is solved.

Our Analysis: This Could Become the npm Package Shape for Agents

Agent Plugins could become the package boundary for the agent ecosystem, but only if distribution and trust mature without bloating the portable core. The analogy is not that plugins are already npm packages. It is that a predictable manifest gives registries, scanners, IDEs, and CI systems something stable to inspect.

Three effects follow.

Reusable agent operations become products. A well-maintained skill plus an MCP connector can move between clients, reducing the cost of selling or open-sourcing specialized workflows.

Security scanning becomes more practical. Fixed paths let a scanner inspect SKILL.md, scripts, and mcp.json consistently. Policies can flag shell access, remote endpoints, secrets, or unpinned dependencies before installation.

Clients compete on execution rather than packaging. Cursor, Claude Code, Gemini CLI, and enterprise agents can differentiate on planning, permissions, observability, and UX while consuming the same portable core.

The standard will fail if every vendor hides required behavior in its extension namespace. Teams should measure portability by running the same plugin in at least two clients and tracking how much client-specific configuration remains.

How to Build a Safe Agent Plugin

A production plugin should be small, inspectable, versioned, and explicit about every external capability.

Start with this workflow:

1. Create plugin.json with the 1.0.0 schema and a stable name.
2. Put each skill in its own skills/<name>/ directory.
3. Keep instructions in SKILL.md, scripts in scripts/, and supporting material in references/.
4. Declare MCP servers in mcp.json with an explicit transport.
5. Use client extension namespaces only for behavior that cannot be portable.
6. Pin script dependencies and avoid downloading executable code at runtime.
7. Document required environment variables without placing secrets in the package.
8. Test component failure independently: one broken MCP server should not disable every skill.
9. Scan instructions for prompt injection and scripts for filesystem or network access.
10. Test the package in two compatible clients before claiming portability.

For teams choosing between coding-agent runtimes, the Cursor vs Claude Code vs GitHub Copilot comparison provides the surrounding product context.

Enterprise Adoption Checklist

Enterprise platform teams need policy around provenance before they create an internal plugin catalog.

• Require an owner, source repository, version, and review date.
• Allowlist MCP endpoints and block implicit transport guessing.
• Run scripts in a sandbox with minimum filesystem and network access.
• Keep secrets in the client secret store, never in plugin.json or mcp.json.
• Generate a software bill of materials for packaged scripts.
• Log plugin version, skill name, MCP tool, user identity, and approval decision.
• Separate discovery from installation and installation from execution.
• Re-review plugins when a remote MCP endpoint changes ownership.
• Provide a kill switch for compromised packages.
• Test uninstallation and removal of cached credentials.

This is where a portable format creates operational value: one review can cover the common package instead of six vendor-specific copies. Client-specific extensions still need separate review.

When You Should Not Create a Plugin

You should not create an Agent Plugin when one skill or one MCP server already solves the problem in one client. Packaging adds value only when related components must travel together or support multiple clients.

Avoid a plugin when:

• The workflow is experimental and changes daily.
• One local skill has no scripts or tools.
• One MCP server serves one managed client.
• The package would mainly contain vendor-specific extension code.
• No owner will maintain compatibility and security updates.

The best first candidate is an established internal workflow with stable instructions, one or two tools, repeated use, and demand from multiple agent clients.

What to Watch Next

The next growth phase depends on compatible clients, trusted distribution, signatures, and clear permission previews. Google has stated that more of its products are expected to support the format, while the specification project lists installation and trust concerns as future work.

Search demand will likely move from "what is Agent Plugins" toward implementation queries: plugin.json examples, MCP packaging, compatible clients, security scanning, and migration from vendor-specific plugin formats. Publishing tested examples early gives developer sites a better chance of earning durable links and AI citations than another generic agent-tools list.

Developers can also test adjacent agent use cases with the Claude vs ChatGPT tool, then choose a runtime based on workflow rather than brand familiarity.

Sources

• Agent Plugins 1.0 official specification
• Google Developers Blog: Agent Plugins, August 6, 2026
• Agent Plugins specification repository
• Model Context Protocol specification
• Agent Skills specification

Key Takeaways

• Version 1.0.0: Agent Plugins defines one directory format for Agent Skills and MCP servers.
• Six major maintainers: Amazon, Cursor, Microsoft, OpenAI, Vercel, and Google back the effort.
• Two Google products: Agents CLI and Data Agent Kit support the format now.
• For developers: standardize the portable core, but keep permission, sandbox, and provenance checks in the client.
• What to watch: compatible-client growth, package signing, trusted catalogs, and security-scanning conventions.