A real browser for your agent: a page to clean text for $0.009, a 25-page site for $0.14. x402.
Scored across 3 tools
The tools are mostly distinct: page_extract handles single-page JS rendering, site_extract handles same-host sections with JS, and web_read handles plain multi-page reads without JS. There is some overlap between page_extract and web_read for single pages, but the descriptions clearly call out the JavaScript execution difference and web_read explicitly points to page_extract for rendered pages.
All tool names use lowercase snake_case and follow an object_verb structure: page_extract, site_extract, web_read. However, the verbs are mixed (extract vs. read), which creates a slight inconsistency in the action implied, though the pattern is still predictable and readable.
With only 3 tools, the set is tightly scoped to the server's web-extraction purpose. Each tool covers a distinct use case—single-page rendering, site-section crawling, and multi-page plain reads—so no tool feels redundant and the count is appropriate for the niche.
The surface covers the core workflows: single-page JS rendering, simple multi-page text extraction, and site-wide section rendering. A minor gap is the lack of a tool for JavaScript-rendered multiple arbitrary pages (site_extract is limited to the same host), but agents can work around this by combining page_extract and web_read.
Render any public web page in a real headless Chrome and return its text. JavaScript runs first, so docs sites and single-page apps that a plain fetch returns empty come back complete. $0.009 per call (x402 on Arc/Base/Solana/X1): the full text and every outbound link. Without a payment the call returns the price and every rail we accept. Refuses private and reserved addresses and our own hosts, so it cannot be used as a proxy into a network. Sites that put a bot wall in front of their pages (Cloudflare, DataDome and the like) answer with a challenge rather than the page: the call then FAILS with http-403 or bot-challenge and says so, rather than charging you for a spinner.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the http(s) page to render | |
| full | No | true asks for the paid full text. Without a payment you get a 402 carrying the price and every rail we accept; sign it and call again with `payment`. | |
| payment | No | a signed x402 payment (the same base64 payload you would put in the PAYMENT-SIGNATURE header). Pass it here and the purchase completes inside this tool call - you never have to leave MCP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pricing and payment requirements, security restrictions (refuses private/reserved addresses and own hosts), bot-wall failure modes with specific error codes (http-403, bot-challenge), and the fact that it only charges on success. This is exceptionally transparent.
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 detailed but each sentence adds value: purpose, JS behavior, pricing, security, failure modes. It is front-loaded with the primary purpose and structured logically. It is appropriately sized for the tool's complexity.
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 tool with no output schema, the description covers return values (full text and outbound links, or price and rails, or error codes), payment requirements, security constraints, and failure behavior. All three parameters are explained with usage context. It is complete for an agent to call correctly.
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 100%, so baseline is 3. The description adds meaningful context: it explains the behavior of the 'full' parameter (paid vs free 402 response) and the 'payment' parameter (signed x402 flow that completes inside the tool call). It clarifies the purchase flow beyond the schema's terse descriptions.
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 renders any public web page with headless Chrome and returns its text, with JavaScript execution. It distinguishes itself from a plain fetch by highlighting JS rendering. Though it doesn't explicitly reference the sibling site_extract, the purpose is unambiguous and specific.
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 provides context for when to use the tool (JS-rendered pages that plain fetch can't get) and mentions bot-wall failures, but it never mentions the sibling site_extract or gives explicit exclusions. No alternative tool is suggested, so an agent has no guidance on when to choose this over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a whole section of a site - up to 25 pages - in one call and get every page back as clean text, with JavaScript executed. Same host only; robots.txt is obeyed and anything it disallows is skipped and named. FREE: the crawl PLAN - exactly which pages would be fetched and what robots.txt allows - so you can see what you would get before paying. PAID ($0.14, x402 on Arc/Base/Solana/X1): every page rendered and returned. It costs more than one page because it is up to 25 real browser renders, not a lookup. If a bot wall on the site lets the first page through but blocks the rest, the call fails with poor-yield and names every page it could not render, instead of billing you for a list of failures.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the page to start from | |
| full | No | true asks for the paid crawl. Without a payment you get a 402 carrying the price and every rail we accept; sign it and call again with `payment`. | |
| pages | No | how many pages, default 10, hard cap 25 | |
| payment | No | a signed x402 payment (the same base64 payload you would put in the PAYMENT-SIGNATURE header). Pass it here and the purchase completes inside this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses several critical behaviors: respects robots.txt and skips disallowed pages, costs more than one page due to real browser renders, and has a failure mode (poor-yield) that returns page names instead of billing. However, it does not mention rate limits, timeouts, or whether links are followed recursively and how depth is determined, leaving room for ambiguity.
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 dense with information but each sentence earns its place: scope, host restriction, robots.txt handling, free plan, paid plan, cost justification, and failure mode. It is front-loaded with the main purpose and then details. Slightly long but justified given the complexity.
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 has 4 parameters (one required), no output schema, and no annotations, the description covers most essentials: what it does, how payment works, error handling, and constraints. Missing: what the output format looks like (plain text), how it handles multi-page navigation (e.g., link discovery), and whether authentication/cookies are supported. But for an agent to call it, the description is fairly complete.
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 100%, so baseline is 3. The description adds valuable meaning: it explains 'full' triggers the paid crawl, and the free version returns a crawl plan, and 'payment' is a signed x402 payload. It also clarifies 'pages' has a hard cap of 25 and default 10. This goes beyond the schema's terse field names.
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 renders a whole section of a site (up to 25 pages) in one call, returning clean text with JavaScript executed. It explicitly contrasts with the sibling page_extract by emphasizing the whole-section scope and the multiple-page coverage, making the distinction obvious.
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 explains when to use this tool (when you need multiple pages from the same host) and notes the paid vs free flow: the free crawl plan shows what would be fetched, and the paid version returns all pages. It also warns about bot walls and the poor-yield failure mode, making the usage context explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to 10 web pages as clean text in one call: title, description and readable body, with the final URL. A plain fetch (no JavaScript); for a rendered page use page_extract. $0.003 per call over x402 (USDC on Arc, Base or Solana, or XNT on X1). Call once without payment for the terms, sign them with your own wallet, call again with payment.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | comma-separated URLs, up to 10 | |
| payment | No | a signed x402 payment (the base64 payload you would put in PAYMENT-SIGNATURE). Pass it and the purchase completes inside this tool call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses that this is a plain fetch, that JavaScript is not executed, that there is a per-call cost, and that payment requires a two-step signed flow. This gives the agent a clear model of side effects and prerequisites.
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?
Three sentences, each with a distinct job: what it returns, how it differs from page_extract, and how payment works. No filler or repetition.
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?
The description is complete for a read tool of this complexity: it names the return contents, the no-JavaScript limitation, the alternative tool, the cost, and the payment flow. No output schema exists, but the description covers what the agent needs.
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 100%, so both urls and payment are already documented. The description adds meaningful workflow context for payment—call once without it, sign the terms, then pass it—and reinforces the up-to-10 limit for urls.
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: reads up to 10 web pages and returns title, description, readable body, and final URL. It also distinguishes itself from page_extract by specifying that this is a plain fetch without JavaScript.
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 explicitly says to use page_extract for rendered pages, establishing when web_read is the wrong choice. It also provides the full payment workflow: call once without payment for terms, sign with your wallet, then call again with payment.
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.
web_readpage_extractsite_extractWeb search for agents, one x402 payment: real results, provider failover, signed receipt. $0.01.
x402 structured link extraction for agents. $0.0005 per successfully processed page.
Pay-per-call browser rendering and x402 marketplace ranking for AI agents, billed via USDC.
x402 cited web research and synthesis for agents. $1.99 per completed brief.
Add one secure layer between your agents and this server.
