AI Agent Plugins Just Got a Shared Standard. Here’s Why Developers Should Care

Developers building extensions for AI agents have been solving the same packaging problem repeatedly.

The useful part may already be portable: a set of instructions, a review workflow, or an MCP server. The surrounding manifest and directory structure often are not.

That means one capability can require several slightly different packages before it works across editors, command-line agents, and hosted tools.

Agent Plugins 1.0 proposes a shared minimum.

Published on August 6, 2026, the open standard packages Agent Skills and MCP server configurations into a portable directory that compatible clients can discover and load. Initial maintainers represent Amazon, Cursor, Microsoft, OpenAI, and Vercel, while Google joined as a core maintainer when version 1.0 was announced.

It sounds like a small infrastructure detail.

Package formats often do, until an ecosystem starts forming around them.

Table of contents

• The fragmentation problem
• What Agent Plugins 1.0 standardizes
• Skills, MCP servers, and plugins
• Build the smallest useful plugin
• Add an MCP server
• Keep client-specific features
• What the standard leaves open
• The security question
• Where portable plugins fit
• Should you adopt it now?
• Practical checklist

The fragmentation problem

Imagine maintaining a pull-request review assistant.

Its core behavior is simple:

1. Read the current diff.
2. Compare it with repository conventions.
3. Look for correctness, security, and maintainability issues.
4. Return findings in priority order.

The assistant may also use an MCP server to retrieve issue details or repository metadata.

None of that behavior is inherently tied to one editor or one agent. Yet each client may expect a different manifest, directory structure, installation process, or extension format.

The result is familiar to anyone who has maintained integrations across several platforms:

• repeated manifests,
• duplicated packaging logic,
• slightly different documentation,
• separate release steps,
• compatibility fixes that do not improve the underlying capability.

The problem becomes more visible as teams use agents in several places. A developer may work with an agent in an editor, another in a terminal, and a hosted agent for asynchronous tasks. Rebuilding the same instructions and tool configuration for every surface creates friction for authors and inconsistent behavior for users.

Agent Plugins does not attempt to make every client identical. It defines a portable core for the components that already have a reasonable chance of working across tools.

That is a smaller goal, but also a more achievable one.

What Agent Plugins 1.0 standardizes

An Agent Plugin is a directory with a required manifest and optional components in predictable locations.

my-plugin/
├── plugin.json
├── skills/
│   └── review-diff/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── client-specific-files

The portable package can contain:

• plugin.json, which identifies the plugin and specification version,
• skills/, containing reusable Agent Skills,
• mcp.json, describing MCP server connections,
• namespaced directories, containing features understood by a particular client.

The standard provides a common packaging contract. A compatible client can inspect the manifest, discover supported components, and ignore extensions it does not understand.

This distinction matters. The standard focuses on portable packaging while leaving user experience and execution policy to individual clients.

In August 2026, support became generally available across VS Code, Copilot CLI, the GitHub Copilot SDK, and the GitHub Copilot app. The specification itself is vendor-neutral and developed publicly rather than being owned by one client implementation.

Skills, MCP servers, and plugins are different layers

A plugin can contain a skill, an MCP configuration, or both. Those pieces solve different problems.

A skill provides reusable guidance

An Agent Skill describes how an agent should perform a particular kind of task. It can include instructions, scripts, and reference material.

Examples include:

• reviewing a database migration,
• preparing a release note,
• analyzing a failing test,
• applying an organization's accessibility checklist,
• validating an infrastructure change.

The skill teaches the agent a workflow. It does not automatically provide access to an external system.

MCP provides tools and context

The Model Context Protocol allows an agent client to connect to tools or data exposed by an MCP server.

A server might provide operations for:

• retrieving issue details,
• querying internal documentation,
• inspecting deployment status,
• reading an approved data source,
• invoking a controlled development tool.

MCP describes the runtime connection. It does not define the complete package through which users discover and install a reusable extension.

A plugin packages reusable components

Agent Plugins supplies the distribution structure around those pieces.

A useful mental model is:

Skill  → how the agent should perform a task
MCP    → which tools or data the agent can access
Plugin → how reusable components are packaged together

A plugin does not need to contain every component. A small workflow may need only a skill. A tool integration may provide an MCP configuration plus instructions explaining how to use it safely.

Build the smallest useful plugin

Let us create a minimal plugin that guides an agent through reviewing a code diff.

The directory needs only two files:

review-helper/
├── plugin.json
└── skills/
    └── review-diff/
        └── SKILL.md

Add the manifest

Create plugin.json:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "review-helper"
}

The $schema property identifies the versioned schema used to validate the manifest. The name identifies the plugin.

