capskip-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Solve CaptchaFox

capskip_solve_captchafox

Solve CaptchaFox challenges and return a token for the cf-captcha-response field. Provide the exact page URL to avoid domain mismatches.

Instructions

Solve a CaptchaFox challenge. CaptchaFox scores the browser itself rather than asking the visitor to read anything, so most solves draw no puzzle at all. Returns a token to put in the form field named 'cf-captcha-response', verbatim — it is verified server side against the session that produced it, so any edit invalidates it. IMPORTANT: the url must be the page the widget actually runs on. CaptchaFox checks it against the domains the key is registered for and refuses a mismatch permanently, not intermittently — so a sitekey that fails immediately and consistently usually means the wrong page URL, not a bad key. The result also carries the User-Agent the token was minted under; submit under that one, not your own.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Full URL of the page the captcha appears on, including scheme.
`proxy`	No	Solve from this network. CaptchaFox scores the address a widget runs on as well as the browser, so repeated solves from one address drift toward interactive challenges and then refusals.
`sitekey`	Yes	The public key the widget renders with, conventionally prefixed 'sk_'. Read it from data-sitekey on the widget container, from the captchafox.render(...) call, or — if the page builds the widget at runtime — from the path segment after /captcha/ in the request to api.captchafox.com.
`timeout`	No	Seconds to wait before giving up. Maximum 600.
`api_server`	No	The widget entry point the target page loads. Defaults to 'https://cdn.captchafox.com/'. Send the MAM package path instead when the page loads that build — it returns a MAM_ prefixed token, and the two are not interchangeable.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Sep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses key behaviors beyond annotations: token is verified server-side and any edit invalidates it, URL mismatches cause permanent refusals (not intermittent), and the result carries a User-Agent that must be used for submission. These are critical operational traits not present in the schema or annotations, enriching the agent's understanding of side effects and constraints.

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

Conciseness4/5

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

The description is a single paragraph but well-structured with an 'IMPORTANT' callout for the URL requirement. Every sentence contributes actionable information—challenge behavior, token handling, and troubleshooting. It is slightly long but not padded; the density justifies the length.

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 captcha-solving tool with two required parameters, an output schema, and a nested proxy object, the description covers the essential operational details: token usage, server-side verification, URL accuracy, and User-Agent alignment. It does not detail proxy behavior beyond the schema, but given that the schema already documents proxy semantics, the description is complete enough for an agent to solve correctly.

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% with rich per-parameter descriptions, so the baseline is 3. The description adds extra context for the 'url' parameter (must be the actual page, mismatch is permanent) and introduces the User-Agent alignment that affects how 'proxy' and 'url' are used. This goes beyond schema, providing meaningful semantic guidance.

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 states a specific verb and resource: 'Solve a CaptchaFox challenge.' It further specifies the nature of the challenge (browser scoring, often no puzzle) and the output format (token for 'cf-captcha-response'). This clearly distinguishes it from other captcha-solving siblings by naming the provider and the token's placement.

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 description gives explicit operational guidance: the URL must be the exact widget page, the User-Agent must match the one used at solve time, and errors are often due to URL mismatch rather than key failure. It does not explicitly compare with alternatives (e.g., 'use ReCaptcha tool for other providers'), but the tool name and context make the target provider obvious, so the guidance is sufficient for selection.

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

Deploy Server