A
licenseA
qualityB
maintenanceAn MCP server that enables AI assistants to fetch web content in multiple formats (HTML, JSON, text, Markdown) with intelligent content extraction, chunk management, and browser automation support.
5
78 npm
15
MIT
clawifi-mcp
by ReARCLabs
This MCP server lets you search, fetch/read web content, extract data, map/crawl sites, manage async jobs, and inspect Clawifi account usage and monitors.
Fetch a URL and return extracted content.
Scrape a URL with source-aware routing and structured content.
Run free-tier web searches.
Extract structured data from a URL.
Map a site’s discoverable URLs from a seed URL.
Start asynchronous crawls and poll them with
get_crawl.Create and poll asynchronous jobs for billable operations.
Get account profile and plan details.
Get credit usage and remaining balance.
List past requests for the authenticated account.
List configured Evidence Monitor checks.
Handles Cloudflare challenge pages and browser fingerprinting to enable web scraping and fetching through Cloudflare-protected sites.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@clawifi-mcpfetch the content of https://example.com"
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.
clawifi
Official Python SDK, CLI, and MCP server for Clawifi, web search and page reading for AI agents: search many engines as one, read pages and PDFs, map and crawl sites, and get back only the passages that answer the question, each with its source. One typed API and MCP surface for all of it.
This package is a thin client over the hosted Clawifi API (hosted API version 1.7.2 at time of release); the Clawifi server is not included. Docs, pricing and status: clawifi.dev/docs · clawifi.dev/pricing · clawifi.dev/status · clawifi.dev/security.
One-click install (hosted server, no key needed to try)
Both add the hosted remote server https://api.clawifi.dev/mcp. No key needed to try: 4 tools, 50 calls a day per address. Add your API key for the full toolset (get a free key).
Related MCP server: Apeiron
Install
pip install clawifiGet an API key
clawifi signup --email you@example.com --password "a strong password"This creates an account, grants 1,000 free credits, and prints an API key. Export it:
export CLAWIFI_API_KEY="clawifi_live_..."Quicktest
clawifi quicktest --url https://example.comSet up your MCP client
clawifi initfinds the MCP clients installed on this machine (Claude Code, Codex, Cursor, Claude Desktop, VS Code) and prints, for each one, the install line for the local server (clawifi-mcp, stdio) and for the remote server, followed by a first call to try. It only prints; it never shows your key, only $CLAWIFI_API_KEY or a masked clawifi_live_****. clawifi init --all shows every client, found or not.
To have it edit a config file for you:
clawifi init --write cursor # ~/.cursor/mcp.json, stdio entry
clawifi init --write cursor --remote # ~/.cursor/mcp.json, remote entry
clawifi init --write claude-desktop # claude_desktop_config.json, stdio entry--write asks before it changes anything and copies the existing file to <file>.bak-<timestamp> first. Claude Code, Codex and VS Code have their own install commands, which init prints.
For Claude Code, for example:
# local (stdio)
claude mcp add --env CLAWIFI_API_KEY=$CLAWIFI_API_KEY --transport stdio clawifi -- clawifi-mcp
# remote
claude mcp add --transport http clawifi https://api.clawifi.dev/mcp --header "Authorization: Bearer $CLAWIFI_API_KEY"Use as an MCP server
The local MCP server runs as:
clawifi-mcpreading CLAWIFI_API_KEY from the environment. clawifi mcp config prints a minimal config for it. Every tool carries a title and the MCP hints readOnlyHint, destructiveHint, idempotentHint and openWorldHint; none is destructive.
The billable tools (fetch, scrape, extract, map_site, crawl, search_free) take their common options as parameters and any other API field in options, which is merged into the request body. They refuse dry_run: use the estimate tool to price a call. Arguments a tool does not declare are refused rather than ignored.
Remote MCP
Clawifi also runs a hosted MCP server, so nothing needs installing:
URL:
https://api.clawifi.dev/mcp(streamable HTTP)Auth:
Authorization: Bearer <your key>, or theX-Clawifi-Api-Key: <your key>header
The old host api.clawifi.qzz.io (API and /mcp) keeps working, so CLAWIFI_API_BASE=https://api.clawifi.qzz.io and existing remote configs need no change.
Without a key the remote server offers a keyless tier of four tools, search_free, fetch_url, scrape_url and map_site, at 12 calls a minute and 50 a day per address. With a key you get the full tool list.
Credits
Calls are charged per operation (a plain fetch is 1 credit, a browser render 3, a crawl 1 per page, and so on). See clawifi.dev/pricing, or print the current table, which needs no key:
clawifi creditsThe credits MCP tool and client.credits() show your own usage and balance instead.
Use as a Python SDK
from clawifi import Clawifi
client = Clawifi() # reads CLAWIFI_API_KEY from the environment
page = client.fetch("https://example.com")
print(page["success"])An async client is also available as clawifi.AsyncClawifi.
search_content searches and reads the top results; it is compact by default and full=True returns the full output:
results = client.search_content("agent memory benchmarks", full=True)Responses are returned as the API sends them, so fields such as published_at, modified_at and fetched_at come through untouched.
Estimates (hosted API 1.7.0 and later)
quote = client.estimate("fetch", url="https://example.com")
# {"dry_run": true, "route": "POST /fetch", "estimate": {"minimum": ..., "maximum": ..., "raises": [...]},
# "balance": ..., "would_402": ..., "would_429": ..., "binding_limit": ..., "charged": 0}
client.crawl("https://example.com", max_pages=50, dry_run=True)estimate() and dry_run=True work for fetch, scrape, extract, map, crawl, search_free and search_content. Before the first dry run the client checks the API version at /product/manifest; an API older than 1.7.0 would ignore dry_run and run (and bill) the call, so the client raises ClawifiDryRunUnsupportedError and sends nothing. Pre-releases such as 1.7.0rc1 count as older than 1.7.0.
dry_run is sent only when it is True, and only as the JSON boolean true: a normal call, or dry_run=False, has no dry_run key in its body, and a value that is not a bool raises TypeError before anything is sent. The API answers any dry_run key (even false) on a route that cannot dry-run with a 422, so schema_assist drops dry_run=False and refuses dry_run=True.
The estimate MCP tool does the same from an agent: estimate(operation="fetch", args={"url": "https://example.com"}).
Rate limits
A 429 raises ClawifiAPIError with retry_after (seconds, from the Retry-After header) and limit_scope (which limit was hit, from details.limit_scope). Retryable calls wait out a Retry-After of up to 10 seconds before retrying; a longer one is raised straight away.
MCP tools
Tool | What it does |
| Fetch a single URL and return its extracted content. With |
| Scrape a URL with source-aware routing and return structured content. With |
| Run a free-tier web search and return results. |
| Extract structured data from a URL. |
| Map a site's discoverable URLs starting from a seed URL. |
| Start an asynchronous crawl from a seed URL; returns a |
| Price a |
| Get the current status and results of a crawl. |
| Create an asynchronous job for a billable operation; returns a |
| Get the current status and results of a job. |
| Get the authenticated account's profile and plan. |
| Get the authenticated account's credit usage and remaining balance. |
| List past requests for the authenticated account. |
| List configured Evidence Monitor checks for the authenticated account. |
Documentation
See clawifi.dev/docs for the full API reference, MCP tool list, and CLI command reference.
License
MIT
Available Tools
13 toolsaccountAInspect
Get the authenticated account's profile and plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions 'authenticated account' implying authentication, but does not disclose rate limits, data sensitivity, or any other side effects. It is minimal.
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?
The description is a single, clear sentence with no extraneous information. Extremely concise and well-structured.
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 the tool's simplicity (0 parameters, read-only, output schema exists), the description adequately covers what the tool does and what it returns ('profile and plan'). No additional info required.
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?
The tool has 0 parameters, so schema coverage is vacuously 100%. The description adds no parameter info because none exists, which is appropriate. Baseline for 0 params is 4.
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 uses a specific verb 'Get' and states the resource 'authenticated account's profile and plan', clearly distinguishing itself from sibling tools like 'credits'. It fully defines the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. For a simple 0-parameter tool this is acceptable but still a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crawlCInspect
Start an asynchronous crawl from a seed URL. Returns a crawl_id to poll.
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes | ||
| seed_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must disclose behaviors. It mentions async operation and polling ID but omits details on crawl duration, error handling, rate limits, or URL restrictions. Minimal transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise but overly brief for a tool with two parameters. Could add critical details without becoming verbose, so it's adequate but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the async complexity and lack of annotations, the description leaves significant gaps: no explanation of kwargs, polling mechanism, or how to use the crawl_id with siblings. Incomplete for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description adds no explanation for either parameter. 'kwargs' is entirely opaque. Agent has no semantic help beyond the schema types.
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?
Description clearly states verb 'start', resource 'asynchronous crawl', and indicates the async nature plus the return of a crawl_id for polling. This distinguishes it from siblings like 'fetch' or 'scrape' which are typically synchronous single-page tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives. Does not mention prerequisites, exclusions, or when to prefer siblings like 'map_site' or 'extract'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_jobCInspect
Create an asynchronous job for a billable operation. Returns a job_id to poll.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| operation | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the operation is asynchronous, billable, and returns a job_id for polling. However, it does not mention side effects, idempotency, error behavior, or any destructive potential, leaving gaps.
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?
Two sentences, no redundant information. Every word adds value: 'Create', 'asynchronous', 'billable', 'returns job_id to poll'. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (presumably describing the return), the description is too minimal for a complex async operation. It lacks context on operation types, payload structure, polling semantics, and credit consumption details. The 0% schema coverage exacerbates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It completely omits any details about the required parameters 'operation' and 'payload', such as expected format or allowed values. This makes it very difficult for an agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates an asynchronous job for a billable operation and returns a job_id. The verb 'create' and resource 'asynchronous job' are specific, and the tool is easily distinguished from sibling tools (e.g., fetch, scrape, get_job) which are data retrieval or monitoring tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'billable operation' but does not clarify prerequisites, scenarios, or when not to use it. Siblings like get_job are related but no comparison provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
creditsAInspect
Get the authenticated account's credit usage and remaining balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic operation. It does not mention authentication requirements, rate limits, or any other context that would help the agent anticipate behavior.
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?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and clearly communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no parameters, and the presence of an output schema, the description is adequately complete. It could mention that it requires authentication, but it is sufficient for a simple read operation.
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?
The tool has zero parameters, so the description does not need to add parameter semantics. The baseline score for 0 params is 4, and the description meets that standard.
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 uses a specific verb 'Get' and clearly identifies the resource as 'the authenticated account's credit usage and remaining balance', providing a precise purpose that distinguishes it from other tools like fetch or scrape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing credit info) but offers no explicit guidance on when not to use or alternatives. It is adequate but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extractCInspect
Extract structured data from a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| kwargs | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavior. It states 'extract structured data', implying a read-only parse, but does not disclose whether the operation is safe (e.g., read-only), what format the output takes, or any rate limits or authentication needs. The minimal description leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words) but under-specified. Conciseness should not come at the cost of omitting critical information. It reads as incomplete rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not leverage it to explain return values. The tool is a structured data extraction endpoint with complex behavior (url parsing, kwargs), but the description fails to cover error conditions, supported URL types, or expected kwargs format. Incomplete for a tool with two required parameters and no schema annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for either parameter. 'kwargs' is entirely opaque; its type and role are undefined. This forces the agent to guess or fail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Extract structured data from a URL', which is a clear verb and resource. However, it does not differentiate from siblings like 'fetch' or 'scrape', which might also retrieve data from URLs. The phrase 'structured data' implies parsing but is not explicit about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use 'extract' versus alternatives like 'fetch', 'scrape', or 'search_free'. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchCInspect
Fetch a single URL and return its extracted content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'return its extracted content' without specifying redirects, JavaScript execution, authentication, rate limits, or destructive actions. This is insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks necessary details and is not front-loaded; every word counts but fails to earn its place by omitting critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (2 parameters, output schema exists), the description still fails to cover behavior or parameter details. It does not reference the output schema, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning beyond the structure. It does not explain the expected format for 'url' or the impact of 'timeout_seconds'. The parameter names alone are not enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'a single URL', and specifies the output 'extracted content'. However, it does not differentiate from sibling tools like 'scrape' or 'crawl', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., for single vs. multiple URLs, static vs. dynamic content). There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crawlCInspect
Get the current status and results of a crawl.
| Name | Required | Description | Default |
|---|---|---|---|
| crawl_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'get', implying read-only, but doesn't disclose potential rate limits, cost implications, or whether it requires an existing crawl ID. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It uses space efficiently but does not earn its place by adding substantial value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are partially covered. However, the description omits context about how to obtain the crawl_id, typical use cases, and any side effects. Incomplete for a 1-parameter tool with no parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'crawl_id' parameter—its origin, format, or validation. No added meaning beyond the schema's type and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves status and results of a crawl. It uses a specific verb-resource pair, differentiating from 'crawl' (which initiates) and 'get_job' (which gets a job). However, it could be more precise about what 'results' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'crawl' or 'get_job'. No prerequisites or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobCInspect
Get the current status and results of a job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states a read operation but does not mention potential errors, authentication needs, or that job_id must be valid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the purpose. It is appropriately short with no wasted words, though it could be structured with more details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and is simple (1 required param), the description is adequate but minimally complete. It does not mention return structure or error conditions, but the output schema presumably covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the only parameter 'job_id' is not explained beyond its name. The description adds no meaning about what a job_id is or how to obtain it.
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 clearly states the verb 'Get' and the resource 'current status and results of a job', which is specific and differentiates from sibling tools like 'get_crawl' (for crawl jobs) and 'create_job' (for creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_crawl' or 'list_history'. It does not mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_historyCInspect
List past requests for the authenticated account.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral context. It implies read-only access but does not disclose pagination, rate limits, or scope of 'past requests'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise but sacrifices necessary detail. It is not overly verbose, but lacks structure for effective parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter info and no annotation coverage, the description is incomplete. It fails to explain the parameter's role or the output format, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the single 'params' parameter. The description offers no explanation of what 'params' expects or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists past requests for the authenticated account. It distinguishes from siblings like 'fetch' or 'scrape' by focusing on history, but does not explicitly differentiate from 'list_monitors'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, context, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsCInspect
List configured Evidence Monitor checks for the authenticated account.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the tool lists items, implying read-only behavior, but does not mention authentication needs, pagination, rate limits, response structure, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly expanded to include parameter details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to mention it or the purpose of the required 'params' parameter. The tool has moderate complexity due to the opaque parameter, and the description does not provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'params' is required but completely undocumented. Schema coverage is 0%, and the description adds no meaning about its structure, allowed values, or purpose. This is a critical gap.
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 clearly states the verb ('List'), the resource ('configured Evidence Monitor checks'), and the scope ('for the authenticated account'). It distinguishes from siblings like 'list_history' by specifying 'Evidence Monitor checks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'list_history' or 'get_job'). The description lacks explicit context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
map_siteCInspect
Map a site's discoverable URLs starting from a seed URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| kwargs | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the high-level action, omitting details such as return format, pagination, rate limits, or whether it respects robots.txt. The output schema exists but the description provides no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. However, it is too brief and could have included essential details without significant bloat, so it is not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mapping site URLs) and the presence of an output schema, the description is insufficient. It does not specify scope (e.g., breadth/depth limits), required permissions, or relation to sibling tools like 'crawl'. The output schema covers return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool has 2 parameters (url, kwargs). The description only implies that 'url' is the seed URL via the phrase 'starting from a seed URL', but does not explain 'kwargs' at all. This leaves agents guessing about the second parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Map') and resource ('a site's discoverable URLs'), with context ('starting from a seed URL'). However, it does not differentiate from sibling tool 'crawl', which performs similar functionality. Still, the verb+resource combination is distinct enough for basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'crawl' or 'extract'. The description lacks context for appropriate usage scenarios, exclusions, or prerequisites (e.g., domain availability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrapeCInspect
Scrape a URL with source-aware routing and return structured content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| kwargs | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'source-aware routing' but does not explain what that entails, nor does it disclose any side effects, authentication requirements, rate limits, or potential destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that efficiently conveys the core purpose and unique feature. While concise, it sacrifices necessary detail, but the sentence earns its place by being direct and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of two parameters with no schema descriptions, a potentially complex 'source-aware routing' behavior, and no annotations, the description is insufficiently complete. It fails to clarify key aspects like how to use 'kwargs' or what the 'source-aware routing' implies, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning for the two parameters. 'url' is implicitly understood, but 'kwargs' is left completely unexplained, making it non-trivial for an AI agent to determine correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Scrape a URL') and a distinguishing feature ('source-aware routing') and outcome ('return structured content'). It is specific enough to convey the core purpose, though it does not explicitly differentiate from sibling tools like 'fetch' or 'extract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it, prerequisites, or comparisons with sibling tools like 'fetch', 'search_free', or 'crawl'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_freeCInspect
Run a free-tier web search and return results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it returns results. No disclosure of rate limits, scope limitations, or any behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but it lacks some informative content that would make it more valuable. Still, it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of output schema, the description is still too sparse. It omits usage guidelines and behavioral context, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage and the description adds no meaning beyond the parameter name 'query'. No hints on format, constraints, or expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a free-tier web search and returns results. It uses specific verb 'Run' and resource 'web search', and 'free-tier' hints at differentiation from possible paid versions among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like fetch, scrape, or crawl. No mention of ideal scenarios or when not to use it.
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.
13 tool updates
v1.0.0- First observed
account - First observed
crawl - First observed
create_job - First observed
credits - First observed
extract - First observed
fetch - First observed
get_crawl - First observed
get_job - First observed
list_history - First observed
list_monitors - First observed
map_site - First observed
scrape - First observed
search_free
TDQS
B3/5.0
Scored across 13 tools
Disambiguation3/5
Tools like fetch, scrape, and extract have overlapping descriptions (all extract content from URLs), making it ambiguous which to use for a given task. Other tools are distinct, but this cluster reduces clarity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., get_crawl, create_job), but a few are single verbs (fetch, scrape, extract) which is a minor deviation. Overall, the naming is clear and predictable.
Tool Count5/5
13 tools cover the core functionalities of web scraping, crawling, job management, account info, and monitoring without being excessive. Each tool serves a distinct purpose.
Completeness4/5
The tool set covers primary workflows (fetch, scrape, crawl, search) but lacks creation or management of monitors beyond listing, and job management only supports create/get, missing delete or update.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Hosted Web Crawler MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Turn any public website into an MCP server for agents to search, read and navigate.
Scrape, crawl and search the web for AI agents via MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceUnlimited web access MCP server for AI agents, enabling search, fetch, and learning across multiple sources while bypassing anti-bot protections.MIT
- AlicenseNot gradedqualityDmaintenanceMCP tool server that gives any AI agent the ability to search, scrape, and analyze content across the internet.42MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.1MIT