How to Enable Human-in-the-Loop (HITL) Approvals for WebMCP Tools

Short answer: To enable human-in-the-loop for WebMCP, bridge the WebMCP site through the Webmcp Trail extension into a guarded MCP server, then flip the per-tool HITL switch. Once HITL is on, a matching tools/call pauses in a pending queue until a person approves it — the call only executes in the tab after approval, and every Approve or Deny decision is written to the audit log.

WebMCP is powerful precisely because it lets an AI client drive a live web app the way you would: as the logged-in user, inside a real session, with real side effects. That same power is why WebMCP approvals matter. A tool named place_order, change_seat, or delete_record does exactly what it says the moment it is called — there is no native “are you sure?” step. Human-in-the-loop for WebMCP closes that gap by pausing sensitive calls until a person signs off.

If you are new to the protocol, start with What is WebMCP and How to add WebMCP to a website. This guide assumes you have a WebMCP site running and want to add approvals on top of it.

Why WebMCP needs human-in-the-loop

WebMCP tools execute in the browser under the current user’s identity. There is no server-side gatekeeper deciding whether a given call is reasonable, and the protocol itself does not define an approval step. That means a WebMCP tool call is, by default, a fire-and-forget action with real consequences.

Consider what a single call can do on a live site:

• Place or cancel an order and charge a saved payment method.
• Change a booking, a seat, or a shipping address.
• Delete a record, revoke access, or update account settings.

An AI client that mis-parses a request, or a compromised prompt, can trigger any of these. Human-in-the-loop for WebMCP means a person reviews the exact tool and arguments before the action runs. Read-only lookups can stay fast; state-changing actions get a checkpoint. That is the trust boundary security teams need before letting agents touch production web apps.

Prerequisites: a bridged server and the right scopes

WebMCP HITL is enforced at the MCP Trail proxy, so the first requirement is that every tools/call actually crosses the proxy. That happens once you bridge the site through the extension.

You will need:

• Chrome 150 or newer, with WebMCP testing enabled at chrome://flags/#enable-webmcp-testing.
• The WebMCP site bridged via the Webmcp Trail extension into a guarded MCP server. The full walkthrough is in Turn a WebMCP site into a guarded MCP server with auth and logs.
• An API key with policies:read and policies:write scopes so the per-tool HITL switch can read and write tool policies.

Once the site is bridged, the extension detects the tools the page exposes and lists them — that list is where you turn approvals on.

Enabling HITL per tool from the extension

Approvals in MCP Trail are set per tool, not all-or-nothing. Each detected WebMCP tool in the extension popup has its own HITL switch, so you can pause the risky calls and let the safe ones run.

The switch maps to a policy:

• Switch ON writes the tool’s policy to hitl. Every matching tools/call pauses for approval.
• Switch OFF writes log_allow. The call still runs, but it is recorded in the audit log — it is never silently auto-allowed.

That is the key detail for security-minded teams: turning a tool “off” for approval does not turn off visibility. A log_allow tool is fully logged and auditable; you simply chose not to require a human on that specific action.

You can set the same policies from the MCP Trail dashboard, per server and per tool, if you would rather manage them centrally than from the popup. Both surfaces write to the same policy store, so a switch flipped in the extension shows up in the dashboard and vice versa.

The fail-secure default: no policy means HITL

New and unknown WebMCP tools do not get a free pass. A tool with no policy set defaults to HITL. Until you make a decision about it, calls to that tool require approval.

This matters because WebMCP sites evolve. If a site ships a new tool tomorrow — say the page adds transfer_funds — that tool arrives with no policy, so it defaults to requiring approval. It cannot silently get auto-run just because it is new. You decide, per tool, whether it should stay HITL, drop to log_allow, or be blocked. The safe state is the default state.

What an approver sees: the pending to approve/deny flow

When a HITL tool is called, the proxy holds the tools/call in a pending state instead of executing it. Nothing runs in the tab yet.

An approver then sees:

• The tool name being called.
• The arguments passed to it.
• Approve and Deny controls.

