Skip to main content
MCP Trail MCP Trail
Back to Blog
Integration • 2026-07-05

Turn Any WebMCP Site into a Guarded MCP Server with Auth and Logs

MCP Trail

MCP Trail Team

Product Team

Turn Any WebMCP Site into a Guarded MCP Server with Auth and Logs

Turn Any WebMCP Site into a Guarded MCP Server with Auth and Logs

Short answer: WebMCP tools have no built-in auth or audit. The Webmcp Trail Chrome extension bridges them through the MCP Trail proxy so they become a guarded WebMCP MCP server — with a bearer token, audit logs, policy allow/deny, drift attestation, and human approvals — with no code.

WebMCP is a fast-growing way for websites to expose tools that an AI agent can call directly inside the browser tab. It is genuinely useful: the tools run as the logged-in user, with the user’s session, cookies, and permissions already in place. If you are new to the standard, start with What is WebMCP and, if you build sites, how to add WebMCP to a website.

But there is a governance gap. Raw WebMCP tools live in the page and execute with the full authority of whoever is signed in. Out of the box, they have no authentication you can hand to an agent, no audit log of what was called, no rate limiting, no allowlist, and no approval step. You cannot point Claude Desktop or Cursor at them safely, and you cannot see or govern what they do. That is exactly the problem WebMCP auth and WebMCP logs need to solve.

MCP Trail closes the gap by turning any WebMCP site into a normal, guarded WebMCP MCP server. This post walks through the whole flow.

How MCP Trail bridges WebMCP into a guarded server

The core idea is a bridge. The Webmcp Trail Chrome extension holds an outbound WebSocket to the MCP Trail proxy. The proxy then treats the browser tab as an MCP “upstream” — internally called the webmcp_bridge kind. Every tools/call crosses the MCP Trail wire before it reaches the tab, so it flows through the same enforcement stack that hosted MCP servers already use: policy, human-in-the-loop approvals, drift attestation, audit logs, and billing.

In other words, MCP Trail becomes a WebMCP gateway. The raw browser tools are never exposed directly to your agent. Instead, your agent talks to a proxy URL protected by a bearer token, and MCP Trail relays approved calls into the tab.

Step-by-step: from browser tab to guarded MCP server

1. Install the Webmcp Trail Chrome extension

Install Webmcp Trail from the Chrome Web Store. You need Chrome 150 or newer, and you must enable the WebMCP testing flag at chrome://flags/#enable-webmcp-testing. This flag is what lets the browser surface a page’s WebMCP tools to the extension.

2. Create a management API key in MCP Trail

In the MCP Trail dashboard, go to Settings → API keys and create a management API key. The key starts with mg_mgmt_. Give it these scopes so the extension can create the server, set policy, and mint the bearer token:

  • servers:read
  • servers:write
  • policies:read
  • policies:write
  • tokens:write

3. Paste the API key into the extension popup

Open the extension popup and paste the mg_mgmt_ key. This links the extension to your MCP Trail account so anything it creates lands in your workspace, under your policies and billing.

4. Detect the tab’s WebMCP tools

Open a website that exposes WebMCP tools. The extension’s This tab section detects them automatically and lists what the page offers. Because detection is scoped to the active tab, the origin host has to match exactly — a tool on one origin will not be bridged from another.

5. One click to create a guarded server

Click Create guarded server from this site. That single action creates a browser-bridged WebMCP MCP server in your MCP Trail account and returns two things:

  • a proxy URL, for example https://app.mcptrail.com/v1/proxy/your-slug
  • a bearer token scoped to that server

Under the hood, the extension opens its outbound WebSocket to the proxy, and MCP Trail registers the tab as a webmcp_bridge upstream. From this moment every call is governed.

6. Run tools from the popup, or connect an MCP client

You now have two ways to use the tools.

From the popup. The extension renders a schema-driven form for each tool and shows the result inline — handy for testing before you wire up an agent.

From an MCP client. Point Claude Desktop, Cursor, or any MCP client at the proxy URL with the bearer token. A typical client config looks like this:

