What can you do with this server?

This server lets an agent detect and clear Cloudflare Turnstile challenges, with one free inspection tool and two API-key-based solving/retrieval tools. * Inspect any URL for Turnstile for free — inspect_page fetches a page and reports whether Turnstile is present, the sitekey(s), rendering style (implicit/explicit), data-* config, cf-turnstile-response field presence, Cloudflare dummy/test sitekeys, and whether it's a full-page WAF challenge instead of a widget. * Detect other CAPTCHAs by name — it tells you if the page uses reCAPTCHA or hCaptcha rather than Turnstile, so you don't waste a solving attempt. * Solve an embedded Turnstile widget or a full-page WAF challenge — solve_turnstile takes the gate type, sitekey, and page URL, then returns a single-use, short-lived token to submit as cf-turnstile-response. * Solve through an optional proxy — solve_turnstile accepts an egress proxy URL. * Pass an optional Turnstile action label — if the widget sets one, solve_turnstile can include it. * Retrieve a previously created solve by id — get_solve is free, never re-bills, and lets you recover a solve that finished after solve_turnstile timed out. * Work without an API key for inspection — inspect_page needs no key; only solving does. * Use sandbox or live mode — an sk_test_ key returns mode: "sandbox" and deterministic tokens; sk_live_ clears real gates. * Act on structured errors instead of exceptions — failures return errorCode values like balance_empty, unknown_sitekey, rate_limited, and forbidden_target, so an agent can respond intelligently.

Which integrations are available for this server?

Provides tools for detecting Cloudflare Turnstile widgets and WAF challenges on web pages, inspecting their configuration, and solving Turnstile challenges to obtain single-use tokens for authorized testing.

How do I use solvegate-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@solvegate-mcp Check https://example.com for a Cloudflare Turnstile challenge" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

solvegate-mcp

Official

by SolveGate

Overview Schema Related Servers Score Discussions

JavaScript

Remote

solvegate-mcp

npm Glama score

An MCP server that lets an agent deal with Cloudflare Turnstile: check whether a page has one, and clear it when it does.

Three tools. One of them needs no account.

Tool	What it does	Needs a key
`inspect_page`	Fetch a URL and report whether Cloudflare Turnstile is on it, its sitekey, how it renders, its `data-*` configuration, and whether the page is a full-page WAF challenge instead of a widget	No
`solve_turnstile`	Clear a Turnstile or Turnstile WAF challenge and return a token	Yes
`get_solve`	Fetch a solve by id — free, never re-bills	Yes

Install

npx solvegate-mcp

Claude Desktop / any MCP client, in your config:

{
  "mcpServers": {
    "solvegate": {
      "command": "npx",
      "args": ["-y", "solvegate-mcp"],
      "env": { "SOLVEGATE_API_KEY": "sk_test_…" }
    }
  }
}

Leave SOLVEGATE_API_KEY out and inspect_page still works. That is deliberate: you should be able to see what the server does before deciding whether to sign up for anything.

Get a key at solvegate.io. A free sk_test_ sandbox key needs no card and returns a deterministic token instantly — right for wiring this up, and it never clears a real gate.

Related MCP server: cloudscraper-mcp

Why `inspect_page` exists

The commonest wrong turn with a solver is calling it when you should have looked first. Three cases account for most of it:

The page carries reCAPTCHA or hCaptcha, not Turnstile. Those are different products from different vendors. This server does not solve them, and neither does SolveGate — inspect_page says so by name instead of letting you find out from a 422.
It is a WAF challenge, not a widget. A full-page Cloudflare interstitial has no data-sitekey, because the challenge belongs to a zone rule rather than to a widget you embed. There is nothing to read off the page, and the gate is waf rather than turnstile.
The sitekey is rendered from script after load. Then it is not in the served HTML at all, and the tool says that rather than guessing.

Inspecting is free, takes about a second, and is quite often the whole answer.

What it will not tell you

The widget mode. Managed, non-interactive and invisible are stored on the widget inside the Cloudflare account that owns the sitekey. The page carries only the key, so no tool can read the mode off the source — including this one, and including anything that claims otherwise.

It does not matter for solving: all three modes resolve to the same request. A sitekey, a page URL, and a token back.

