cloudflare-solver
Server Details
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
- Status
- Healthy
- Uptime
- 100.0% over 42 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 1 tool
With only one tool there is nothing to disambiguate, so ambiguity is trivial. However, the tool's name 'post_get_page_source' confuses its own purpose by mixing POST and GET semantics, making it unclear what the tool actually does without reading the description.
A single tool name cannot establish a consistent pattern across tools, but the name itself is internally inconsistent, combining 'post' and 'get' prefixes which suggest conflicting conventions. The snake_case styling is fine, but the contradictory verb choices lower the score.
A single tool feels thin for a server named 'cloudflare-solver', since solving Cloudflare challenges typically involves more than just fetching page source. However, one tool can be acceptable for a narrowly defined purpose, placing it right at the borderline.
The server only fetches page source, which is a minimal subset of what a Cloudflare-solving tool should do. Missing crucial capabilities like handling cookies, solving interactive challenges, setting headers, or retrying, making the server likely to hit dead ends on real-world tasks.
Available Tools
1 toolpost_get_page_sourceGet page sourceBInspect
Fetches and returns page source of provided url. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the billing cost ('Billing per call: 1 Credits') and the core behavior of fetching and returning page source. It does not mention potential errors, redirects, authentication requirements, or response format, but for a simple read-style tool this is acceptable though not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: one for the tool's function and one for billing. Every word earns its place, with no fluff or redundancy. It is appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one parameter, no output schema, no nested objects—the description is mostly complete. It states what is fetched and returned, and mentions billing. It could be more complete by describing error behavior or response format, but for this low-complexity tool it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'url', with an example but no description, and schema description coverage is 0%. The description only repeats 'provided url' without adding meaningful detail about URL format, encoding, or constraints. Since the description must compensate for low schema coverage and does not, the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetches and returns page source of provided url.' This is a specific verb+resource pairing. However, with no sibling tools listed, it cannot distinguish itself from alternatives, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool when you need the page source for a given URL. It does not provide explicit when-to-use vs. when-not-to-use guidance or mention alternatives, but the intended use case is reasonably clear from the wording.
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.
1 tool update
- First observed
post_get_page_source
Related MCP Connectors
Bypass Cloudflare API: A powerful scraping API designed to bypass Cloudflare protection.
Solve reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and image captchas. Platform-hosted, no creden
ScrapeUnblocker: ScrapeUnblocker allows to bypass anti-bot services and scrape the full page source.
The most accurate web access API. Stop getting blocked.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables scraping and fetching websites with protection handling like Cloudflare and captchas, via an MCP interface.6 npm1Apache 2.0
- AlicenseAqualityCmaintenanceOpen-source browser automation API with anti-detection for AI agents, web scraping, and automation, providing undetectable Chrome via MCP and REST API with Cloudflare bypass.2410MIT

sessemi-mcpofficial
AlicenseAqualityDmaintenanceEnables AI agents to scrape websites protected by Cloudflare, DataDome, and Akamai, bypassing anti-bot measures to retrieve page content.2MIT- AlicenseAqualityAmaintenanceEnables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.2589 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.