de en es ja ko ru zh

solvegate-mcp

Name: solvegate-mcp
Author: SolveGate

Official

by SolveGate

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

solvegate-mcp

一个 MCP 服务器，让代理能够处理 Cloudflare Turnstile：检查页面是否携带 Turnstile，如果有，就清除它。

三个工具。其中一个无需账户。

工具	作用	需要密钥
`inspect_page`	获取一个 URL，并报告页面上是否有 Cloudflare Turnstile、其 sitekey、渲染方式、其 `data-*` 配置，以及页面是整页 WAF 验证还是一个小部件	否
`solve_turnstile`	清除一个 Turnstile 或 Turnstile WAF 验证，并返回一个 token	是
`get_solve`	按 id 获取一个求解结果 —— 免费，且绝不会重新计一遍	是

安装

npx solvegate-mcp

Claude Desktop / 任何 MCP 客户端，在配置中：

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

不设置 SOLVEGATE_API_KEY，inspect_page 依然可用。这是刻意的：在你决定是否要注册之前，你应该先看清这个服务器做了些什么。

在 solvegate.io 获取密钥。免费的 sk_test_ 沙箱密钥不需要银行卡，并会立即返回一个确定的 token —— 正好适合用来进行周边通用连接，而且它永远不会清除某个真实的关卡。

Related MCP server: cloudscraper-mcp

为什么要有 `inspect_page`

使用求解器时最常见突发的错误是：在你应该先看一眼前就贸然调用。绝大多数情况都落在这三种之一：

页面上是 reCAPTCHA 或 hCaptcha，而不是 Turnstile。 它们来自不同厂商的产品。本服务器不解决它们，SolveGate 也不 —— inspect_page 会直接说出这一点，而不是让你从 422 错误里发现。
这是 WAF 挑战，而不是小部件。 一个 Whole-page Cloudflare 插屏没有 data-sitekey，因为该挑战属于某个 zone 规则，而不是属于你嵌入的小部件。页面上没有什么可读的，而且关卡是 waf 而不是 turnstile。
sitekey 是在加载后通过脚本渲染出来的。 那么它根本不在服务器返回的 HTML 里，工具会直接讲明这一点，而不是去猜。

检查是免费的，大概只需要一秒，而且常常直接就是全部答案。

它不会告诉你什么

小部件模式。 Managed、non-interactive 和 invisible 这些模式都存储在属于 sitekey 所有者的 Cloudflare 账户里的小部件上。页面只拿 key 带过去，所以没有任何工具能从源码里读出模式 —— 这个工具不能，任何声称能读的也都不能。

这对解决没有关系：所有三种模式最终都解析成一个相同的请求。一个 sitekey、一个页面 URL、返回一个 token。

唯一的例外是 Cloudflare 官方文档里的五个虚拟 sitekey，其小部件类型由 Cloudflare 自己公布。inspect_page 会报告这些；如果页面上出现了其中一个，就知道你看到的是一个 staging 构建，而不是生产环境。

配置

变量	默认值	作用
`SOLVEGATE_API_KEY`	—	你的密钥。`sk_test_` 用于沙箱，`sk_live_` 用于真实关卡。
`SOLVEGATE_BASE_URL`	`https://api.solvegate.io`	API 基础地址。
`SOLVEGATE_SITE_URL`	`https://solvegate.io`	`inspect_page` 运行的地方。
`SOLVEGATE_TIMEOUT_MS`	`30000`	每个请求的超时。
`SOLVEGATE_MAX_WAIT_MS`	`60000`	`solve_turnstile` 等一个未决求解的最长时间。

密钥从环境中读到，绝不是某个工具参数 —— 工具参数对模型可见，而且会出现在对话记录里。

行为说明

求解在底层是异步的。 solve_turnstile 以 async: true 创建求解并进行轮询，而不是在整个尝试期间保持连接。代理的某次工具调用有一个它自己无法控制的超时，如果采用同步求解，一个卡顿的门会被人看成工具已失效。此外，这里的超时也会给你留下一个 solve id：错误会点名它，而 get_solve 会把它捞回来，而不是丢掉一个已经被计费的求解。

错误是结果，不是异常。 所有失败都会以 isError 结果返回，并附带有 SolveGate 自己的错误 code —— balance_empty、unknown_sitekey、rate_limited、forbidden_target。模型可以针对这些信息行动。而对一个堆栈追踪，模型并不能做什么有用的事。

Token 一次性且短生命期。 expiresAt 是 Unix 秒；超过它，Cloudflare 就不再接受这个 Token，而那个 solve 记录也仅仅是一个记录。记得在真正提交的时候再请求 token。

在信任 token 之前，先检查 mode。 sk_test_ 密钥返回的是 mode: "sandbox"，而沙箱 token 是没法清除一个真实 gate 的。这个字段就是为了让生产配置里的测试 key 能响亮地失败，而不是无声地失败。

