x402 Scraper API

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the check is FREE and framed as a preflight, but says nothing about return shape, permissions, rate limits, or what 'safety' and 'pricing' actually mean.

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?

It is a single front-loaded fragment with no filler, and 'FREE' is useful context. However, it is too terse to be appropriately sized for a tool whose output semantics matter.

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 one-parameter tool with no output schema and no annotations, the description omits return values and the meaning of safety/pricing checks. It provides only high-level intent, leaving an agent unable to predict outputs.

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 single required url parameter is only described as a 'target URL'. The description adds no format, constraint, or example beyond the schema's string/uri typing.

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?

It states an action (preflight) and resource (target URL) and mentions safety/pricing checks, but 'safety' and 'pricing' are vague and it does not distinguish this tool from siblings like scrape_markdown or page_changed. An agent can infer a pre-check, but not exactly what it validates.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no routing to sibling alternatives. 'Preflight' weakly implies use before scraping, but the agent must infer that condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it discloses the most important non-obvious trait: an MCP invocation does not return comparison results but payment requirements, which must be settled via an HTTP POST. That is exactly the kind of behavioral disclosure that prevents a failed call. It stops short of describing the returned comparison payload or error behavior, so 4 rather than 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?

Two sentences, front-loaded with the price and payment model, then the purpose, then the settlement mechanics. Every clause carries information an agent needs; there is no filler.

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 two-string paid tool with no output schema and no annotations, the description covers cost, payment flow, and the core operation, which is what an agent needs to avoid a dead-end call. The remaining gap is input format and expected result shape, which is real but secondary given no output schema exists to defer to.

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% for two required string parameters, so the description must compensate and largely does not. It restates the concepts ('Polymarket rules', 'bookmaker market description') but never says whether these are raw text, JSON, URLs, or how long/complex they may be. An agent knows what to pass conceptually but not in what form.

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 verb and resource: 'Compare Polymarket rules with a bookmaker market description.' That is far more concrete than the sibling tools (check_url, scrape_markdown, etc.), so an agent can tell this is a domain comparison task rather than a scraping task. It never says what the comparison produces (e.g., a mismatch report), which keeps it from 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?

It gives the essential context for deciding to invoke: the call costs $0.05 USDC on Base and, over MCP, will only return payment requirements rather than a result, with the settlement path spelled out (POST /v1/market-rules/compare with x402 headers). That is strong operational guidance. It does not state when not to use it or any prerequisite on input format, so it falls short of explicit alternatives/exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does the hardest part: it discloses that this is a paid operation ($0.02 USDC on Base) and, critically, that the MCP call does NOT return extraction results but payment requirements. That non-obvious two-step semantic is exactly the kind of thing an agent would otherwise get wrong. It omits failure modes, expiry of payment requirements, and whether results are returned on the settle path.

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 dense sentences, with the most decision-relevant fact (this costs money) front-loaded before the mechanics. Nothing is wasted and it can be read in a few seconds.

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?

There is no output schema, and the description compensates by explaining what actually comes back over MCP (payment requirements) and how to complete the transaction. Combined with the paid nature of the call, this covers what an agent must know before invoking. Minor gaps remain around error handling and whether the settled POST returns the extracted JSON directly.

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% and the schema object is a free-form nested object, so the description has to carry meaning. It does explain the role of each parameter – the URL is the source, the JSON schema defines the desired output structure – which the bare schema does not convey. It gives no detail on supported JSON-schema subset, nesting depth, or format constraints.

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 transformation: a URL plus a JSON schema becomes structured JSON, which is a clear verb+resource statement. It is distinguishable from siblings like scrape_markdown and check_url, though it never names those siblings to draw the contrast explicitly.

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 second sentence explains the payment flow (MCP call returns requirements, settle via POST /v1/extract), which is useful operational guidance. However, there is no statement of when to choose this over scrape_markdown for schema-driven extraction versus plain markdown scraping, and no prerequisites or exclusions beyond the payment step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose a highly non-obvious trait: the MCP call does not perform the check, it returns payment requirements, and settlement happens via a separate POST with x402 headers, including the exact cost. It omits what a settled response contains and whether the payment requirement is returned every call or only once.

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 tightly packed sentences with the cost and the two-step settlement path up front; nothing is redundant. The density is high but the ordering is sensible, leading with price and purpose before the mechanics.

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 two-parameter tool with no output schema, it covers purpose, cost, and the settlement path an agent must follow, which is the critical missing piece. It stops short of describing the shape of a successful 'changed' result or the payment-requirements payload, so an agent still has gaps after a successful settle.

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. It usefully clarifies that 'since' accepts either a hash or a timestamp, which the schema does not say, but adds nothing about the 'url' parameter or format constraints, leaving half the parameters 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 operation: determine whether a page changed since a given hash or timestamp. The verb+resource is clear and distinct from siblings like scrape_markdown or extract_structured, though it never explicitly contrasts itself with check_url, which sounds closely related.

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 is only implied by the phrase 'since a hash or timestamp' — an agent can infer this is a conditional re-check tool. There is no explicit statement of when to prefer it over check_url or scrape_markdown, and no exclusions or prerequisites beyond the payment note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and discloses key behavior: paid cost, x402/Base network, MCP returns payment requirements, and settlement requires a separate POST with payment headers. It omits some post-settlement return details, but the most important operational behavior is exposed.

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 compact and front-loads the paid cost before stating the purpose and payment flow. It is dense and telegraphic but every sentence carries relevant operational 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?

Given no annotations and no output schema, the description explains the payment-requirements behavior and settlement endpoint, which is essential. It still leaves some gaps around what the tool returns after successful settlement and how payment failures are surfaced.

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, but it only says "URL" without specifying constraints, examples, or expected URL types. The single parameter is simple and the schema has format uri, but the description adds little meaning beyond that.

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 makes the core purpose clear: it converts a URL into clean markdown, and the tool name reinforces the verb-resource pairing. It does not explicitly distinguish this from sibling tools such as extract_structured, but the purpose itself is understandable.

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 explains the payment workflow: the MCP call returns payment requirements, and settlement happens via POST /v1/scrape/markdown with x402 headers. However, it does not say when to use this tool instead of siblings like check_url or extract_structured.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.