Airbrowser

Overview Schema Source Related Servers Discussions Admin

solve_captcha

Attempt to solve CAPTCHA challenges by automatically detecting and clicking checkbox or slider controls via CDP, supporting Turnstile, reCAPTCHA, hCaptcha, and DataDome.

Instructions

Attempt a SeleniumBase CDP-based CAPTCHA interaction, such as clicking a CAPTCHA checkbox, or performing a drag/drop action on a slider CAPTCHA.

This tool attempts to interact with CAPTCHA controls such as Cloudflare Turnstile, reCAPTCHA, hCaptcha, DataDome Slider, or FriendlyCaptcha via the Chrome DevTools Protocol (CDP), which is usually stealthier than JavaScript because CDP actions can avoid triggering isTrusted: false.

This tool automatically detects the coordinates of CAPTCHA checkboxes for determining the correct location to perform the click. If no CAPTCHA is detected on the current page, then no click action is attempted.

The tool does not guarantee that the CAPTCHA was solved. Some CAPTCHA controls are embedded inside shadow DOM or otherwise do not expose an easy success signal. A successful attempt may result in changes to page state or browser cookies.

Tool workflow: 1. Inspect the webpage with get_content when you need to determine whether CAPTCHA-related controls are present. 2. Call 'solve_captcha' to attempt the CAPTCHA interaction. 3. Use 'get_page_info', 'get_content', 'check_if_condition', or 'manage_cookies' to inspect resulting page/session state.

Returns: A message confirming that the CAPTCHA interaction was attempted. The message is the same for both successful and failed attempts.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.15.0Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It honestly states that success is not guaranteed, that the return message is identical for success and failure, that the action may change page state or cookies, and that shadow DOM may prevent detection. It also explains the CDP mechanism and why it is stealthier.

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

Conciseness5/5

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

The description is longer than average but every section earns its place: purpose, mechanism, behavior, workflow, and return-value caveat. It is front-loaded with the core purpose, uses clear section breaks, and contains no filler or repetition.

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?

For a no-parameter tool with an output schema and no annotations, the description is fully self-sufficient. It explains when to invoke it, what will happen, what will not happen, and how to verify the outcome using sibling tools. Nothing essential for correct invocation is missing.

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?

The input schema has zero parameters, so there is nothing for the description to explain beyond the schema. The description correctly focuses on behavior rather than arguments. This matches the baseline for parameter-free tools.

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 opens with a specific verb and resource: 'Attempt a SeleniumBase CDP-based CAPTCHA interaction,' and enumerates concrete interactions (checkbox click, slider drag/drop). It also names target providers (Cloudflare Turnstile, reCAPTCHA, hCaptcha, etc.), making the purpose unambiguous and clearly distinct from sibling browser automation tools.

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?

The tool provides a numbered workflow that tells the agent when to inspect with get_content, when to call solve_captcha, and which sibling tools to use afterward to verify results. It also states that no click is attempted if no CAPTCHA is detected. However, it does not explicitly discuss when not to use this tool or why it should be preferred over click_element or run_javascript in CAPTCHA scenarios.

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