What is an Agent Plugin?
An Agent Plugin is a portable package for reusable AI-agent components. Under the open Agent Plugins 1.0 standard, a plugin is a directory with a manifest and optional Agent Skills and Model Context Protocol server definitions in fixed locations. This can reduce repeated packaging across compatible AI clients, but it does not standardise installation, permissions, sandboxing, trust or how each client behaves. Businesses must still review the contents, connections and runtime controls before using one.
An Agent Plugin is a package that lets related AI capabilities travel together.
The open Agent Plugins 1.0 standard gives compatible AI clients a predictable place to find two portable components:
- Agent Skills, which contain reusable instructions, resources and sometimes scripts;
- MCP servers, which connect an AI client to external tools or information through the Model Context Protocol.
The useful idea is packaging, not a new kind of intelligence. An Agent Plugin does not make an agent cleverer by itself. It puts capabilities that belong together into a structure another compatible client can understand.
What does an Agent Plugin contain?
At its simplest, an Agent Plugin is a directory with a plugin.json manifest. It can also contain a skills/ directory and an mcp.json file.
reports-plugin/
├── plugin.json
├── skills/
│ └── weekly-report/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── mcp.json
The manifest identifies the plugin and the version of the Agent Plugins specification it follows. Skills live in a fixed directory. MCP server definitions live in a fixed file. A compatible client does not need a different custom layout merely to discover those pieces.
Version 1.0 deliberately standardises only Skills and MCP servers. Commands, hooks, sub-agents, user-interface elements and other extensions can still be specific to an individual client.
How is an Agent Plugin different from an AI Skill?
An AI Skill carries a method. It can describe the instructions, examples, reference material, checks and output structure for a recurring type of work.
An MCP server provides access to tools or data. It might let an approved client read a reporting system, search a document collection or call a business service.
An Agent Plugin is the package around one or both of those components.
For example, a weekly-report Skill could explain which figures matter, how to investigate a change and how the report should be written. An MCP server could provide controlled access to the underlying data. The Agent Plugin would package the Skill and the connection definition together so compatible clients can discover them consistently.
That separation matters. The Skill is not the data connection. The connection is not the business method. The plugin is not the agent.
Is this the same as every ChatGPT, Claude or Copilot plugin?
No. The word “plugin” is already used by several products for their own extension systems.
An Agent Plugin with capital letters refers here to the open Agent Plugins specification and its portable structure. A provider may also support extra files or capabilities that only work in its own client. Existing Claude and Copilot plugin formats, for example, have their own layouts even where they offer similar ideas.
Compatible clients can load the standard parts they support and ignore client-specific extensions they do not understand. That gives authors a shared baseline without pretending every platform behaves identically.
Why does this matter to a business?
The immediate benefit is reduced duplication.
If a company has a useful, tested capability, it should not need to maintain several slightly different copies merely because each AI client expects a different wrapper. A shared package can make the portable parts easier to version, review and reuse.
That may help a business:
- preserve a specialist method alongside the tool connection it requires;
- move a supported capability between compatible clients with less repackaging;
- inspect one predictable directory rather than several unrelated formats;
- keep client-specific extras separate from the portable core;
- reduce drift between duplicated versions of the same Skill or MCP configuration.
For a Scottish SME, the practical opportunity is not to build a marketplace of plugins. It is to avoid locking a proven method unnecessarily to one interface. A reporting, document-review or service-triage capability may be more valuable if its core method and connection definitions can move with the business.
Portability is still only useful when the underlying workflow is worth preserving. Packaging a weak process makes it easier to distribute a weak process.
What does the standard not solve?
Agent Plugins 1.0 is intentionally narrow. The official project documentation says distribution, installation, permissions, user experience and client-specific capabilities remain under each client's control. Google's launch explanation is even more explicit: the format defines no permission model, sandboxing requirements, trust or provenance verification.
That means the standard does not answer:
- who is allowed to install a plugin;
- whether the publisher can be trusted;
- what code or scripts should be permitted to run;
- which accounts, files or records an MCP server can access;
- where credentials are stored;
- which actions require human approval;
- how updates are reviewed or rolled back;
- whether two clients will produce the same result.
The specification includes containment and validation rules for the package structure. Those are useful safeguards, but they are not a complete runtime security system.
What should a business check before installing one?
Treat an Agent Plugin as a small software and process package, not as a harmless prompt file.
- Read the manifest and contents. Check the publisher, repository, licence, Skills, scripts and referenced files.
- Identify every connection. Review each MCP server, the tools it exposes and the information it can read or change.
- Check the client controls. Confirm how that specific product handles installation, permissions, approvals, credentials and isolation.
- Use least privilege. Start with the minimum account access and the narrowest set of tools required.
- Separate reading from writing. A first pilot can often retrieve and recommend without being allowed to send, edit, publish or delete.
- Test the method and the connection. Include missing data, malicious instructions, incorrect records, tool failures and incomplete results.
- Assign an owner. Someone must review new versions, source changes, permissions and whether the plugin should remain installed.
Microsoft's VS Code guidance warns that plugins can include hooks and MCP servers that run code on a machine, and tells users to review the contents and publisher before installation. The principle applies beyond software development: an extension that can reach live business systems deserves ordinary security, procurement and change-control discipline.
Should a small business build an Agent Plugin?
Usually not as the first step.
Start with a repeated task, a clear owner and a tested AI Skill for the business. Add an external connection only when the workflow genuinely needs live data or an action. Consider an Agent Plugin when those components belong together and portability across compatible clients would remove real maintenance work.
Google's launch guidance makes the same practical distinction: one Skill does not automatically need a plugin, and one MCP server for one client may be simpler on its own.
My view is straightforward. Build the method first. Prove the connection second. Package them together only when the package solves an actual distribution or maintenance problem.