可接受的使用方式

只对自己拥有或已被授权测试的属性开展解决。这也是为了那些总是卡在验证上的端到端测试、针对你自己 staging 的 CI，以及针对你自己生产环境的 synthetic monitoring。约束向来以可接受使用条款为准，而且在 denylist 上的目标，无论任何 agent 请求什么，都会返回 403 forbidden_target。

开发

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

测试驱动的是一个真实 stdio 传输，而不是直接调用工具回调。这样是有意的：SDK 在注册时拒绝的 schema，或者一个无关的写入到 stdout —— 后者会把传输弄坏，因为 stdout 就是传输 —— 这样的问题，只有真正让某个东西用它说协议时才能暴露。

链接

SolveGate API 参考
OpenAPI 规范
Turnstile 检测器 —— 这个服务器开放出来的同款检查，可以在浏览器中做
Turnstile 错误索引

MIT.

Need make sure no weird leftover "Gite" from "Development" translation? I wrote "无障碍" erroneously? Need check. I think I accidentally wrote "无障碍" for "Development". Wait in my draft I wrote "## 无障碍" but that's a typo - "Development" should be "开发". Need fix! Let's review.

The final text in my answer draft at the end: "## 无障碍" should be "## 开发". Also "Gite" is not there. I need correct.

Also "这是刻意的" etc.

Need final answer with "## 开发". Also check "whole-page" translation: "一个 Whole-page Cloudflare 插屏" has "Whole-page" English. Better "一个整页 Cloudflare 插屏页".

Let's re-evaluate "console.log"? No.

Need correct "## 开发" not "无障碍".

Also "But an invalid URL?" No.

Let's craft final final.

We must output only translated text. No code fence.

Let's be precise: "the solve id" etc.

Let's adjust some wording:

"That is deliberate" = "这是有意为之" okay.
"Right for wiring this up" = "正适合用来搭建对接" perhaps better.
"never clears a real gate" = "永远不会清除真实关卡". Good.

Let's final now. Ensure no extra commentary.

Final answer.# solvegate-mcp

一个 MCP 服务器，让代理能够处理 Cloudflare Turnstile：检查页面是否携带 Turnstile，如果有就清除它。

三个工具。其中一个不需要账户。

工具	作用	需要密钥
`inspect_page`	获取一个 URL，并报告页面上是否有 Cloudflare Turnstile、其 sitekey、渲染方式、其 `data-*` 配置，以及页面是整页 WAF 验证还是一个小部件	否
`solve_turnstile`	清除一个 Turnstile 或 Turnstile WAF 验证，并返回一个 token	是
`get_solve`	按 id 获取一个求解结果 —— 免费，且永不重复计费	是

安装

npx solvegate-mcp

Claude Desktop / 任何 MCP 客户端，在配置中：

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

不设置 SOLVEGATE_API_KEY，inspect_page 依然可用。这是刻意为之：在你决定是否注册任何东西之前，你应该先看清这个服务器做了些什么。

在 solvegate.io 获取密钥。免费的 sk_test_ 沙箱密钥不需要银行卡，并会立刻返回一个确定性的 token —— 正适合用来搭建对接，而且它永远不会清除真实关卡。

为什么要有 `inspect_page`

使用求解器时最常犯的错，就是在应该先看一眼前就贸然调用。绝大多数情况都落在这三种情形：

页面上是 reCAPTCHA 或 hCaptcha，而不是 Turnstile。 它们来自不同厂商、是不同的产品。这个服务器不解决它们，SolveGate 也不解决 —— inspect_page 会直接说出这一点，而不是让你从 422 错误里去发现。
这是 WAF 验证，而不是一个小部件。 整页 Cloudflare 插屏页没有 data-sitekey，因为这种验证属于某个 zone 规则，而不是属于你所嵌入的小部件。页面上没有任何可读取的信息，门禁类型是 waf 而不是 turnstile。
sitekey 是在加载后由脚本渲染出来的。 那它根本不在已提供的 HTML 里，工具会如实说明，而不是去猜。

检查是免费的，大约只需要一秒，而且很多时候给出的就是完整答案。

它不会告诉你什么

小部件模式。 Managed、non-interactive 和 invisible 都存储在拥有该 sitekey 的 Cloudflare 账户内的小部件上。页面本身只携带 key，所以任何工具都无法从源码中读出模式 —— 包括这个工具，也包括任何声称能做到的东西。

这对求解来说没有区别：所有三种模式最终都对应同一个请求。一个 sitekey、一个页面 URL，返回一个 token。

唯一的例外是 Cloudflare 官方文档里公开的五个虚拟 sitekey，Cloudflare 自己公布了这些小部件的方式。inspect_page 会报告这些 sitekey；如果在某页上发现其中一个，它会告诉你一个有用的信息：你看到的是 staging 构建，而不是生产环境。