Only after an approver clicks Approve does the call execute in the tab and return its result to the client. If they Deny, the call never runs. Either way, the decision is recorded in the MCP audit log, tied to the specific request — so you always have a record of who approved what, and with which arguments. This is the same review model described in MCP human-in-the-loop approvals, applied to browser-based WebMCP tools.

Auto-allow vs Log-allow vs HITL

Behavior	Runs immediately?	Logged?	Requires a human?	Good for which tools
Auto-allow (not offered)	Yes	No	No	Nothing — silent execution is the risk MCP Trail removes
Log-allow (log_allow)	Yes	Yes	No	Read-only or low-risk tools: search, list, get, status
HITL (hitl)	No, pauses first	Yes	Yes	State-changing tools: place order, delete, change seat, pay

MCP Trail deliberately does not offer a silent auto-allow. The lowest-friction setting, log_allow, still writes to the audit log. The point is that you always have visibility, and you add a human wherever the action is worth pausing for.

Routing approvals to Slack and email

Approvals do not have to live in one screen that someone has to watch. Pending WebMCP tool calls can be routed to Slack or email alerts, so the right person gets pinged the moment a call is waiting. That keeps agents moving without forcing anyone to babysit a queue, and it means a sensitive place_order at 2 a.m. reaches an on-call human instead of stalling silently.

Combining HITL with drift attestation

Human-in-the-loop answers “should this call run right now?” Drift attestation answers “is this still the site I approved?” Together they stop silent changes from executing.

MCP Trail snapshots the approved toolset when you bridge a WebMCP site — this is drift attestation. If the site later changes a tool (renames it, alters its schema, or swaps its behavior), calls are blocked until you re-approve the new shape. A site cannot quietly redefine search into something that moves money and have it sail through on the old policy.

So the layered picture is:

1. Drift attestation confirms the toolset matches what you signed off on. Changed tools are blocked until re-approved.
2. HITL pauses sensitive calls on the approved tools until a person says yes.
3. The audit log records every decision, tied to the request.

That is how HITL plus drift together close the “a site changed something and it just ran” gap that makes WebMCP risky by default.

FAQ

What is human-in-the-loop for WebMCP?

Human-in-the-loop for WebMCP is an approval checkpoint on browser-based tool calls. When a WebMCP site is bridged through the Webmcp Trail extension into a guarded MCP server, you can mark a tool as hitl. A call to that tool pauses in a pending state at the MCP Trail proxy until a person reviews the tool name and arguments and clicks Approve or Deny. Only then does it run in the tab.

Do read-only WebMCP tools need approval?

They do not have to. You set policies per tool, so a safe read-only tool like search or list_items can be set to log_allow — it runs immediately but is still recorded in the audit log. Reserve HITL for state-changing actions such as placing an order, changing a seat, or deleting a record. Note that any tool with no policy at all defaults to HITL, so you approve it once and then decide where it belongs.

What happens to a call while it waits for approval?

Nothing executes yet. The proxy holds the tools/call in a pending state and does not run anything in the tab. The approver sees the tool name and its arguments. If they Approve, the call executes and the result returns to the client. If they Deny, the call never runs. Both outcomes are written to the audit log against that request. If alerts are configured, the pending call is pushed to Slack or email so it does not sit unnoticed.

Can I get approval alerts in Slack?

Yes. Pending WebMCP approvals can be routed to Slack or email, so the moment a HITL call is waiting, the right person is notified. That lets agents keep working on the auto-allowed tools while a human handles the ones that need a decision.

Explore features · Use cases · Open MCP Trail

Related articles

• What is WebMCP — a plain-language introduction to the protocol that lets AI clients drive a live web app as the logged-in user.
• How to add WebMCP to a website — the developer walkthrough for exposing your site’s actions as WebMCP tools.
• Turn a WebMCP site into a guarded MCP server with auth and logs — the companion post on bridging a WebMCP site through the extension so every call crosses the proxy.
• MCP human-in-the-loop approvals — the broader approval model for MCP, applied here to browser-based WebMCP tools.