Skip to main content
Glama

Verify and resume

captcha_resume

Resume an existing browser session after a human CAPTCHA handoff by consuming the scoped handoff once, rechecking the challenge, and continuing only when it is cleared.

Instructions

Consume the matching task-scoped handoff once, re-inspect the existing browser session, and resume only after the current challenge is clear.

Input Schema

NameRequiredDescriptionDefault
task_idNoTask identifier used for a human handoff.
handoff_idNoOpaque identifier returned by captcha_handoff.
session_idYesConfigured browser session identifier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / handoff_id
      Added value: +{
      +  "description": "Opaque identifier returned by captcha_handoff.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / task_id
      Added value: +{
      +  "description": "Task identifier used for a human handoff.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. First observedv0.2.1

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only tell the agent this is not read-only; the description adds genuinely useful behavior — the handoff is consumed exactly once (single-use), the session is re-inspected rather than trusted, and resumption is gated on challenge clearance. It does not say what happens when the challenge is still present (error vs no-op).

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?

A single dense sentence with the critical constraint ('only after the current challenge is clear') placed at the end where it lands. No filler, though the triple-verb construction packs a lot into one line.

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

Completeness3/5

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

For a non-read-only tool with no output schema, the description covers the happy path but omits failure behavior (what is returned or thrown if the challenge is unresolved or the handoff was already consumed). That gap matters for an agent deciding whether to call it or retry.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents task_id, handoff_id, and session_id fully. The description adds only the notion that the handoff is 'task-scoped' and matched, which is marginal beyond the schema. Baseline 3 applies when the schema carries the load.

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

Purpose4/5

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

States a specific verb chain (consume, re-inspect, resume) against concrete resources (task-scoped handoff, existing browser session). It is clearly distinguishable from captcha_handoff/inspect/wait, though it does not explicitly name which sibling it supersedes.

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

Usage Guidelines3/5

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

The phrase 'resume only after the current challenge is clear' gives a real precondition for use, which is more than nothing. However, it never names alternatives (e.g., captcha_wait vs captcha_complete) or states when NOT to call it, so an agent must infer the routing.

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