Skip to main content
Glama
Sign In
CaptchaAI MCP Server

CaptchaAI MCP Server

Official
by CaptchaAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Solve Captcha

solve_captcha

Solves CAPTCHA challenges in token mode without a browser, returning the solved token or payload for supported challenge types.

Instructions

Solve a CAPTCHA in token mode (no browser) and return the solved token or payload.

Blocks until solved (typically 10-80s). Call get_supported_captchas() first to check which arguments are required for the chosen captcha_type. When user_agent is returned (Enterprise, Cloudflare Challenge, CaptchaFox), reuse it when submitting the token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "captcha_type": "<captcha_type>",
      "website_url": "<website_url>"
    },
    "name": "solve_captcha"
  }
}

Input Schema

NameRequiredDescriptionDefault
gtNoGeeTest public `gt` parameter (required for geetest).
proxyNoProxy string in "user:pass@host:port" format (required for cloudflare_challenge and captchafox).
actionNoAction name (required for recaptcha_v3; optional `sa=` for Enterprise v2).
div_idNoLemin target container element ID (required for lemin).
cookiesNoOptional cookies forwarded to the solver ("KEY1:Val1;KEY2:Val2;").
versionNoOptional Friendly Captcha version string.
challengeNoGeeTest `challenge` parameter (required for geetest).
invisibleNoEnable invisible mode (recaptcha_v2 only).
min_scoreNoMinimum score threshold (0.0-1.0) for recaptcha_v3.
proxytypeNoProxy protocol when proxy is set ("HTTP" or "HTTPS").
api_serverNoOptional Lemin API server URL.
captcha_idNoLemin captcha identifier (required for lemin).
enterpriseNoEnable Enterprise mode (recaptcha_v2 or recaptcha_v3).
user_agentNoOptional User-Agent string forwarded to the solver.
website_keyNoSite key (data-sitekey) for reCAPTCHA, Turnstile, CaptchaFox, or Friendly Captcha.
website_urlYesFull URL of the page containing the CAPTCHA.
captcha_typeYesCAPTCHA challenge type (e.g. "recaptcha_v2", "recaptcha_v3", "turnstile").

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries real weight here: it discloses that the call blocks for a typical 10-80s, that it runs without a browser, and that certain captcha types return a user_agent that must be reused on submission. It omits failure/timeout behavior and any cost or balance implication, which matters for a paid external solver with a get_balance sibling.

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?

Two short paragraphs with the outcome and mode front-loaded, followed by the timing expectation and the prerequisite call. Every sentence carries actionable information and there is no filler.

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 17-parameter, open-world tool with a full-coverage schema and an output schema, the description covers purpose, latency, prerequisite discovery, and post-call token submission. The remaining gap is error/timeout handling and cost awareness, which an agent calling an external paid solver would benefit from knowing.

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% and the schema already tags each parameter with its conditional requirement ("required for geetest", "required for lemin", etc.), so per-parameter meaning is fully covered elsewhere. The description only adds the meta-instruction to consult get_supported_captchas for the required set, which is a process hint rather than new parameter semantics.

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 specific verb and resource ("Solve a CAPTCHA") plus the operating mode ("token mode (no browser)") and the output ("solved token or payload"). That mode qualifier is what lets an agent distinguish this from any browser-based solving path without opening the schema.

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?

Gives an explicit prerequisite sequence: call get_supported_captchas() first to learn which arguments the chosen captcha_type requires, then call this tool. It also prescribes downstream behavior (reuse the returned user_agent when submitting the token). It stops short of stating when-not-to-use or any exclusion, so 4 rather than 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