solvegate-mcp

Official

by SolveGate

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Inspect a page for Cloudflare Turnstile

inspect_page

Read-only

Fetch a URL to detect Cloudflare Turnstile details: widget presence, sitekey, render method, data-* config, test keys, and WAF challenge type. Use when the sitekey is unknown.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "inspect_page"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Aug 25, 2026

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.

Deploy Server