Skip to main content
Glama
xav-ie

Browser Session MCP

await_human_takeover

Waits for the human to finish logging in on the takeover page, returning completed:true on success or false on timeout. Poll it in a background task with short timeouts to catch the Done signal.

Instructions

Wait for the human to click Done in the takeover page. completed is true if they finished, false on timeout. STRONGLY ADVISED: run this in a BACKGROUND task and POLL — call it in a loop with a SHORT timeout (e.g. 4000ms) until completed:true — rather than one long blocking call, which can exceed your MCP client's request timeout and make you miss the Done signal. The human may take several minutes; a background poller lets you be notified and resume. On completion the session is authenticated and you can continue; consider save_browser_state so later sessions skip the login. Fails on a token that request_human_takeover didn't issue or that has already completed.

Input Schema

NameRequiredDescriptionDefault
tokenYesThe token returned by request_human_takeover.
timeoutNoMilliseconds to wait before returning completed: false. Default 300000, max 1800000.

Output Schema

NameRequiredDescriptionDefault
tokenYes
completedYesTrue once the person clicked Done; false on timeout.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.5
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "properties": {
      +    "completed": {
      +      "description": "True once the person clicked Done; false on timeout.",
      +      "type": "boolean"
      +    },
      +    "token": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "completed",
      +    "token"
      +  ],
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / timeout / description
      Added value: +"Milliseconds to wait before returning completed: false. Default 300000, max 1800000."
    • addedInput schema / properties / token / description
      Added value: +"The token returned by request_human_takeover."
  3. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by documenting timeout semantics, the risk of exceeding the MCP client's request timeout, the fact that a human may take minutes, the post-completion state (session authenticated, you can continue), and the two failure modes (token not issued by request_human_takeover, or already completed). Annotations only say non-readonly/non-idempotent, which conveys far less.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and return semantics, then the polling advice and follow-ups in a logical order. Slightly dense with capitalized emphasis, but nearly every sentence carries operational information; only the resume/notify clause is mildly redundant with the polling advice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers what the agent needs to call this correctly: how to poll, what `completed` means, what happens on completion, and what causes failure. An output schema exists, so the description is not obligated to detail return structure and doesn't.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real guidance on `timeout` — use a short value (e.g. 4000ms) and poll, rather than the schema's 300000 default — which changes how an agent should set it. `token` is only referenced by provenance (returned by request_human_takeover), matching the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: wait for the human to click Done in the takeover page, and defines the success/failure signal (`completed` true/false). It is clearly distinct from siblings like request_human_takeover (which issues the token) and save_browser_state (suggested as a follow-up).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly prescribes patterns: run in a background task and poll in a loop with a short timeout (~4000ms) instead of one long blocking call, and explains why (client request timeout, missing the Done signal). It also notes the follow-on action (save_browser_state) and the failure condition for stale/completed tokens.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.