Solve reCAPTCHA image grids, text captchas, GeeTest and FunCAPTCHA for AI agents. Free tier.
Scored across 6 tools
Each solve_* tool targets a distinct CAPTCHA type (FunCAPTCHA, GeeTest slider, reCAPTCHA grid, text), leaving no overlap. The two support tools (get_account_status, report_result) have clearly separate purposes.
All names follow a consistent verb_noun pattern: get_account_status, report_result, solve_funcaptcha, solve_geetest_slider, solve_recaptcha_grid, solve_text_captcha. The solve_ prefix cleanly groups the solving tools.
Six tools is well-scoped for a CAPTCHA-solving service: one solver per supported CAPTCHA family plus account and feedback operations. Every tool earns its place with no redundancy.
The surface covers account management, result feedback, and four CAPTCHA families with a clear feedback loop for improving accuracy. However, popular types like hCaptcha and Cloudflare Turnstile are absent, leaving minor gaps.
Shows the plan, the solves left today, the balance and the time until the daily reset. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | Plan name: a monthly plan, 'Free', 'Pay per use' or 'No plan'. |
| status | Yes | |
| balance_usd | Yes | |
| daily_quota | Yes | |
| solves_left_today | Yes | How many more successful solves can be paid today (daily quota left plus balance). |
| seconds_until_daily_reset | Yes | The daily quota resets at 00:00 UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=false, covering the safety profile. The description adds the genuinely useful 'free to call' cost disclosure not present in annotations, plus the returned data set. It omits auth requirements and rate/refresh behavior, so it adds some value but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the returned data and ending with the cost hint. Every clause earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema present, the description needn't explain return values. Combined with annotations covering safety, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call by describing only what is returned, with nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Shows) and enumerates the exact resource fields returned: plan, solves left today, balance, and time until daily reset. This is unmistakably distinct from the sibling solve_* tools that consume credits and from report_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free to call' implies a no-cost check an agent can perform liberally, which is a weak usage signal. However, there is no explicit when-to-use guidance, no condition selecting it over siblings, and no prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tells Solvecha whether a reCAPTCHA answer was accepted or rejected. Free, optional, and it improves accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| grid | Yes | The grid you sent: '3x3', '4x4' or '1x1'. | |
| job_id | Yes | The job_id returned by solve_recaptcha_grid. | |
| verdict | Yes | 'accepted' if the site accepted the answer (the challenge was passed or the next step appeared), 'rejected' if it did not. | |
| round_index | No | Optional: which challenge round this was, starting at 0. |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| recorded | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the write/idempotency profile is covered. The description adds genuinely useful behavioral context — the call is free and feeds back to improve accuracy — but says nothing about failure handling, whether repeated reports are harmless, or what the response indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundancy, front-loading the core action before the incentive to call. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the mutation profile and an output schema present, the description does not need to explain return values. It covers purpose, optionality and benefit; only minor guidance on when to report (e.g., after each challenge round) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains job_id, verdict, grid and round_index in detail. The description adds no parameter-level meaning of its own, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it tells the Solvecha service whether a reCAPTCHA answer was accepted or rejected. This cleanly separates it from the solve_* siblings, which produce answers rather than report verdicts. It stops short of naming a sibling explicitly, so it lands at a strong 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free, optional, and it improves accuracy' communicates the key condition for calling it: the agent doesn't have to, but should because it improves the service. It does not state when it becomes required or point to alternatives such as get_account_status, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solves a FunCAPTCHA tile-selection puzzle (mode 'tile') or a game-style match puzzle (mode 'match') and returns which tiles to pick. Costs one credit per successful solve.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'tile' picks tiles in a 3x2 grid (default). 'match' solves game puzzles where a picture must match a reference. | |
| task | Yes | The instruction text, for example 'Pick the sheep' or 'Match the number of rocks with the number on the left'. | |
| image | Yes | One picture: the grid of tiles (mode tile) or the whole game image (mode match). Base64 or https URL. | |
| timeout_seconds | No | How long to wait for the answer, 5 to 90. Default 45. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| answer | Yes | |
| job_id | Yes | |
| selected_tiles | Yes | Tiles to pick, counted from 1 (left to right, top to bottom for tile mode; in the order of the answer options for match mode). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), and the description adds genuinely new context: the one-credit cost per successful solve and the fact that it returns tiles to pick. It does not elaborate on failure/timeout behavior, but the cost note is a valuable behavioral trait not present in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the capability and modes come first, with the cost caveat second. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and the 100% schema coverage handles parameters. Cost and mode are covered, so the definition is largely complete; only failure/retry or error semantics are unaddressed, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (mode, task, image, timeout_seconds) are already documented in the schema. The description echoes the 'tile'/'match' modes but adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (solves) and resource (FunCAPTCHA / Arkose Labs puzzle) plus the two operating modes, which cleanly separates it from the sibling solvers (geetest_slider, recaptcha_grid, text_captcha). An agent can identify this as the FunCAPTCHA solver 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you call this when facing a FunCAPTCHA tile or match challenge, but it never states when-not to use it or explicitly points to the sibling solvers for other captcha types. Usage is inferred from the captcha type in the name rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solves a GeeTest slider puzzle and returns how far to drag the handle, as a percentage of the background width. Costs one credit per successful solve.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | The instruction text of the challenge. Default 'slide'. | |
| images | Yes | Either one screenshot of the whole challenge, or two pictures in this order: the background, then the transparent puzzle piece. Each is base64 or an https URL. | |
| timeout_seconds | No | How long to wait for the answer, 5 to 90. Default 45. |
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| how_to_use | Yes | |
| offset_percent | Yes | How far to drag the slider handle, as a percentage of the width of the background picture as shown on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is not read-only, is open-world and not idempotent, so the safety profile is covered. The description adds genuinely useful context beyond that: it names the exact return value (drag offset as a percentage of background width) and discloses the cost model ('one credit per successful solve'), which is important for an agent deciding whether to retry. It does not say whether failed solves still consume credits or what errors look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler: purpose first, then the concrete output contract and the cost. Nothing is repeated from the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, 1 required), an output schema exists so return values need not be spelled out here, and the description covers purpose plus the credit cost. It stops short of describing failure/retry behavior or auth requirements, which is the only real gap for a paid, non-idempotent external call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all three parameters, including the ordering of the one-vs-two image inputs and the 5-90 second timeout range. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (solves) plus the exact resource (GeeTest slider puzzle) and even specifies the return semantic (drag distance as a percentage of background width). The puzzle-type specificity distinguishes it from siblings solve_recaptcha_grid, solve_funcaptcha and solve_text_captcha without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the name and by the sibling family of captcha solvers; the description never states when to pick this over the other solve_* tools or what preconditions exist (e.g. valid challenge images, account credits available). The credit statement hints at a billing context but is not framed as a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solves a Google reCAPTCHA v2 image challenge from a screenshot and returns which tiles to click. Send the instruction text (task), the layout (grid) and the picture(s). Waits for the answer (usually 2 to 6 seconds). Costs one credit per successful solve. After you click and submit, call report_result with Google's verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| grid | Yes | Challenge layout: '3x3' or '4x4' (one picture of the whole grid) or '1x1' (single tile pictures, 1 to 9). | |
| task | Yes | The instruction text shown to the user, copied in full, for example 'Select all images with buses'. | |
| images | Yes | For 3x3 and 4x4: exactly one picture of the whole grid. For 1x1: one to nine tile pictures. Each is base64 (PNG, JPEG, GIF or WebP; a data: URL is fine) or an https URL. | |
| timeout_seconds | No | How long to wait for the answer, 5 to 90. Default 45. Solves usually take 2 to 6 seconds. |
| Name | Required | Description |
|---|---|---|
| grid | Yes | |
| answer | Yes | One boolean per tile: true means click it. |
| job_id | Yes | Pass this to report_result after you submit the answer. |
| summary | Yes | |
| positions | No | The same tiles as 'row R, column C' (3x3 and 4x4 only). |
| selected_tiles | Yes | Tiles to click, counted from 1. 3x3 and 4x4: left to right, top to bottom. 1x1: the number of the picture you sent. Empty means: click none (then press Verify or Skip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), and the description adds genuinely useful behavior beyond them: a billing model ('costs one credit per successful solve'), expected latency ('waits... usually 2 to 6 seconds'), and a required post-call ('call report_result'). It stops short of describing failure/unsolvable behavior, which would round this out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action, then inputs, then cost/latency, then the required follow-up. Every sentence carries distinct information; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it correctly focuses on inputs, cost, latency, and the report_result loop. For a stateless single-shot solve tool, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds a practical semantics hint not in the schema — that solves 'usually take 2 to 6 seconds' — which directly informs how to set timeout_seconds against its 45-second default. The restating of task/grid/images adds no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Solves a Google reCAPTCHA v2 image challenge from a screenshot') plus the output ('returns which tiles to click'). This cleanly separates it from the sibling solvers (solve_funcaptcha, solve_geetest_slider, solve_text_captcha) without needing schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: send task, grid and pictures, and explicitly routes the follow-up step ('call report_result with Google's verdict'). It does not, however, state when NOT to use it or which sibling to pick for a different captcha type, so an agent must infer the boundary from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a picture with distorted letters and digits and returns the text (case-sensitive). Costs one credit per successful solve.
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | The captcha picture: base64 (a data: URL is fine) or an https URL. | |
| timeout_seconds | No | How long to wait for the answer, 5 to 90. Default 45. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The recognised text. It is case-sensitive. |
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (openWorld, non-idempotent, non-destructive), and the description adds genuinely new behavioral context: one credit consumed per successful solve and case-sensitive output. It does not describe failure behavior (e.g. whether timeouts or bad reads are charged), which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, no filler, with the core function front-loaded and the cost caveat placed last. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return-value detail is unnecessary, and the description supplies the cost and case-sensitivity facts an agent needs. It is close to complete for a 2-parameter solver; only error/timeout handling behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (image, timeout_seconds) are already fully documented, including accepted formats and the 5-90 range. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (reads), resource (a captcha picture), and the distinguishing input type (distorted letters and digits), which separates it from siblings like solve_recaptcha_grid or solve_geetest_slider. It stops short of naming those siblings explicitly, but an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the captcha type described: it is for text captchas, not grid, slider or funcaptcha challenges. There is no explicit when-to-use, prerequisite, or fallback guidance relative to the sibling solvers, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_account_statusreport_resultsolve_funcaptchasolve_geetest_slidersolve_recaptcha_gridsolve_text_captchaSolve reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and image captchas. Platform-hosted, no creden
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
Add one secure layer between your agents and this server.
