Experimental WebMCP Support: rustunnel Dashboard Tools for Browser Agents
rustunnel now exposes a small, security-conscious set of authenticated dashboard tools to WebMCP-aware browser agents. Here is what agents can do, what they cannot do, and how this complements the existing stdio MCP server.
The short version. rustunnel now has experimental WebMCP support on authenticated dashboard pages. When you open the rustunnel dashboard in a compatible browser, an in-browser agent can discover a small set of structured account tools and call them through your live signed-in session.
This is an experiment, not a claim of universal browser support. WebMCP remains a proposed API under active development. Chrome currently makes it available through the Chrome 149 origin trial, and the API shape and agent experience may change. Browsers without WebMCP support continue to show the normal dashboard; the integration is a progressive enhancement.
Why Put Agent Tools in the Browser?
Browser agents can already inspect pages, find controls, and simulate clicks. That works, but every visual interaction asks the agent to infer what an element means, which inputs are valid, and whether the page has changed as expected.
WebMCP lets a page register named tools with descriptions and JSON schemas. A compatible browser can present those tools to its agent, which supplies structured arguments and lets the page run the same authenticated client logic its UI uses. The result is less brittle than teaching an agent the exact location of a button or the current layout of a table.
For rustunnel, that means you can ask questions such as:
- "How much bandwidth has this account used in the last 30 days?"
- "Which API keys exist, and when were they last used?"
- "Are any load-balancing members unhealthy?"
- "Create a tunnel API key named
browser-agent-demo."
The agent does not need a separately copied dashboard credential. It works within the browser tab and the account session you have already authenticated.
What rustunnel Exposes in v1
The first version registers six tools:
| Tool | Purpose | Changes state? |
|---|---|---|
get_usage_summary | Current plan and 30-day tunnel, request, and bandwidth usage | No |
list_api_keys | API-key metadata, without raw key tokens | No |
list_tunnel_history | Recent tunnel history with pagination | No |
get_load_balancing_status | Groups, member health, and regional warnings | No |
get_billing_status | Plan, estimated usage, spend cap, and payment status | No |
create_api_key | Create one tunnel API key and return its raw value once | Yes |
The scope is intentionally account-oriented. It gives an agent useful context while you are working in rustunnel.com, with one narrow mutation for bootstrapping a CLI or agent integration.
The Security Boundary
WebMCP tools act with the authority of the page that registered them, so the registration boundary matters as much as the tool code. rustunnel's v1 follows a few strict rules:
-
Tools exist only on authenticated
/dashboard/*routes. The dashboard layout registers them when it mounts and unregisters them when it unmounts. Public marketing pages, login, registration, password reset, and other authentication pages expose no dashboard tools. -
Calls use the live authenticated browser session. Tool handlers call the same typed client used by the dashboard. The short-lived account access token stays in browser memory, and the refresh token remains in its httpOnly cookie. Neither the access token nor the refresh token is returned in a tool result.
-
Most tools are read-only. v1 exposes no billing changes, account or authentication changes, API-key deletion, tunnel deletion, or other deletion mutations. Read-only and untrusted-content annotations are applied where appropriate so capable agents can make better confirmation and data-handling decisions.
-
API-key creation is visible and throttled.
create_api_keyis client-side rate-limited to one attempt per minute. Every successful call produces a visible in-page notice naming the new key and linking to the API Keys page for review. The newly created tunnel API key is returned once to the calling agent because that is the purpose of the operation; existing raw keys are never retrievable.
These controls do not make agent execution risk-free. Agents and models can make mistakes, and WebMCP's security model is still evolving. Keep the browser UI visible, review unexpected actions, and revoke a tunnel API key if it was created or shared unintentionally. The Chrome WebMCP tool-security guidance explains the wider threat model, including prompt injection, tool annotations, and origin exposure.
WebMCP and the stdio MCP Server Do Different Jobs
rustunnel already ships a production stdio MCP server for tunnel lifecycle. It lets MCP clients such as Claude Code, Cursor, Codex, and Claude Desktop create, list, inspect, and close HTTP, TCP, and UDP tunnels. It runs alongside the agent harness and invokes the rustunnel CLI; it does not depend on an open dashboard tab.
The browser tools serve a different context:
| Browser WebMCP account tools | stdio rustunnel-mcp server |
|---|---|
| Discovered from an open authenticated dashboard page | Installed in an MCP-compatible agent harness |
| Uses the user's current browser session | Uses a rustunnel tunnel API key |
| Reads account, usage, billing, history, key, and load-balancing state | Creates and manages live tunnels |
| Experimental Chrome origin-trial integration | Existing tunnel-lifecycle integration |
They are complementary, not replacements. A browser agent can inspect the account and create a dedicated tunnel API key; the stdio MCP server can then use that key to run the tunnel lifecycle. If you prefer agent instructions around the CLI itself, install the rustunnel CLI/agent skill. For direct platform integrations, the public OpenAPI 3.1 surface documents authentication, API-key management, usage, and billing endpoints; tunnel creation remains on the rustunnel control plane and in the CLI/MCP server.
Availability and How to Try It
As of August 2026, WebMCP is not a stable cross-browser web platform feature. Chrome documents it as a proposed standard available through the Chrome 149 origin trial, with a local development flag at chrome://flags/#enable-webmcp-testing. A WebMCP-aware browser or extension must visit the dashboard before it can discover page tools.
To explore the API and its constraints, start with:
- the official WebMCP explainer;
- Chrome's WebMCP overview and origin-trial instructions;
- Chrome's imperative API documentation; and
- Chrome's tool-security guidance.
If your browser and agent support the trial, sign in and open the dashboard. If they do not, nothing about the standard rustunnel dashboard, CLI, skill, OpenAPI surface, or stdio MCP workflow changes.
We are treating this first release as a deliberately narrow learning surface: useful enough to test real account workflows, restricted enough to make every mutation easy to understand and review, and ready to evolve as the WebMCP proposal does.