Agent Plugins: Build Your AI Tools Once, Use Them Across Apps

OpenAI has announced Agent Plugins, an open standard designed to solve a problem that has quietly become expensive: every AI agent client has its own way of loading instructions, tools and integrations.

If you build a useful capability for one agent, you often have to rearrange it, rewrite configuration files or duplicate it before another agent can use it. Agent Plugins creates a shared package format for the pieces that can travel.

The practical promise is straightforward: build a plugin once, then load it into compatible agent clients.

That matters if you want AI agents to use your own software, internal APIs, scripts or business systems rather than being limited to the tools supplied by the platform.

What Agent Plugins actually is

An Agent Plugin is a self-contained folder with a required

plugin.json

• Agent Skills: instructions, reference material and scripts that teach an agent how to carry out a particular job.
• MCP server configuration: connections to tools and data through the Model Context Protocol.

A minimal package looks like this:

text
my-plugin/
├── plugin.json
├── skills/
│   └── create-customer-quote/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

The manifest identifies the plugin and the version of the Agent Plugins specification it uses. The

skills/

mcp.json

Version 1.0 supports MCP connections over

stdio

This is not a new app store, deployment service or permission system. Distribution, installation, updates, user experience and permissions still belong to each client. Agent Plugins provides the common packaging layer underneath them.

Skills explain the job. MCP provides the tools.

The easiest way to understand the format is to separate knowledge from action.

A skill can explain:

• when to use a tool;
• what information is required;
• which steps must happen in order;
• what safety checks to run;
• how to format the result;
• how to handle common failures.

An MCP server can then expose the live capabilities needed to finish the job:

• search customer records;
• create a quote;
• update a project board;
• query an inventory system;
• generate a report;
• deploy an application;
• call your own API.

Put them together and the agent gets both the operating procedure and the controlled connection to the underlying system.

That is far more useful than giving an agent a generic API description and hoping it works out the rest.

How this helps people use their own tools

Imagine you run a small software company with a quoting app. Your team already has an API that can read customer details, calculate prices and create a draft quote.

Today, you might configure that API separately in ChatGPT, Cursor and VS Code. You may also have to paste the same working instructions into each product: check the customer first, never overwrite an approved quote, flag discounts above 15 percent, and save drafts for human review.

With an Agent Plugin, you could package the capability once:

1. CODE

   plugin.json

   identifies your quoting plugin.
2. A
   CODE

   create-customer-quote

   skill describes the process and safeguards.
3. CODE

   mcp.json

   connects the client to your quoting API through an MCP server.
4. Supporting references document fields, pricing rules and error handling.

A compatible client can discover the skill and map the MCP configuration into its own runtime. The user can then ask:

“Create a draft renewal quote for Acme using the current account terms. Flag anything that needs approval.”

The agent has a defined method, access to the right tools and clear boundaries. Your business logic stays in your app. The portable plugin describes how an agent should use it.

The same pattern works for many other products:

• A CRM plugin that finds accounts, prepares follow-ups and logs approved notes.
• An ecommerce plugin that checks stock, drafts product updates and opens fulfilment tasks.
• A finance plugin that reads invoice status, drafts reminders and routes risky cases to a person.
• A support plugin that searches product documentation, checks an account and drafts a response.
• A developer plugin that runs internal validation, opens deployment previews and checks release rules.
• A research plugin that searches a private knowledge base, preserves citations and produces a structured brief.

You are not moving the whole application into the agent. You are exposing a controlled set of useful actions and packaging the instructions that govern them.

Why portability matters

The current AI tool market moves quickly. Teams switch editors, add new agent clients and run different products for different jobs. An integration tied tightly to one client can become another piece of software you have to maintain.

A shared format reduces that duplication.

The official compatibility list currently includes GitHub Copilot, Kiro, Cursor, ChatGPT and Codex, and VS Code. These clients can adopt components incrementally, so you still need to check which skills and MCP transports each one supports. The standard does not guarantee that every plugin behaves identically everywhere.

Even with that limitation, the direction is useful. Your durable asset becomes the capability itself: the skill, the tool connection, the safeguards and the references. The client becomes a place where that capability can run.

For independent developers, this could mean shipping an agent-ready companion to an existing app. For internal teams, it could mean maintaining one approved package for company tools instead of a folder of slightly different configurations. For agencies, it could mean building repeatable client workflows that are easier to install across supported environments.

A sensible way to start

Do not begin by exposing your entire product.

Choose one narrow workflow with a clear result, such as creating a draft support reply or checking a deployment. Then:

1. Define the job. Write down the trigger, required inputs, expected output and failure cases.
2. Expose the smallest tool surface. Give the MCP server only the actions needed for that job.
3. Write the skill. Explain the sequence, constraints, approval points and output format.
4. Keep secrets outside the package. Use the client or server’s credential mechanism. Do not put API keys in
   CODE

   plugin.json

   ,
   CODE

   mcp.json

   or skill files.
5. Require review for consequential actions. Draft first when the plugin touches money, customers, production systems or published content.
6. Test in more than one client. Portability is the goal, but clients still control installation, permissions and runtime behaviour.
7. Version the package. Treat it like software: validate changes, document compatibility and keep a rollback path.

The best first plugin is boring. It does one useful job reliably and makes its boundaries obvious.

What this could change for app builders

Apps have traditionally offered a user interface and an API. Agent Plugins points toward a third product surface: a packaged way for agents to understand and operate the app.

That gives builders a cleaner route to make existing products useful inside AI workflows. Instead of creating a separate bespoke integration for every assistant or coding agent, they can maintain a portable core made from skills and MCP connections. Client-specific features can still be added as extensions when they are genuinely needed.

The standard is early, and adoption will determine how useful it becomes. But the design addresses a real problem. People want agents to use the tools they already rely on. Developers need a way to provide that access without rebuilding the same integration for every client.

Agent Plugins gives them a common place to start.

Sources

• OpenAI Developers announcement on X
• Agent Plugins overview
• Build an Agent Plugin
• MCP server configuration
• Compatible clients