The one exception is Cloudflare's five documented dummy sitekeys, whose widget type Cloudflare publishes itself. inspect_page reports those, and finding one on a page tells you something useful — you are looking at a staging build rather than production.

Configuration

Variable	Default	What it does
`SOLVEGATE_API_KEY`	—	Your key. `sk_test_` for the sandbox, `sk_live_` for real gates.
`SOLVEGATE_BASE_URL`	`https://api.solvegate.io`	API base.
`SOLVEGATE_SITE_URL`	`https://solvegate.io`	Where `inspect_page` runs.
`SOLVEGATE_TIMEOUT_MS`	`30000`	Per-request timeout.
`SOLVEGATE_MAX_WAIT_MS`	`60000`	How long `solve_turnstile` waits for a pending solve.

The key is read from the environment and is never a tool argument — a tool argument is model-visible and ends up in transcripts.

Notes on behaviour

Solving is async underneath. solve_turnstile creates the solve with async: true and polls it, rather than holding a connection open for the whole attempt. An agent's tool call has a timeout it does not control, and a synchronous solve makes a slow gate look like a dead tool. It also means a timeout here leaves you a solve id: the error names it, and get_solve will pick it up rather than losing a solve that was already billed.

Errors are results, not exceptions. Every failure comes back as an isError result carrying SolveGate's own error.code — balance_empty, unknown_sitekey, rate_limited, forbidden_target. A model can act on those. It can do nothing useful with a stack trace.

Tokens are single-use and short-lived. expiresAt is Unix seconds; past it, Cloudflare stops accepting the token and the solve record is just a record. Request a token at the moment you submit it.

Check mode before trusting a token. An sk_test_ key returns mode: "sandbox", and a sandbox token will not clear a real gate. The field exists so a test key in a production config fails loudly rather than quietly.

Acceptable use

Solve only against properties you own or are authorised to test. This exists for end-to-end tests that keep failing on a challenge, CI against your own staging, and synthetic monitoring of your own production. The acceptable use policy is the binding version, and targets on the denylist return 403 forbidden_target regardless of what any agent asks for.

Development

npm install
npm run build
npm test          # spawns the built server and speaks MCP to it
OFFLINE=1 npm test  # skips the two tests that reach the network

The tests drive a real stdio transport rather than calling the tool callbacks directly. That is on purpose: a schema the SDK rejects at registration, or a stray write to stdout — which corrupts the transport, since stdout is the transport — only shows up when something actually speaks the protocol to it.

Available Tools

3 tools

get_solveRetrieve a solve by idA

Read-only

Fetch a solve created earlier. Free — reading never re-bills. Use this when solve_turnstile timed out while still pending: the solve may have finished after the tool gave up, and the id is in that error message. A 404 means no such solve for this API key's workspace.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The solve id, e.g. slv_8Kd2aF9

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`mode`	Yes
`token`	Yes
`billed`	Yes
`status`	Yes
`summary`	Yes
`errorCode`	Yes
`expiresAt`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark it read-only and open-world, but the description adds valuable behavioral context: it is free and never re-bills, and a 404 is scoped to the current API key's workspace. This goes beyond structured metadata without contradicting it.

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?

Three concise sentences with no filler. The main purpose is front-loaded, followed by a concrete use case and an error interpretation; every sentence earns its place.

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?

For a single-parameter retrieval tool with an output schema and safety annotations, the description fully covers when to call it, what the id means, cost implications, and error semantics. Nothing essential is missing for correct invocation.

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 only parameter, id, is already clearly described with a format example. The description adds the useful hint that the id may come from a timeout error, but does not need to elaborate further since the schema carries the parameter meaning.

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 ('Fetch a solve... by id') and distinguishes itself from siblings by describing exactly when it is the right tool. The mention of solve_turnstile and 404 behavior makes its role unambiguous.

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?

Explicitly tells the agent when to use this tool: after solve_turnstile times out while the solve is pending, with the id coming from that error message. It also interprets a 404 response, giving clear operational context beyond the schema.

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

inspect_pageInspect a page for Cloudflare TurnstileA

Read-only