{
  "mcpServers": {
    "webmcp-trail": {
      "url": "https://app.mcptrail.com/v1/proxy/your-slug",
      "headers": {
        "Authorization": "Bearer mg_tok_your_bearer_token"
      }
    }
  }
}

If you want to sanity-check the endpoint from a terminal, you can list the tools with a simple request:

curl -s https://app.mcptrail.com/v1/proxy/your-slug \
  -H "Authorization: Bearer mg_tok_your_bearer_token" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

For a fuller walkthrough of client wiring, see connect Claude or Cursor to a hosted MCP. The setup is identical here — the only difference is that the upstream happens to be a browser tab.

One caveat: the tab that exposes the tools must stay open when a call runs, because the tools actually execute in that tab.

What you get instantly

The moment your WebMCP MCP server exists, every guardrail MCP Trail applies to hosted servers applies to it too:

  • Auth. Each server gets its own bearer token. The raw browser tools are never exposed directly — an agent only ever sees the proxy. That is real WebMCP auth, without adding an auth layer to the site itself. If you also need identity on the upstream, see how to add OAuth to an MCP server.
  • Audit logs. Every tools/call is logged with the tool name, arguments, and outcome. These WebMCP logs land in the standard MCP audit log, so you get one governed record across browser-bridged and hosted servers alike.
  • Policy. Allow or deny per tool. If a site exposes ten tools and you only want an agent using two, you allowlist those two.
  • Drift attestation. MCP Trail snapshots the approved toolset. If the site silently changes its tools — adds, renames, or alters them — calls are blocked until you re-approve, so a page update cannot quietly expand what an agent can do.
  • Rate limits and budgets. Each call is metered against your plan’s credits, so a runaway agent cannot hammer a browser tool endlessly.
  • Human approvals (HITL). Turn on per-tool approval and a person confirms sensitive calls before they run. See human-in-the-loop approvals for WebMCP for the full pattern.

Raw WebMCP tools vs WebMCP through MCP Trail

CapabilityRaw WebMCP toolsWebMCP through MCP Trail
AuthNone — runs as the logged-in userPer-server bearer token; raw tools never exposed
Audit logNoneEvery call logged with tool, args, outcome
Policy / allowlistNoneAllow or deny per tool
Drift protectionNone — tools can change silentlyApproved toolset snapshotted; drift blocks calls
Rate limits / budgetNoneEvery call metered against credits
Human approvalNoneOptional per-tool HITL confirmation
Works with Claude / CursorNot directlyYes — connect via proxy URL + bearer token

The pattern is simple: raw WebMCP is powerful but ungoverned, and the WebMCP gateway turns that power into something you can safely hand to an agent and to a team.

FAQ

Can I connect Claude or Cursor to WebMCP tools?

Not directly — WebMCP tools live in the browser tab and have no endpoint an MCP client can reach. Once you bridge the site through MCP Trail, though, you get a proxy URL and a bearer token that Claude Desktop, Cursor, or any MCP client can connect to like any other MCP server. The tab that exposes the tools just has to stay open, because that is where the tools run.

Do WebMCP tools have authentication?

Raw WebMCP tools do not. They execute with the authority of whoever is logged into the page, and there is no token to hand to an agent. MCP Trail adds WebMCP auth by issuing a per-server bearer token in front of the bridge. Your agent authenticates to the proxy, and the raw tools are never exposed directly.

How do I see logs of WebMCP tool calls?

Every tools/call that crosses the bridge is recorded in the MCP Trail audit log with the tool name, the arguments, and the outcome. Because browser-bridged and hosted servers use the same enforcement stack, your WebMCP logs sit alongside everything else in one place, rather than being invisible in the page.

Does the browser tab need to stay open?

Yes. WebMCP tools execute inside the tab that exposes them, so that tab must remain open whenever a call runs. The extension keeps an outbound WebSocket to the MCP Trail proxy while the tab is open; close the tab and the upstream goes away until you reopen it.

Explore features · Use cases · Open MCP Trail

Share this article