A small manifest is a feature here. The portable core should contain only the information compatible clients need to discover the package.

Add the skill

Create skills/review-diff/SKILL.md:

---
name: review-diff
description: Review a code diff for correctness, security, scope, and maintainability.
---

Review the current code diff as a skeptical maintainer.

## Review priorities

1. Correctness defects and missed requirements
2. Security-sensitive behavior
3. Missing or ineffective tests
4. Unnecessary complexity
5. Changes outside the requested scope

## Process

- Read the task and repository instructions first.
- Inspect the complete diff before forming conclusions.
- Check modified tests against the intended behavior.
- Distinguish confirmed defects from questions or assumptions.
- Do not modify files during the review.

## Output

Return findings in priority order. For each finding, include:

- severity,
- affected file and location,
- concise explanation,
- practical remediation.

If no material issue is found, say so directly and mention any remaining verification gap.

This is already a valid conceptual plugin: one manifest and one discoverable skill.

The quality of the review still depends on the client, model, repository context, and available tools. Portability means the package can be discovered consistently. It does not make execution identical.

Add an MCP server without losing portability

Suppose the review workflow needs issue metadata from an approved MCP server. The plugin can add an mcp.json file at its root.

A conceptual package now looks like this:

review-helper/
├── plugin.json
├── mcp.json
└── skills/
    └── review-diff/
        └── SKILL.md

The specification supports MCP server descriptions for standard transports, including local standard input/output and network-based connections.

The exact configuration depends on the server and its authentication model. That is where security review becomes essential.

Do not embed credentials in the plugin. Do not assume that installation should grant every available permission. The package may describe a connection, but the client remains responsible for how it asks for consent, stores configuration, starts a server, and exposes tools to the agent.

A good skill should also describe when the tool is appropriate:

## Issue context

Use the issue-tracker MCP tools only when the task references an issue ID.
Read issue title, description, and acceptance criteria before reviewing the diff.
Do not create, edit, close, or comment on issues during a code review.

This does not replace client-enforced permissions. It makes the intended operating boundary visible to both maintainers and the agent.

Keep client-specific features without polluting the core

Portability does not require every client to abandon its unique capabilities.

Agent Plugins uses reverse-domain namespaces for client-specific files:

my-plugin/
├── plugin.json
├── skills/
├── mcp.json
└── com.github.copilot/
    └── client-specific-components

A compatible client that recognizes the namespace can load those components. Other clients can ignore the directory and still use the portable skill or MCP configuration.

This is a practical compromise:

• common components remain reusable,
• clients can continue to innovate,
• vendors do not need to force every feature into the shared standard,
• authors can preserve enhanced behavior without forking the entire package.

The cost is that “portable” does not mean “feature-identical.” Plugin documentation should clearly label which capabilities belong to the shared core and which require a specific client.

What the standard deliberately leaves open

Agent Plugins standardizes the package format, not the entire lifecycle.

Clients still control areas such as:

• discovery and marketplaces,
• installation and updates,
• trust prompts and consent,
• authentication,
• permission enforcement,
• user interface,
• sandboxing,
• how skills are presented to the model,
• how MCP servers are started and monitored,
• support for client-specific extensions.

That means two compatible clients may load the same plugin but expose it differently. One may require confirmation before starting an MCP server. Another may apply an enterprise allowlist. A third may support the skill but ignore an optional extension.

This is not necessarily a weakness. Standardizing policy too early can produce a large specification that few clients implement consistently.

The important question is whether the shared core removes meaningful duplication without hiding client differences. Version 1.0 is an initial answer, not the final shape of the ecosystem.

The security question developers should ask

A portable plugin is easier to distribute. That also makes its trust model more important.

Installing instructions is not the same as installing a passive theme. A skill can influence agent behavior. An MCP configuration can connect the client to executable tools or external data. Scripts bundled with skills may run inside a development environment.

Before installing a plugin, ask:

• Who maintains it?
• Which files and instructions does it contain?
• Does it bundle scripts?
• Which MCP servers does it configure?
• How are those servers obtained and started?
• Which credentials or permissions do they request?
• Can the plugin create external or irreversible effects?
• Does the client isolate execution and show approval prompts?
• Can the organization restrict plugins to approved marketplaces?

GitHub's implementation allows managed organizations to automatically install or block plugins, configure known marketplaces, and restrict installation to managed sources. Other clients may use different controls.

Plugin authors can help by keeping the package inspectable:

• use the smallest necessary permissions,
• avoid hidden network behavior,
• document external services,
• pin or verify dependencies where appropriate,
• separate read-only and write-capable workflows,
• explain which actions require human approval,
• publish changes and security guidance clearly.