配置

变量	默认值	作用
`SOLVEGATE_API_KEY`	—	你的密钥。`sk_test_` 用于沙箱，`sk_live_` 用于真实关卡。
`SOLVEGATE_BASE_URL`	`https://api.solvegate.io`	API 基础地址。
`SOLVEGATE_SITE_URL`	`https://solvegate.io`	`inspect_page` 运行的地方。
`SOLVEGATE_TIMEOUT_MS`	`30000`	每个请求的超时。
`SOLVEGATE_MAX_WAIT_MS`	`60000`	`solve_turnstile` 等待未决求解的时间。

密钥是从环境变量读取的，绝不会是工具参数 —— 工具参数对模型可见，并且会出现在对话记录中。

行为说明

求解在底层是异步的。 solve_turnstile 使用 async: true 创建求解并轮询它，而不是在整个尝试期间保持连接。代理的工具调用有一个它无法控制的超时；同步求解会让一个慢的关卡看起来像死掉的工具。这同时意味着，在这里超时会留给你一个 solve id：错误信息会指明它，get_solve 也会把这个已经计费的求解捞回来，而不是丢掉它。

错误是结果，不是异常。 每一次失败都会作为 isError 结果返回，并携带 SolveGate 自己的 error.code —— balance_empty、unknown_sitekey、rate_limited、forbidden_target。模型可以针对这些信息采取行动。而堆栈追踪对它毫无用处。

TOKEN 是一次性且短期的。 expiresAt 是 Unix 秒。超过这个时间后，Cloudflare 不再接受该 token，而 solve 记录也仅仅是一条记录。请在真正提交之时再请求 token。

在信任 token 之前，先检查 mode。 sk_test_ key 会返回 mode: "sandbox"，而沙箱 token 无法清除真实关卡。这个字段存在的目的，就是让预发布配置里的测试 key 能响亮地失败，而不是无声地失败。

可接受的使用范围

只对你拥有或已获授权测试的资产进行求解。本工具是为了那些一直卡在验证上的端到端测试、针对你自有 staging 环境的 CI，以及针对你自有生产环境的监控而存在的。可接受使用条款是更有约束力的版本；无论任何 agent 请求什么，位于拒绝列表上的目标都会返回 403 forbidden_target。

开发

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

测试驱动的是真实 stdio 传输，而不是直接调用工具回调。这是有意的：一个在注册时被 SDK 拒绝的 schema，或者一次无关的对 stdout 的写入 —— 这会弄坏传输，因为 stdout 就是传输 —— 只有真正用协议跟它对话时才会显现出来。

链接

SolveGate API 参考
OpenAPI 规范
Turnstile 检测器 —— 这个交通暴露的同样检查，放到浏览器里
Turnstile 错误索引

MIT.

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.

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

Output 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.

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

Output 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.

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

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.

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

Deploy Server

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A4.8/5.0

Scored 2026-08-31 10:15 across 3 tools

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

ActivityStale

ResponsivenessNo issues

Resources

Related MCP Connectors

cloudflare-solver B
com.jojapi
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
Web Scraping Browser Automation
11
https://mcp.jojapi.com/cloudflare-solver
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
https://api.mcp.ai/p_captcha
Solvecha A
com.solvecha
Solve reCAPTCHA image grids, text captchas, GeeTest and FunCAPTCHA for AI agents. Free tier.
Browser Automation Web Scraping Penetration Testing
61
https://api.solvecha.com/mcp
Human Handoff relay A
com.botrecipe
Hands CAPTCHAs, 2FA codes and approvals from your agent to your human with one tap.
Agent Orchestration Autonomous Agents Security
51
https://relay.cloudforbots.com/mcp

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 5 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 5 months ago (2026-05-21 00:25 UTC)
1
-
disasm.dev MCP serverofficial
Browser Automation Web Scraping
disasm-dev
A
license
A
quality
D
maintenance
Enables AI assistants to generate DataDome and Incapsula clearance tokens without a headless browser, for development and prototyping.
Updated 4 months ago (2026-06-25 13:11 UTC)
6
MIT
webshot-mcp
Browser Automation Web Scraping
Brandon-35
A
license
Not graded
quality
C
maintenance
Enables agents to take screenshots and extract text from web pages using a persistent Chrome browser via CDP, with built-in SSRF protection.
Updated 2 months ago (2026-08-18 04:18 UTC)
9 npm
MIT

solvegate-mcp

安装

为什么要有 inspect_page

它不会告诉你什么

配置

行为说明

可接受的使用方式

开发

链接

安装

为什么要有 inspect_page

它不会告诉你什么

配置

行为说明

可接受的使用范围

开发

链接

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

disasm.dev MCP serverofficial

webshot-mcp

为什么要有 `inspect_page`

为什么要有 `inspect_page`