Proposal: a browser-automation capability contract for MCP servers
Context
A growing number of MCP servers expose browser automation tools. They differ widely in safety guarantees:
- Some launch a fresh headless browser per call.
- Some drive the user's real Chrome over CDP.
- Some origin-scope credentials; others do not.
- Some require human approval for mutating actions; others let the LLM act freely.
- Some verify actions with before/after evidence; others return success strings.
Today a client has no standard way to discover which of these properties a server claims. Tool descriptions are free-form, so every client must parse prose to decide whether to trust a server with sensitive flows.
Proposal
Introduce an optional capability contract, e.g. browser-automation, that a server can advertise in its capabilities. The contract would declare a set of safety invariants the server promises to uphold. A non-normative starter set:
| invariant |
meaning |
origin_scoped_credentials |
Cookies/auth headers never leave the origin they belong to. |
verified_actions |
Mutating tools return before/after state evidence, not just "OK". |
human_approval_gates |
High-risk actions can pause for user confirmation. |
sandboxed_renderer |
The browser process keeps the OS renderer sandbox on by default. |
no_identity_cookie_cloning |
Session-identity cookies for major providers are never cloned from the user's real profile. |
audit_logging |
Tool calls and decisions are logged for inspection. |
Why this helps
- Clients can warn users before connecting a low-safety browser server to a high-stakes workflow.
- Server authors can differentiate on safety without writing a whitepaper in every tool description.
- The ecosystem moves toward a baseline that protects both users and platforms from accidental data leaks or account takeovers.
Reference implementation
We are experimenting with these invariants in NeoBrowser, an open-source MCP server that drives real Chrome over CDP. The implementation is opinionated (we bias toward safety over convenience), but it could serve as one data point for what a contract might look like in practice.
Next steps
If there is appetite, I can draft a more formal proposal or reference PR against the spec. Happy to iterate here first.
Proposal: a
browser-automationcapability contract for MCP serversContext
A growing number of MCP servers expose browser automation tools. They differ widely in safety guarantees:
Today a client has no standard way to discover which of these properties a server claims. Tool descriptions are free-form, so every client must parse prose to decide whether to trust a server with sensitive flows.
Proposal
Introduce an optional capability contract, e.g.
browser-automation, that a server can advertise in itscapabilities. The contract would declare a set of safety invariants the server promises to uphold. A non-normative starter set:origin_scoped_credentialsverified_actionshuman_approval_gatessandboxed_rendererno_identity_cookie_cloningaudit_loggingWhy this helps
Reference implementation
We are experimenting with these invariants in NeoBrowser, an open-source MCP server that drives real Chrome over CDP. The implementation is opinionated (we bias toward safety over convenience), but it could serve as one data point for what a contract might look like in practice.
Next steps
If there is appetite, I can draft a more formal proposal or reference PR against the spec. Happy to iterate here first.