Where portable plugins could be useful

The strongest use cases are repeatable workflows that cross tools or teams.

Repository review standards

A project can package its review method, security checks, and output format as a reusable skill. Developers can use the same core workflow from multiple compatible clients.

Framework and platform guidance

A maintainer can publish a skill that teaches agents the supported setup, architecture, migration process, and verification commands for a framework.

Internal engineering workflows

An organization can package release preparation, incident analysis, accessibility review, or infrastructure validation with approved tool connections.

Product integrations

A service provider can distribute an MCP configuration together with skills that explain safe and effective use of its tools.

Open-source maintenance

Projects can share triage, contribution, documentation, and release workflows without requiring contributors to adopt one specific agent client.

Not every instruction deserves a plugin. Repository-specific rules may still belong in AGENTS.md. Personal preferences may belong in local agent configuration. A plugin is most useful when a capability needs to be distributed, versioned, and reused across environments.

AGENTS.md or Agent Plugin?

The two formats solve related but different problems.

Use AGENTS.md when guidance belongs to a repository:

This project uses pnpm.
Do not edit generated files.
Run these checks before finishing.

Use an Agent Plugin when a capability should travel between repositories or clients:

Review any database migration using this process.
Connect to this approved documentation service.
Generate release notes in this format.

A repository can use both. AGENTS.md supplies local context, while a plugin supplies a reusable workflow or tool integration.

Should you adopt the standard now?

Consider experimenting now if you:

• already maintain the same agent capability for several clients,
• publish Agent Skills,
• distribute an MCP integration,
• manage shared workflows across a development organization,
• want a vendor-neutral package for a new extension.

You may prefer to observe the ecosystem if you:

• use only one client and rely heavily on its unique features,
• have no reusable skills or MCP integrations,
• require installation or permission behavior the standard does not cover,
• cannot yet test the plugin across your target clients.

Adoption does not need to be all or nothing. A useful first step is moving the genuinely portable components into the standard layout while keeping client-specific behavior in a namespaced directory.

GitHub states that existing Copilot plugins that do not target Agent Plugins 1.0 remain supported, so maintainers do not need to migrate immediately merely to preserve current behavior.

Practical checklist for plugin authors

Portability

• [ ] The shared capability belongs in a plugin rather than repository-local instructions.
• [ ] plugin.json targets a published specification version.
• [ ] Skills live under skills/.
• [ ] MCP configuration lives in mcp.json.
• [ ] Client-specific components use an appropriate namespace.
• [ ] Documentation separates portable and client-specific behavior.

Quality

• [ ] Each skill has a narrow, observable purpose.
• [ ] Instructions define boundaries as well as actions.
• [ ] Output expectations are explicit.
• [ ] Examples reflect real tasks rather than idealized demos.
• [ ] The plugin has been tested in every client you claim to support.

Security

• [ ] No credentials are embedded in the package.
• [ ] External services and network behavior are documented.
• [ ] Scripts are minimal and reviewable.
• [ ] Requested tools follow least privilege.
• [ ] Write actions and irreversible effects require clear approval.
• [ ] Installation guidance explains the trust boundary.

Maintenance

• [ ] The package has a clear owner.
• [ ] Changes are versioned and documented.
• [ ] Deprecated components have a migration path.
• [ ] Compatibility claims are tested before release.
• [ ] Users have a place to report security and interoperability issues.

The takeaway

Agent Plugins 1.0 is not a universal runtime for agents. It does not make models identical, standardize every permission, or guarantee that a plugin behaves the same way in every client.

It solves a narrower problem:

One portable package
        ↓
Reusable Agent Skills
        +
Reusable MCP configuration
        +
Optional client extensions
        ↓
Several compatible agent clients

That narrow scope may be exactly why the standard is worth watching.

Developer ecosystems often grow around small agreements: where files live, how packages identify themselves, and which parts different tools can recognize. Once those basics are shared, authors can spend less time repackaging the same capability and more time improving it.

If you already maintain a skill or MCP integration, the most useful question is not whether every feature is portable.

It is whether the shared part should still be duplicated.

Would you install the same agent plugin across your editor and CLI, or do you expect those environments to remain fundamentally different?

Explore the Agent Plugins 1.0 specification

Sources and further reading

• Specification: Agent Plugins documentation
• Open-source repository: Agent Plugins Specification 1.0
• GitHub announcement: Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app

Connect with Me

If you found this guide helpful, let's connect and discuss modern development workflows!

• 💻 GitHub: johnnylemonny
• ✍️ DEV.to: johnnylemonny