Give it a URL, get structured rows. A model writes the parser once; replays are free.
Scored across 5 tools
The five tools target recognizable stages: account/quota lookup, cheap platform detection, single-page extraction, bulk-site crawling, and asynchronous crawl status polling. Only mild blur remains between crawl_site's "links" mode and doing repeated extract_page calls against each linked page.
Four active functions broadly follow descriptive lower_snake_case phrasing such as crawl_site, crawl_status, detect_site, and extract_page. The lone exception is "account", whose bare topical name differs stylistically and omits any indication of the retrieval action intended.
With five tools the server stays tight and role-based: information/prep, one-off extraction, bulk crawl launch/completion checking, and quota reporting. Every entry represents a plausible step in normal scraping workflows without padding.
Core capabilities span reconnaissance, single-page and whole-site harvesting, deferred outcomes via crawl_status, and credit monitoring. Operational extras such as cancelling/deleting queued jobs or reviewing past-crawl details look unexposed, leaving users dependent on whatever limited state those methods already retain.
Credits left and this month's usage for the key in use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It conveys a read-only status operation but does not explicitly state that it is non-destructive, whether it consumes credits, or any rate-limit implications. The output schema covers return shape, but behavioral traits are otherwise minimal.
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 a single, front-loaded sentence with no filler. Every word contributes to conveying what the tool does.
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?
For a zero-parameter, read-only status tool with an output schema, this is nearly complete. It tells the agent what to expect and which key applies. Adding an explicit 'safe to call' note would make it fully complete, but the gap is small.
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 tool has zero parameters, so there is little to explain beyond the empty schema. Mentioning 'the key in use' clarifies that no explicit key parameter is required, which is a small but useful semantic addition.
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 resource (the API key/account) and what it reports: credits left and monthly usage. It does not explicitly contrast with sibling tools, but the siblings are all crawl/detect/extract operations, so the domain distinction is clear.
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 intended use is implied: call this when you need to check remaining credits or usage for the active key. There is no explicit 'when to use this vs alternatives' guidance, though no sibling is a natural alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk a site and extract every item. Waits up to four minutes; a longer crawl returns a job_id to pass to crawl_status.
`mode` picks how the items are found. "rows" (the default) reads every
card on the listing itself and follows its pagination -- right for
search results, categories and tables. "links" follows each card into
its own page, for sites where an item has one. "like" starts from one
example item page, given as `like_page`, and finds every other page
shaped like it; pass `listing_url` as well when you know the stock or
results page, because inferring it is the part that fails.
| Name | Required | Description | Default |
|---|---|---|---|
| js | No | ||
| mode | No | rows | |
| fields | No | ||
| scroll | No | ||
| like_page | No | ||
| max_items | No | ||
| listing_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the four-minute timeout and the asynchronous job_id handoff to crawl_status, plus the failure-prone nature of inferring the listing URL in 'like' mode. It does not cover permission/auth needs or the behavior of js, scroll, and max_items, keeping it below a 5.
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 timeout/job_id behavior is front-loaded, followed by tightly-scoped per-mode guidance. Every sentence earns its place, though the mode prose is a dense run-on that could be structured more scannably.
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?
An output schema exists, so return values need not be described. The description covers the crawl flow, async handoff, and the mode semantics that matter most for calling it correctly; the gaps around js/scroll/max_items are the main shortfall for a 7-parameter tool.
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?
Schema description coverage is 0% across 7 parameters, so the description must compensate. It explains `mode`, `like_page`, and `listing_url` well, but says nothing about `js`, `fields`, `scroll`, or `max_items`, leaving half the surface undocumented anywhere.
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?
States a clear verb+resource: 'Walk a site and extract every item.' It also names crawl_status as the follow-up tool for long crawls, giving an agent a way to distinguish this from the status poller. It does not differentiate itself from extract_page or detect_site, so it falls short of 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?
Explicitly maps each `mode` value to a concrete situation ('rows' for search results/categories/tables, 'links' when items have own pages, 'like' for shape-matching from a sample page), and even notes when to also pass `listing_url`. That is strong when-to-use guidance for the parameter, though there is no guidance on choosing crawl_site over the sibling tools extract_page or detect_site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a crawl that outlived its call.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does reveal one meaningful trait — the asynchronous model where crawls continue after the initiating call returns — but it omits what the tool returns, whether it is a read-only status poll, whether it blocks or errors on unfinished jobs, and any polling semantics. This is a thin disclosure for a tool with zero annotation coverage.
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?
A single sentence of eight words with the main verb and object front-loaded; every word earns its place. The only knock is that 'outlived its call' is a clever, slightly indirect phrasing that trades directness for style.
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?
An output schema exists, so return-value documentation is covered externally. For a single-parameter tool the definition is nearly adequate, but the provenance of job_id is left to inference, the status semantics are unexplained, and there is no annotation safety profile. It is minimally sufficient but with clear gaps.
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?
Schema description coverage is 0%, so the description must compensate for the bare job_id schema, and it adds only marginal meaning: it implies job_id identifies the asynchronous crawl from a prior call. It does not say where to obtain job_id (presumably from crawl_site's response) or describe any format expectations, so the compensation is insufficient for 0% coverage.
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 uses a specific verb ('Fetch') and resource ('a crawl'), and the phrase 'outlived its call' clarifies this targets a crawl job still running after the initiating call returned. This distinguishes it from the sibling tools (crawl_site initiates, extract_page/detect_site do other work). However, it never explicitly says it returns status/progress/results, leaving that to be inferred from the tool name.
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?
Usage context is implied rather than stated: 'a crawl that outlived its call' suggests the agent should use this after initiating a crawl and wanting to check on it later. No explicit when-to-use guidance, no named alternatives, and no exclusions are provided, so the agent must infer the relationship to crawl_site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what platform a site runs on and which strategy to use. Cheap; call it before a large job.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds only 'Cheap' as a cost/performance hint and implies a read-only report, but does not describe side effects, network behavior, output handling, or failure modes. This is minimal disclosure for a tool with zero annotation support.
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?
Two short sentences with no filler. The primary purpose is front-loaded, and the second sentence adds a genuinely useful operational hint about cost and timing. Every word earns its place.
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?
For a single-parameter tool with an output schema, the core is simple, and the purpose plus usage hint may be enough to attempt a first call. However, with no annotations, the description still omits input semantics and any behavioral details, leaving the agent with only a skeletal understanding.
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?
Schema description coverage is 0%, and the description never mentions the url parameter, its expected format, or any constraints. The only hints are the tool name and the word 'site', which do not add meaning beyond the schema's minimal field title. The description fails to compensate for the missing schema documentation.
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 states a specific action ('Report') and resource ('what platform a site runs on and which strategy to use'), which clearly distinguishes it from sibling tools like crawl_site, crawl_status, and extract_page. It stops short of explicitly naming those alternatives, but the purpose is not vague.
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 explicitly tells the agent when to call this tool: 'call it before a large job', and adds the cost dimension with 'Cheap'. It does not enumerate alternatives or exclusions, but the narrow purpose and clear trigger make the guidance actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from ONE page. fields declares your own
schema, e.g. ["title", "salary:number", "tags:list"]; omit it for the
product schema. First call on a new site compiles a recipe (300
credits); later calls replay it for 1 credit per row.
A site nobody could read is remembered for a week and answered
without calling the model, so re-reading a dead page costs nothing.
`retry` asks anyway.
| Name | Required | Description | Default |
|---|---|---|---|
| js | No | ||
| url | Yes | ||
| retry | No | ||
| fields | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the credit economics (300 credits to compile a recipe, 1 credit per row on replay) and the week-long negative caching of unreadable sites. It does not explain what the `js` flag changes or any auth/rate-limit behavior.
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?
Front-loads the core action, then the schema hint, then the cost/caching model in three tight paragraphs. The embedded code and line breaks are slightly noisy but every sentence carries information.
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?
An output schema exists, so return values need no explanation. An agent gets purpose, schema override, cost model, and caching caveat; only the `js` parameter remains a gap for a 4-parameter tool.
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?
Schema coverage is 0%, so the description must compensate. It explains `fields` in useful detail (declaration syntax, default behavior) and `retry` explicitly, but `js` and `url` are left entirely undocumented.
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?
States a specific verb+resource ('Extract structured data') and scopes it emphatically to 'ONE page', which implicitly separates it from the sibling crawl_site. It never names an alternative tool outright, so the differentiation is inferable rather than explicit.
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?
Gives clear operational context: omit `fields` to fall back to the product schema, use `retry` to force a read of a site remembered as unreadable. It does not, however, say when to choose this over crawl_site or detect_site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
extract_page1 field changedInput schema / properties / retryAdded value: +{
+ "default": false,
+ "title": "Retry",
+ "type": "boolean"
+}crawl_site2 fields changedInput schema / properties / like_pageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Like Page"
+}Input schema / properties / modeAdded value: +{
+ "default": "rows",
+ "title": "Mode",
+ "type": "string"
+}accountcrawl_sitecrawl_statusdetect_siteextract_pagePDF URLs to per-page text, tables as rows, Markdown, metadata and OCR for scanned pages.
URL to Markdown or structured JSON (schema.org/OG); renders SPA; batch reads. No signup/key.
Reliable PDF table extraction. Pass a URL, get structured JSON tables with citations.
Turn any URL into clean, structured, agent-ready content. $0.02/call via x402 on Base.
Add one secure layer between your agents and this server.