AI Agent - Aug 9, 2026

Agent Plugins vs Agent Skills vs MCP: What Each Standard Does

Q: Are Agent Plugins a replacement for Agent Skills or MCP?

No. Agent Skills define reusable instructions and resources, MCP defines connections to tools and services, and Agent Plugins define a common package and discovery layout that can carry skills and MCP server configuration together.

Q: Do I need an Agent Plugin for one skill?

Not necessarily. A single skill can remain an Agent Skill. A plugin becomes useful when related portable components need one package or must move across compatible clients with a common wrapper.

Q: Does Agent Plugins make an MCP server trusted?

No. A conforming package can still launch code or connect to a remote service. Installation source, permission scope, credentials, process and network isolation, trust, provenance, and approval remain separate.

Q: Can every compatible client run every plugin component?

No. A conformant client can support skills, MCP servers, or both, and MCP clients can differ by transport support. Client extensions are intentionally non-portable and ignored by clients that do not implement their namespace.

Quick answer

Agent Skills package reusable instructions and supporting resources. MCP connects an agent to tools and services through a protocol and lifecycle. Agent Plugins provide one directory, manifest, and fixed discovery layout that can carry skills and MCP server configuration together across compatible clients.

They are layers, not competitors:

Agent Plugin = package and discovery wrapper
Agent Skill = instructions and resources
MCP server = tool or service connection
Client policy = install, permissions, sandbox, trust, approval, UX

Agent Plugins 1.0 does not absorb the Agent Skills or MCP specifications, and it does not standardize the client-policy layer.

Side-by-side comparison

Question	Agent Plugins 1.0	Agent Skills	MCP
Primary job	Package and discover related components	Give an agent reusable procedural knowledge	Connect an agent to tools, data, and services
Main artifact	`plugin.json`, fixed directories, optional `mcp.json`	A skill directory led by `SKILL.md`	Server implementation and protocol connection
Executes tools by itself	No	Not inherently	Exposes callable capabilities
Defines instruction format	No, defers to Agent Skills	Yes	No
Defines wire protocol	No, defers to MCP	No	Yes
V1 portable components	Skills and MCP servers	One skill and its supporting files	Tools, resources, prompts, and protocol features supported by the server/client
Defines installation or distribution	No	Client-dependent	Client/server deployment-dependent
Defines permissions or sandbox	No	No universal runtime policy	Protocol is not a universal authorization policy

Use an Agent Skill when knowledge is the product

A skill is a good fit for a repeatable method: reviewing a document, deploying a particular stack, diagnosing a metric, or following a source-grounded workflow. It can include scripts, references, and assets alongside its SKILL.md.

If the skill requires no external tool connection and targets one or more skill-capable clients, it can stand alone. Wrapping a single skill in a plugin may add packaging overhead without additional value.

Use MCP when the agent needs a capability boundary

An MCP server can expose tools or services such as database reads, repository operations, browser actions, or a remote business API. MCP defines the connection and interaction semantics; the server still controls authentication, authorization, data handling, and side effects.

An MCP server can exist without a plugin. A client can configure it through its native mechanisms. Package it when it belongs with related skills or when a common portable wrapper reduces client-specific configuration drift.

Use an Agent Plugin when components belong together

A plugin earns its keep when:

one or more skills and MCP servers implement one coherent capability;
the same portable components must travel across compatible clients;
authors want a versioned manifest and deterministic discovery layout;
invalid components should fail independently rather than disabling the package;
client-specific extras need a legitimate namespaced home outside the portable core.

The plugin does not make every part portable. In v1, commands, hooks, agents, and client-owned behaviors remain extensions. Other clients can ignore them.

Example: reporting workflow

Suppose a team wants an agent to query a reporting database and write a weekly summary:

The skill explains metric definitions, query order, data-quality checks, and summary format.
The MCP server exposes bounded database queries.
The plugin packages the skill plus MCP connection metadata in predictable locations.
The client and organization decide where it can be installed, which credentials it receives, what data it can query, whether writes need confirmation, how the subprocess is isolated, and how updates are trusted.

No one layer proves the others are safe or correct.

Portability is conditional

A launch list of compatible clients does not mean identical behavior. Under the v1 conformance rules, a client can support at least one component type. MCP clients may support stdio, Streamable HTTP, or both. Client extensions are deliberately ignored outside their owning namespace.

Before claiming “works everywhere,” build a compatibility matrix that records:

manifest schema version;
skill support and Agent Skills version;
MCP transport support;
environment and placeholder handling;
install, enable, update, and removal flow;
credential and permission model;
client extension use;
subprocess, filesystem, and network controls;
error reporting and user-confirmation behavior.

Security boundaries

Agent Plugins package containment prevents specified package files and paths from escaping their permitted roots. It does not sandbox a subprocess. MCP configuration headers are visible package data, not a secret mechanism. V1 defines no portable OAuth or credential-reference fields.

Review the source and version of the package, every skill instruction, every executable, remote origin, requested header, environment variable, working directory, tool action, and data destination. Grant the narrowest permissions through the client and underlying services.

Decision guide

Only reusable instructions? Start with one Agent Skill.
Only a tool or service connection? Start with an MCP server and the client’s native configuration.
Related skills and tools across clients? Add an Agent Plugin wrapper.
Client-specific hooks or commands? Put them in a namespaced extension and label them non-portable.
Need installation trust or sandbox guarantees? Define those in client and organizational policy; the v1 package format does not provide them.

Read the Agent Plugins 1.0 specification guide for the exact package contract and use the manifest, skills, and MCP authoring guide to build one. See Google’s Agents CLI and Data Agent Kit paths for two adoption examples.

Frequently asked questions

Are Agent Plugins a replacement for Agent Skills or MCP?

No. Plugins package the portable parts; Skills and MCP continue to define their respective instruction and protocol contracts.

Do I need an Agent Plugin for one skill?

Not necessarily. Use a plugin when related components need one portable wrapper or common cross-client discovery.

Does Agent Plugins make an MCP server trusted?

No. Source, permissions, credentials, isolation, trust, provenance, and approval remain separate.

Can every compatible client run every plugin component?

No. Clients differ in supported component types, MCP transports, policy, and client extensions.

Official sources

Source check: August 9, 2026. Verify current specification status, supported clients, component types, transports, and client policy before choosing a package design.