solvegate-mcp is an MCP server used to enable AI agents to handle Cloudflare Turnstile. It provides three tools, at least one of which can be used without an account.
Purpose It allows agents to first determine whether a page actually uses Turnstile, and then decide whether the challenge needs to be cleared. A common mistake is to get a solver and call it directly, whereas the existence of inspect_page is precisely for checking first:
- The page may use reCAPTCHA or hCaptcha rather than Turnstile. These are different products from different vendors, and neither this server nor SolveGate solves them. inspect_page will directly report the name instead of making you wait for a 422 error.
- The page may be a WAF challenge rather than an embedded widget. A full-page Cloudflare interstitial has no data-sitekey, because the challenge comes from zone rules rather than an embedded widget, and the gate type is waf rather than turnstile.
- The sitekey may be rendered by a script after loading, in which case it is not in the HTML returned by the server. The tool will state this truthfully rather than guess. Checking is free and takes about one second, and in many cases this is the entire answer.
Main capabilities
- inspect_page: checks whether a page contains Turnstile and can also be used without an API key; it can identify cases such as reCAPTCHA, hCaptcha, WAF challenges, and dynamically rendered sitekeys.
- solve_turnstile: clears a Turnstile challenge. It uses an asynchronous approach under the hood, setting async: true on creation and polling rather than keeping the connection open the whole time.
- get_solve: used to continue retrieving the solve result after a timeout. Regarding widget modes (managed, non-interactive, invisible), this information is stored in the Cloudflare account that owns the sitekey, and the page carries only the key, so no tool can read the mode from the source code, including this tool. This has no effect on solving; all three modes ultimately come down to the same request: sitekey, page URL, and returning a token. The only exception is the five dummy sitekeys officially published by Cloudflare, whose widget types are determined by Cloudflare publishes them itself, and inspect_page will report them. If you find them on a page, it means you are facing a pre-release build rather than a production environment.
How to use Connect it in the configuration of Claude Desktop or any MCP client. The API key is read from an environment variable, never from a tool parameter—tool parameters are visible to the model and enter the conversation record. You can omit SOLVEGATE_API_KEY in the configuration, and inspect_page will still work; this is intentional, so you can first see clearly what the server does before deciding whether to register. Get a key at solvegate.io. The free sk_test_ sandbox key does not require a credit card, returns a deterministic token immediately, is suitable for integration testing, and it will never clear a real gate.
Behavior details
- Solving is asynchronous under the hood: solve_turnstile creates a solve with async: true and polls, rather than keeping the connection open the whole time. An agent's tool calls have timeouts it cannot control, and synchronous solving would make a slow gate look like the tool is dead. This also means a timeout leaves behind a solve id: the error will name it, get_solve can continue retrieving it, and an already-billed solve will not be lost.
- Errors are results rather than exceptions: every failure is returned as an isError result with SolveGate's own error.code, such as balance_empty, unknown_sitekey, rate_limited, forbidden_target. The model can act on this, whereas a stack trace is useless to the model.
- Tokens are one-time and short-lived: expiresAt is Unix seconds; after expiration Cloudflare no longer accepts the token, and the solve record is just a record. Request the token at the moment you submit.
- Check the mode before trusting the token: an sk_test_ key returns mode: "sandbox", and sandbox tokens do not clear real gates. This field exists so that a test key in a production configuration fails loudly rather than quietly passing.
- Only solve targets you own or are authorized to test: suitable for end-to-end tests that keep failing due to challenges, CI against your own pre-release environment, and synthetic monitoring of your own production environment. The acceptable use policy is the binding version, and targets on the deny list are allreturns 403 forbidden_target, no matter what the agent requests.
- Tests drive the real stdio transport, rather than directly calling tool callbacks. This is intentional: schemas the SDK rejects at registration time, or stray writes to stdout (stdout is the transport channel, and writes will break the transport), are only exposed when something actually speaks the protocol to it.
Applicable scenarios End-to-end tests that keep failing due to challenges, CI against your own pre-release environment, synthetic monitoring of your own production environment.
Limitations This server does not solve reCAPTCHA or hCaptcha. It cannot read widget modes. Tokens are one-time and short-lived. Use is limited to targets you own or are authorized to test, and deny-listed targets return 403.