Fetch a URL and report what its HTML says about Cloudflare Turnstile: whether a widget is present, its sitekey, whether it renders implicitly or via turnstile.render(), the widget's data-* configuration, whether the sitekey is one of Cloudflare's documented test keys, and whether the page is a full-page WAF challenge rather than a widget. Free, no API key required. Use this before solving when the sitekey is unknown. It CANNOT determine the widget's mode (managed / non-interactive / invisible) — that is stored in the Cloudflare account that owns the sitekey and is not in the page at all.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The page URL to inspect, e.g. https://example.com/login

Output Schema

ParametersJSON Schema

Name	Required	Description
`present`	Yes	Turnstile was found on the page
`summary`	Yes	One line a human can read
`finalUrl`	Yes
`sitekeys`	Yes	Sitekeys found, in document order
`rendering`	Yes
`httpStatus`	Yes
`otherCaptcha`	Yes	Other CAPTCHA products on the page — we do not solve these
`wafChallenge`	Yes	The response is a Cloudflare WAF challenge interstitial
`responseFieldPresent`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint, it adds meaningful behavioral specifics: it performs an HTML inspection rather than solving a challenge, requires no API key, is free, and has a specific hard limitation around widget mode. These details substantially describe side effects and boundaries beyond annotations.

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?

Although the description is long, each clause delivers a distinct, useful fact: what is fetched, what is reported, cost/auth requirements, usage timing, and a critical limitation. The most important action and resource are front-loaded, and no sentence is slack.

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?

Given a single required parameter, an output schema, and annotations, the description covers everything an agent needs: when to call it, what it returns, its constraints, and what it cannot infer. The mitigation of return format details is appropriate.

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?

The schema fully describes the single 'url' parameter with an example, so parameter documentation coverage is 100%. The description does not add much beyond the schema, but the schema already carries the necessary semantic weight. This aligns with the baseline for high schema coverage.

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 ('Fetch') and a concrete result ('report what its HTML says about Cloudflare Turnstile') and enumerates exact outputs: widget presence, sitekey, render method, data-* configuration, test keys, and full-page WAF challenge. This clearly separates it from sibling solving/result-retrieval tools.

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?

It explicitly says 'Use this before solving when the sitekey is unknown,' giving a direct invocation condition. It also provides an exclusion: it cannot determine the widget's mode because that data is not in the page, so agents know when this tool is not sufficient.

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

solve_turnstileSolve a Cloudflare Turnstile or WAF challengeA

Clear a Cloudflare challenge and return a token. gate is "turnstile" for an embedded widget (there is a data-sitekey in the page) or "waf" for a full-page Cloudflare interstitial. sitekey and url are both required; the url must be the page the challenge actually renders on, because a sitekey is bound to its configured hostnames. Tokens are single-use and expire in minutes — request one at the moment you submit. Failed solves are never billed. Requires SOLVEGATE_API_KEY.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The page URL the challenge renders on
`gate`	Yes	Which challenge type to clear
`proxy`	No	Optional egress proxy URL to solve through
`action`	No	Optional Turnstile action label, if the widget sets one
`sitekey`	Yes	The target's sitekey, e.g. 0x4AAAAAAA…

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`mode`	Yes	sandbox tokens NEVER clear a real gate
`token`	Yes	Submit this as the cf-turnstile-response field
`billed`	Yes
`status`	Yes
`solveMs`	Yes
`summary`	Yes
`errorCode`	Yes
`expiresAt`	Yes	Unix seconds after which the token is worthless

TDQS

A4.7/5.0

Behavior5/5

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

Annotations indicate non-read-only and non-idempotent behavior, and the description adds meaningful operational context: tokens are single-use and expire in minutes, failed solves are never billed, SOLVEGATE_API_KEY is required, and sitekeys are bound to hostnames. This goes well beyond the annotations and clarifies important 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.

Conciseness5/5

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

Four sentences with no filler: purpose is front-loaded, then parameter guidance, then token lifecycle and error/cost behavior. Every sentence adds useful information and the structure is easy to parse.

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 and useful annotations present, the description supplies the critical missing context: token expiry timing, no-billing on failed solves, API key requirement, and hostname binding. Nothing an agent needs to invoke this tool correctly appears to be missing.

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. The description adds extra semantic value by explaining the `gate` enum values, reinforcing that `sitekey` and `url` are both required, and explaining why `url` must be the actual rendering page. Some parameters like `proxy` and `action` receive no additional description, but the schema already documents them adequately.

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 opens with a specific verb-resource pair ('Clear a Cloudflare challenge and return a token') and then defines the two `gate` modes, clearly distinguishing an embedded widget from a full-page interstitial. This makes the tool's purpose immediately understandable and separates it from generic 'solve' tools.

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 actionable selection guidance: it explains when to use 'turnstile' versus 'waf', and instructs the agent to request tokens at submission time due to expiry. It does not explicitly name sibling tools as alternatives or state when not to use this tool, so it stops short of full when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.1.2Aug 29, 2026

