Skip to main content
Glama

captcha_solve

Solves CAPTCHAs via configured provider (2captcha). Pass sitekey + pageurl for Turnstile/hcaptcha; pass image_base64 for image CAPTCHAs. Stealth-first avoids challenges.

Instructions

Solve a CAPTCHA through the configured provider (env GHOSTFOX_CAPTCHA_PROVIDER=2captcha + GHOSTFOX_CAPTCHA_KEY). Turnstile/hcaptcha: pass sitekey + pageurl; image captchas: pass image_base64. Stealth-first: prefer not being challenged at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageurlNoTurnstile/hcaptcha-style: the page URL the challenge lives on.
sitekeyNoTurnstile/hcaptcha-style: the site's sitekey.
session_idYes
image_base64NoImage captcha: the challenge image as base64 PNG.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the provider configuration via environment variables and a stealth-first preference, which is useful context. However, it does not describe the output (e.g., captcha token), failure modes, network/cost implications, or what happens when stealth succeeds.

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 compact and well-structured: it opens with the primary action, states the provider configuration, then lays out the two parameter modes, and ends with a strategic note. Every sentence adds value.

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

Completeness2/5

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

With no output schema and no annotations, the description should explain what the tool returns and how the required session_id is used. It does neither. It also omits practical details like timeouts, errors, or whether the result is a token to be used elsewhere.

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 description adds meaning beyond the schema by explaining which parameters should be used together: sitekey + pageurl for Turnstile/hcaptcha, and image_base64 for image captchas. However, it does not explain the required session_id parameter, whose schema description is absent.

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 clearly states the tool's job: solve a CAPTCHA through a configured provider. It also differentiates between Turnstile/hcaptcha and image captchas, which are distinct modes of the same action. The tool is clearly distinct from the sibling page/identity/session tools.

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 description provides mode-specific guidance: use sitekey + pageurl for Turnstile/hcaptcha and image_base64 for image captchas. However, it does not explicitly state when to use this tool versus an alternative or when not to use it; the 'stealth-first' note is more philosophical than operational.

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