Agent Data Tools: Web and documents

by dev.workers.revmesh2074.agent-data-tools

extract

Read public static HTML, Markdown or plain text. HTML includes code, tables, links, heading IDs, image alt text and unverified author/date provenance. Optional exact HTML section ID. Default 20,000 output characters, maximum 100,000; input 2 MiB. No JavaScript rendering, authentication or paywall access. Empty pages, invalid sections, browser challenges and execution errors are uncharged. Use to read docs or articles into context. Costs $0.002 in USDC on Base per successful call, paid with x402.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Absolute http(s) URL of the page to fetch
`format`	No	Returned representation: text (default), markdown, or both. HTML structured details are included in every format; Markdown/plain sources have empty details.
`section`	No	Optional exact visible HTML ID within primary content, 1-500 characters. Heading scope includes subsections until next same/higher-level heading; section/article/main/div scope is its subtree. Missing/ambiguous/unsupported targets fail uncharged. URL fragments alone do not select a section.
`maxChars`	No	Maximum characters of body text to return (500-100000, default 20000)

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`lang`	Yes
`text`	No
`links`	Yes
`title`	Yes
`format`	Yes
`status`	Yes
`tables`	Yes
`section`	Yes	Null for full primary-content reading. Otherwise the explicitly requested scope; title/description/canonical remain page-level metadata. Heading scope ends before the next same/higher-level heading, including nested subsections; container scope is its subtree.
`finalUrl`	Yes
`headings`	Yes
`markdown`	No
`warnings`	Yes
`canonical`	Yes
`fetchedAt`	Yes
`truncated`	Yes	Input or requested primary representation is incomplete. Structured detail limits are reported separately in warnings.
`codeBlocks`	Yes
`hashFormat`	Yes
`textLength`	Yes	Full extracted text length before the character cap, within the input limit.
`contentHash`	Yes
`contentType`	Yes
`description`	Yes
`linkBaseUrl`	Yes	Effective source-derived HTTP(S) base for links: the first supported HTML base href outside inert/foreign subtrees, otherwise finalUrl. Credentials and non-HTTP(S) base values are ignored with a warning. HTML links/canonical use this base; raw Markdown keeps relative syntax and can be resolved using this field. No linked resource is fetched. This static interpretation does not evaluate scripts or Content Security Policy.
`sourceFormat`	Yes	Source interpretation. Markdown is identified by text/markdown, or a .md/.markdown final path served as text/plain (warned). Markdown syntax is retained verbatim within the cap, not converted to HTML or parsed for structured details; text also retains that syntax. HTML section IDs are unsupported for Markdown/plain text.
`sourceMetadata`	Yes	Page-level source declarations, not verified authorship or freshness. Head author/Open Graph date tags and bounded direct Schema.org JSON-LD Article/WebPage-like nodes only; exact-URL matches preferred, otherwise only one identity-free candidate. Author @id references resolve only to unambiguous local Person/Organization names, with both paths recorded. No external context/reference fetching or general JSON-LD expansion. Separate 2000-character value+provenance budget; 5 authors/10 dates. Original date strings are not normalized. Empty for Markdown/plain sources; unrelated entities and ambiguous nodes are omitted with warnings.
`contentSelection`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses concrete operational traits: default 20,000 and max 100,000 output characters, 2 MiB input cap, exact failure semantics ('Empty pages, invalid sections, browser challenges and execution errors are uncharged'), and the payment model ('$0.002 in USDC on Base per successful call, paid with x402'). This also explains why readOnlyHint is false despite a read operation — the call spends money — so there is no contradiction.

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?

Purpose is front-loaded and every sentence carries information (limits, cost, failure handling), with no filler. It is dense to the point of being run-on, packing limits, exclusions, failure rules and pricing into a single block, which slightly hurts scannability.

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?

For a paid, open-world fetch tool with an output schema already covering the return shape, the description supplies everything else an agent needs: input/output size caps, JS/auth/paywall limits, cost and currency, and which failures are free. Nothing material is missing before invocation.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: what the HTML 'details' payload actually contains (code, tables, links, heading IDs, image alt text, unverified author/date provenance) and that section must be an 'exact HTML section ID' with URL fragments explicitly not selecting a section. The default/max char figures duplicate the schema, but the format-detail explanation is genuine added value.

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 gives a specific verb+resource ('Read public static HTML, Markdown or plain text') and immediately bounds the scope with negatives ('No JavaScript rendering, authentication or paywall access'), which implicitly separates it from siblings like html_to-text (converts supplied HTML), screenshot (renders JS) and pdf_text. It also enumerates what an HTML fetch yields (code, tables, links, heading IDs, alt text, author/date provenance), so an agent knows exactly what class of tool this is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a positive use case ('Use to read docs or articles into context') and the exclusions ('No JavaScript rendering, authentication or paywall access') implicitly define when not to use it. However, it never names an alternative for those excluded cases (e.g. screenshot for JS pages), so routing to a sibling is left to inference.

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

All Agent Data Tools: Web and documents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?