Changedget_solve6 fields changed

removedOutput schema / properties / errorCode / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / errorCode / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / expiresAt / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / expiresAt / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / token / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / token / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changedsolve_turnstile8 fields changed

removedOutput schema / properties / errorCode / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / errorCode / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / expiresAt / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / expiresAt / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / solveMs / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / solveMs / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / token / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / token / type
```
Added value: +[
+  "string",
+  "null"
+]
```

3 tool updatesv0.1.1Aug 25, 2026
- First observedget_solve
- First observedinspect_page
- First observedsolve_turnstile

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.8/5.0

Disambiguation5/5

Each tool serves a distinct purpose: inspect_page reads page HTML, solve_turnstile solves the challenge, and get_solve retrieves a previous result. There is no functional overlap between them, and their descriptions clearly differentiate when to use each.

Naming Consistency5/5

All tool names follow the verb_noun pattern in snake_case: inspect_page, solve_turnstile, get_solve. The pattern is consistent and predictable, making it easy to infer tool behavior from the name.

Tool Count5/5

With only 3 tools, the server remains tightly focused on the Turnstile solving workflow. Each tool is essential and there is no bloat or redundancy, so the count is perfectly matched to the scope.

Completeness5/5

The tool surface covers the full lifecycle: pre-flight inspection (inspect_page), actual solving (solve_turnstile), and post-hoc retrieval (get_solve). This is a complete workflow with no obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

cloudflare-solver B
com.jojapi
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
Web Scraping Browser Automation
11
Captcha Solver B
io.github.mcp-dir
Solve reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and image captchas. Platform-hosted, no creden
Browser Automation Web Scraping
121
scrapeunblocker-dfsswg C
com.jojapi
ScrapeUnblocker: ScrapeUnblocker allows to bypass anti-bot services and scrape the full page source.
Web Scraping Browser Automation
11
bypass-cloudflare-api A
com.jojapi
Bypass Cloudflare API: A powerful scraping API designed to bypass Cloudflare protection.
Web Scraping Browser Automation
11

Related MCP Servers

sessemi-mcpofficial
Web Scraping Browser Automation
sessemi
A
license
A
quality
D
maintenance
Enables AI agents to scrape websites protected by Cloudflare, DataDome, and Akamai, bypassing anti-bot measures to retrieve page content.
Updated 3 months ago (2026-05-22 09:45 UTC)
2
MIT
cloudscraper-mcp
Browser Automation Web Scraping
LLMTooling
F
license
Not graded
quality
D
maintenance
Enables AI agents to bypass Cloudflare protection and scrape web content, returning clean Markdown with smart chunking and file export.
Updated 4 months ago (2026-05-21 00:25 UTC)
1
-
Real Browser MCP
Browser Automation Web Scraping
qxZap
A
license
Not graded
quality
D
maintenance
Provides a real browser that bypasses bot detection (Cloudflare, Turnstile) for AI agents, enabling navigation, clicking, typing, screenshots, and data collection through MCP tools.
Updated 7 months ago (2026-02-16 09:18 UTC)
104
MIT
disasm.dev MCP serverofficial
Browser Automation Web Scraping
disasm-dev
A
license
A
quality
C
maintenance
Enables AI assistants to generate DataDome and Incapsula clearance tokens without a headless browser, for development and prototyping.
Updated 2 months ago (2026-06-25 13:11 UTC)
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SolveGate/solvegate-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

solvegate-mcp

Install

Why inspect_page exists

What it will not tell you

Configuration

Notes on behaviour

Acceptable use

Development

Links

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

sessemi-mcpofficial

cloudscraper-mcp

Real Browser MCP

disasm.dev MCP serverofficial

Latest Blog Posts

MCP directory API

Why `inspect_page` exists