Stories
Can one website tool keep the same rules across agent clients?
by Matt Gibbs · Updated
Agent Plugins is a new open, vendor-neutral effort to give reusable agent components a portable package format. Its initial steering group includes maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel.
That work arrives as agent clients are developing their own ways of adding tools.
There are MCP servers, browser tools, Skills, plugins, embedded assistants, app directories and client-specific configuration files. That variety is understandable. Different clients have different jobs and different ways of presenting capabilities to their users.
But it creates a problem for anyone building the tools behind them.
If I describe the same website capability separately for every agent client, I do not really have one capability anymore. I have several copies of it. One copy may accept different inputs. Another may return more information. Another may omit an important limit. Another may accidentally be treated as writable when it was meant to be read-only.
The packaging has started to control the product.
That is exactly what I do not want for Open for Agents.
The website owner's reviewed decision should remain authoritative: what the capability does, what it may read or change, which inputs it accepts, how much it returns, and where approval is required. MCP, WebMCP, plugins and an embedded Assistant should carry that decision to different places. They should not each invent their own version of it.
I recently ran a small experiment to find out whether that distinction works in practice.
Can one capability keep the same rules in a new client?
Agent Plugins 1.0 is the emerging specification behind that effort. A package can bring together instructions, Skills and MCP tools in a form that a compatible client can discover and install.
Version 1.0.0 is still a working draft, so I tested one narrow question:
Could I take one capability that Open for Agents already understands, package it for a new agent surface, and keep its contract intact?
If the answer was yes, a website owner could review the capability once and publish the same rules in each supported format.
The test used one read-only documentation search
I used a read-only capability called search_documentation.
Its job is straightforward. It accepts a search query and returns a short list of relevant passages from reviewed documentation. It can also accept the identifier of the page the visitor is currently reading, which helps it understand context.
The limits mattered more than the search itself:
- The query is required and cannot exceed 200 characters.
- The current-page identifier is optional and must use the expected format.
- The capability is read-only.
- It returns no more than five results.
- It cannot roam across the web.
- It cannot change anything.
For the experiment, which I ran on 10 August 2026, I used a small fictional documentation set. It was not connected to the live Open for Agents service, a production database, customer information or a model provider. That kept the test focused on interoperability rather than hiding the result behind a much larger system.
I packaged the capability with an Agent Plugins manifest, an MCP configuration, a Skill explaining when to use it, and a small local MCP server.
Then I installed it into an isolated Codex environment.
Codex installed and called the tool
Codex found the package. It found the Skill. It started the MCP server and discovered the search_documentation tool.
I then called the tool through Codex's own MCP interface. The request returned three relevant results from the fictional documentation set.
This checked the client's actual installation, discovery and invocation path, not just whether the local server could answer a request.
There was no model call involved. The result did not depend on whether a model chose the right tool or wrote a persuasive answer. It was a direct test of the package and its contract.
The tool kept the same limits
The search returned results and kept every tested rule.
Codex saw the same tool name, description and input schema. The 200-character query limit remained in place. The optional page identifier kept its validation rule. The tool remained read-only. The result ceiling remained five.
No additional tools appeared. The package did not gain general web access, production credentials or broader authority.
These details are easy to lose when a capability is copied for a new client. Removing the query limit could make a request expensive. Dropping the read-only classification could change how a client explains or approves the tool. A second copy of the schema could fall behind the live product.
A portable package is useful only if it keeps the capability's limits and permissions.
Invalid calls still failed
I also tried calls that should not work.
An unknown tool name failed. An empty query failed. A query longer than 200 characters failed. Unexpected arguments failed.
I then broke the two layers separately.
A malformed Skill was rejected by the Skill validator, but it did not alter the MCP server's authority. A broken MCP command did not corrupt the Skill itself.
That separation is healthy. A Skill can help a client understand when and how to use a capability, but it should not be able to grant the server new powers. The server still decides which calls are allowed.
Open for Agents follows the same rule. Instructions can improve how a tool is presented and used, but they must not grant powers that the website owner did not approve.
Codex needed only a small adapter
I tested with an early Codex build that supported portable Agent Plugins. This particular installation still needed two small client-specific configuration files to present the package and start its MCP server. The portable package itself remained unchanged.
This showed that the portable package could retain its meaning behind a small Codex-specific adapter. It did not prove that this Codex version could install the package without those client-specific files.
The Codex files changed presentation and installation, not meaning. They did not rename the tool, widen its inputs, relax its limits or grant it new authority.
Clients will continue to have different packaging conventions. The important thing is that an adapter stays thin: it should translate the package into the client's expected shape without redefining the capability.
Uninstalling removed the tool and server
Installation is only half of a plugin lifecycle.
After the test, I removed the package. Codex no longer reported it as installed. The MCP registration disappeared. No server process remained. The experiment did not alter my normal Codex configuration, and no package data escaped the isolated test environment.
Agent plugins can start processes, register tools and introduce configuration. Clean removal is part of being portable.
The contract held in one Codex test
The experiment showed that one reviewed Open for Agents capability could be packaged for Agent Plugins 1.0 and used through Codex without weakening its contract.
It did not prove universal portability. I did not test VS Code or another independent client, remote publication, signing, version updates, marketplace distribution, the live Open for Agents service or a package containing dozens of capabilities.
Agent Plugins itself is still developing. This result applies to one real client: the capability kept its reviewed rules while a thin adapter handled the Codex packaging.
Owners should not repeat the same decision for every client
A website owner should not have to approve the same capability again for every agent client.
The owner should be able to review a capability once:
- This information is public.
- This tool is read-only.
- These are its accepted inputs.
- This is the maximum result.
- This action changes state and requires approval.
- This action must remain human-only.
Open for Agents can publish that same reviewed definition wherever it is useful.
An MCP client may discover it through an MCP server. A compatible browser may receive it through WebMCP. A visitor may use it through the optional site Assistant. An agent client may eventually install it as part of a portable plugin package.
Each client should receive the same limits and approval rules even when its packaging differs. This avoids maintaining separate copies that can drift apart.
Website owners could support more agent clients
If portable agent packages mature, they could give website owners another way to meet users where they already work. A developer might install a reviewed documentation capability in a coding client. A publisher or merchant might offer limited tools without handing over unrestricted access to the underlying system.
The client would provide the interface. Open for Agents would still limit the website information and actions available through it.
That lets people choose an agent client without forcing the website owner to maintain a separate capability for that vendor.
The next comparison should use an independent client
The same unchanged package can now be tried in a second independent client. It should expose the same tool, schema, limits and read-only classification. The same valid call should work. The same invalid calls should fail. Installation and removal should leave the client clean.
A matching result would show that the same package and rules work in more than one client.
Only after that repeat result would a larger package or a connection to an isolated Open for Agents test site be useful.
Keep the website owner's rules unchanged
Agent formats will keep changing. Website owners should not have to redefine a capability each time.
This experiment kept search_documentation read-only, limited queries to 200 characters and returned no more than five results after it was packaged for Codex. Other clients still need to be tested.