What Are Agent Plugins? Skills, MCP Servers, and What Changes (2026)
Agent Plugins is an open, vendor-neutral specification for packaging Agent Skills and MCP servers into one portable directory. Version 1.0.0 was published on August 6, 2026. It fixes a single manifest file and a single folder layout, so the same package loads in any compatible AI agent client.
That is the whole idea. There is no new protocol here and no new runtime. The pieces that already existed keep working, and the specification only says how to put them in a box.
This guide covers what shipped and what is inside a plugin. It also covers what the spec refuses to define, and what changes for anyone who uses agents to produce analysis.
What shipped on August 6, 2026
Two official posts went up the same day. Vercel published the announcement written by Jonathan Hefner. Google published its own post from Kevin Hou, Haoyu Wang and Alan Blount on the Google Developers Blog.
Vercel's post states that Vercel initiated the proposal. Representatives from Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI and Vercel then refined it into 1.0.0.
The post also lists the clients that support the format at launch: ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code. Google's post names two of its own products: the Agents CLI and the Data Agent Kit. The Data Agent Kit ships plugins for BigQuery, Spanner and Cloud SQL.
One detail is worth keeping straight. The specification repository was created on April 3, 2026, so August 6 marks the 1.0.0 release rather than the start of the work. Coverage that treats those two dates as the same thing overstates how quickly this came together.
Who is behind it
The project publishes its Technical Steering Committee in a MAINTAINERS.md file. As of August 2026 it lists five Core Maintainers. They are Clare Liguori of Amazon, Roshan Sadanani of Cursor and Harald Kirschner of Microsoft. The list also names Gav Verma of OpenAI and Jonathan Hefner of Vercel. Hefner is listed as Lead Core Maintainer.
Google's announcement says Google joined as a Core Maintainer, represented by Kevin Hou. That addition is not yet reflected in the published maintainers file.
Licensing is split. The repository's own licensing notice puts specification text, documentation and examples under CC BY 4.0. Schemas, source code and scripts fall under Apache 2.0.
What is actually inside a plugin
A plugin is a directory. The specification keeps the required surface deliberately small.
The manifest is plugin.json, and only two fields are required. The $schema field declares which version of the specification the package targets. For 1.0.0 that value is https://agent-plugins.org/schemas/1.0.0/plugin.schema.json.
The second required field is name. It must be 1 to 64 characters, drawn from a-z, 0-9, - and ., and it must start and end with an alphanumeric character. Doubled separators such as -- and .. are rejected.
Everything else in the manifest is optional: version, description, author, homepage, repository, license and keywords.
Components live at fixed paths rather than being declared inline. Skills come from a skills/ folder, where each immediate child directory containing a SKILL.md file counts as one skill. MCP servers are declared in mcp.json.
That last constraint is the interesting one. The manifest cannot relocate components and cannot define them inline. A reader can therefore tell what a plugin contains by listing two paths.
A worked example makes the shape obvious. A plugin that produces a monthly revenue summary would carry one skill folder holding the reporting instructions, and one mcp.json entry pointing at the warehouse. Nothing about that arrangement is client-specific, which is the entire point.
What the specification deliberately leaves out
The list of exclusions is longer than the list of requirements, and it is stated openly.
The spec does not define the skill format itself, which belongs to the Agent Skills specification. It does not define MCP wire behaviour, which belongs to the Model Context Protocol. It does not define the contents or validation of client-specific extensions. It does not define fallback behaviour after a transport connection fails.
Google's post adds the rest of the boundary. Installation mechanisms, distribution protocols, permissions, sandboxing, trust verification and user experience are all out of scope.
The omission of trust verification deserves a moment. A plugin can declare an MCP server that reaches any endpoint, and the specification does not judge whether that endpoint deserves access. Review remains a human job, or a job for whichever client loads the package.
This is a packaging format and nothing more. Anyone hoping for an app store with review and signing will not find one here.
Why a packaging standard matters for data work
Most people who ask an agent for a chart never think about packaging. The connection is still direct.
An agent can only produce a real deliverable if it can reach two things: instructions for the task, and access to the data. Skills carry the first. MCP servers carry the second. Until now, shipping both together meant a different wrapper for every client.
Duplication has a predictable cost. Wrappers drift. One client gets a fix and another does not. The version that reads your warehouse then falls behind the version that writes the summary. The failure shows up as a stale number in a finished report.
Teams that maintain their own internal skills feel this most. A finance group with a close-process skill and a warehouse connector currently ships them separately, then repeats the wiring for each editor the team uses. One package replaces that with one folder in version control.
A shared package format removes that particular class of drift. It does not make an agent better at analysis, and it should not be sold as though it does.
Where a plugin standard stops helping
A packaging spec assumes you already have the pieces. It says nothing about their quality, and it will not tell you whether a skill produces a defensible chart.
This is the gap worth naming honestly. Powerdrill Bloom already exposes both of the things the format packages. It runs Claude Skills for research, analysis, automation and execution. It also ships its own MCP server, so a compatible client can browse datasets and run jobs by request.
What it adds beyond the plumbing is the part the spec leaves alone. You upload a spreadsheet, ask a question in natural language, and get back a chart, a written summary or a deck. The packaging layer decides how tools travel between clients. It does not decide whether the answer is any good.
For a broader survey of that ecosystem, our roundups of MCP platforms and agent skills for data analysis and reporting cover the current field.
Adjacent standards worth knowing
Three specifications now sit next to each other, and they are easy to confuse.
| Standard | What it defines | Scope |
|---|---|---|
| Agent Skills | How a single skill is written | Instructions and resources |
| Model Context Protocol | How an agent talks to a tool or data source | Runtime protocol |
| Agent Plugins | How skills and MCP servers ship as one unit | Packaging only |
Reading the scope column is the fastest way to avoid a category error. A question about how an agent authenticates to a database is an MCP question. A question about how to hand a colleague the whole setup is a packaging question.
The three are complementary by design. A plugin contains skills and MCP server declarations, and each of those remains independently portable outside the plugin.
Conclusion
Agent Plugins 1.0.0 is a small specification with a narrow job. One manifest, two required fields, two fixed component paths, and an explicit refusal to define installation, permissions or trust.
The value shows up over months rather than on day one. Fewer wrappers means fewer places for a tool to fall out of sync. That matters most when the output is a number someone will act on. If you want the analysis layer rather than the plumbing, try Powerdrill Bloom on a file you already have. See also our auto insights page.
Facts in this article were verified against official sources on August 11, 2026. Specification details change, so check the linked pages before relying on a field name.
Frequently asked questions
What are Agent Plugins in simple terms?
They are a standard way to bundle an agent's skills and its MCP server declarations into one folder. Any compatible client can then load that folder without a client-specific wrapper around it.
Is Agent Plugins the same as MCP?
No. MCP is a runtime protocol that governs how an agent talks to a tool or a data source. Agent Plugins only governs packaging, and a plugin can declare MCP servers inside it.
What is required in plugin.json?
Only two fields. The $schema value declares the specification version being targeted, and name identifies the plugin. Everything else, including version and license, is optional metadata.
Which tools support Agent Plugins?
Vercel's launch post lists ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code. Google separately announced support in its Agents CLI and Data Agent Kit.
Does Agent Plugins handle installation or permissions?
No. Installation, distribution, permissions, sandboxing and trust verification are all explicitly out of scope. The specification covers the package layout and nothing beyond it.