Skip to main content
Glama
Sign In
Browser MCP

Browser MCP

by Agent360dk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_solve_captcha

Detect CAPTCHAs on the current page and work through them, one action per call. "detect" reports reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and FunCaptcha. "click_checkbox" tries the reCAPTCHA checkbox and detects again.

Instructions

Detect CAPTCHAs on the current page and work through them, one action per call. "detect" reports reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and FunCaptcha. "click_checkbox" tries the reCAPTCHA checkbox and detects again. "click_grid" clicks the reCAPTCHA image-challenge cells you choose; this tool returns no image, so take one with browser_screenshot first. "ask_human" returns the message to show the user with browser_ask_user.

Input Schema

NameRequiredDescriptionDefault
gridNoFor click_grid: the size of the reCAPTCHA image grid in your screenshot, 3 (3x3) or 4 (4x4).
cellsNoGrid cell indices to click (0-indexed, left-to-right, top-to-bottom) for image challenges. E.g. [2, 5, 7] to click cells 3, 6, 8. Pass grid to say which grid you see; without it, the grid is read as 4x4 only when an index is 9 or higher.
actionNoAction to take. "detect" scans for CAPTCHAs. "click_checkbox" clicks the reCAPTCHA checkbox. "click_grid" clicks specific reCAPTCHA grid cells (pass cells, and grid 3 or 4). "ask_human" returns the message to show the user with browser_ask_user; it shows nothing itself. Default: "detect"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.30.2
    • changedInput schema / properties / action / description
      Previous value: -"Action to take. \"detect\" scans for CAPTCHAs. \"click_checkbox\" clicks the reCAPTCHA checkbox. \"click_grid\" clicks specific grid cells (pass cells param). \"ask_human\" shows overlay to user. Default: \"detect\""New value: +"Action to take. \"detect\" scans for CAPTCHAs. \"click_checkbox\" clicks the reCAPTCHA checkbox. \"click_grid\" clicks specific reCAPTCHA grid cells (pass cells, and grid 3 or 4). \"ask_human\" returns the message to show the user with browser_ask_user; it shows nothing itself. Default: \"detect\""
    • changedInput schema / properties / cells / description
      Previous value: -"Grid cell indices to click (0-indexed, left-to-right, top-to-bottom) for image challenges. E.g. [2, 5, 7] to click cells 3, 6, 8."New value: +"Grid cell indices to click (0-indexed, left-to-right, top-to-bottom) for image challenges. E.g. [2, 5, 7] to click cells 3, 6, 8. Pass grid to say which grid you see; without it, the grid is read as 4x4 only when an index is 9 or higher."
    • changedInput schema / properties / cells / items / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / grid
      Added value: +{
+  "description": "For click_grid: the size of the reCAPTCHA image grid in your screenshot, 3 (3x3) or 4 (4x4).",
+  "enum": [
+    3,
+    4
+  ],
+  "type": "number"
+}
  2. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the one-action-per-call stateful pattern, that 'click_grid' returns no image (a genuinely non-obvious trait), and that 'ask_human' shows nothing itself but returns a message. It doesn't cover failure/detection-negative behavior, permissions, or rate limits, which keeps it from a 5.

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-loaded with the core verb, then four tight sentences mapping one-to-one to the action enum. There is some duplication between the body text and the 'action' parameter description, but the structure is dense and every sentence carries actionable information.

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

Completeness4/5

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

For a 3-param, no-annotation, no-output-schema tool, the description covers the action state machine and its cross-tool dependencies well enough to drive correct invocation. It could be more complete about what 'detect' reports back and what happens when solving fails, but nothing essential for calling it is missing.

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 description coverage is 100%, so the schema already documents 'action', 'grid', and 'cells' thoroughly, including the 0-indexed ordering and the 4x4 fallback rule. The prose largely restates the enum meanings; its added value is sequencing (pass cells together with grid), which is closer to usage guidance than parameter semantics. Baseline 3 applies.

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?

The description states a specific verb and resource (detect and work through CAPTCHAs on the current page) and then enumerates the four concrete action modes with what each one does. It distinguishes itself from siblings by naming browser_screenshot and browser_ask_user as the tools that complement specific actions.

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

Usage Guidelines4/5

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

Each action is given a clear usage context: 'click_grid' requires a prior browser_screenshot because the tool returns no image, and 'ask_human' requires browser_ask_user to actually display anything. What's missing is explicit when-not-to-use guidance (e.g. when to give up and escalate, or when the CAPTCHA is unsolvable), so it stops just short of a 5.

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

Deploy Server

Other Tools