capskip-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Solve hCaptcha

capskip_solve_hcaptcha

Solves hCaptcha checkbox, invisible, and Enterprise widgets from a sitekey and page URL, returning a short-lived token to place in the form and submit.

Instructions

Solve an hCaptcha widget — or a js.hcaptcha.com script on the page — and get its token. Checkbox, invisible and hCaptcha Enterprise widgets all use this tool. Requires sitekey and url. Put the returned token in the form's hidden h-captcha-response field and in g-recaptcha-response if the form has one, or call the widget's data-callback with it, then submit with the returned User-Agent. Tokens are single use and expire about two minutes after they are issued, so submit promptly. Do not use capskip_solve_recaptcha for hCaptcha: both carry a data-sitekey, but they are different widgets.

Input Schema

Name	Required	Description
`url`	Yes	Full URL of the page the captcha appears on, including scheme.
`data`	No	hCaptcha Enterprise only: the rqdata value the page passes to the widget through hcaptcha.setData() before it runs. It is issued for one challenge and expires quickly, so read a fresh one for every solve. Leave it out when the page sets none.
`proxy`	No	Solve from this network. hCaptcha scores the address a token comes from as well as the browser, so many solves from one address are what its rate limits catch. Pass the proxy the form submission will go through.
`sitekey`	Yes	The sitekey of the hCaptcha widget, a UUID such as 'a5f74b19-9e45-40e0-b45d-47ff91b7a6c2'. Read it from data-sitekey on the widget container (<div class="h-captcha" data-sitekey="…">), from the sitekey option of hcaptcha.render(), or from the sitekey= parameter in the address of the hCaptcha iframe.
`timeout`	No	Seconds to wait before giving up. Maximum 600.
`invisible`	No	true for an invisible widget, one rendered with data-size="invisible".
`userAgent`	No	The User-Agent the form will be submitted with. CapSkip uses it only when it matches the browser it solves with, and always reports the one the token was actually earned with. Usually leave it out.

Output Schema

Name	Required	Description	Default
`code`	Yes
`token`	Yes
`respKey`	Yes
`captchaId`	Yes
`userAgent`	No
`solveSeconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.0Nov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare it is a non-destructive open-world write; the description goes well beyond that with the post-solve contract. It discloses that tokens are single-use, expire roughly two minutes after issue, must be injected into the hidden h-captcha-response field (and g-recaptcha-response where present) or delivered via data-callback, and that submission must use the returned User-Agent.

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?

Front-loaded with the identification criteria, then the solve-and-submit workflow, then the sibling exclusion. Every sentence carries operational content; nothing is repeated from the schema.

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?

With an output schema present, the description need not describe return values, and it correctly focuses on the tricky part: what to do with the token once returned. For a seven-parameter open-world tool with nested proxy input, this covers the decision points an agent would otherwise get wrong.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds selection meaning the schema does not: invisible and Enterprise widgets use this same tool, and sitekey/url are the mandatory pair. It stops short of explaining proxy rate-limit behavior or the rqdata freshness rule, which only the schema covers.

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 an hCaptcha widget") and immediately names the identifying artifacts an agent will see (the h-captcha div or the js.hcaptcha.com script). It explicitly distinguishes itself from the nearest sibling, capskip_solve_recaptcha, on the shared data-sitekey ambiguity.

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

Usage Guidelines5/5

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

Covers which widget variants route here (checkbox, invisible, Enterprise), which are required inputs (sitekey and url), and gives an explicit negative rule: do not use capskip_solve_recaptcha because both carry data-sitekey but are different widgets. It also advises leaving the userAgent and data params out in the common case.

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

Deploy Server