Skip to main content
Glama

Extract several pages

extract_many
Read-onlyIdempotent

Extract structured data from up to 25 URLs in order, returning summaries, records, and induced fields while respecting robots.txt and TDM rights.

Instructions

Read several pages' declared data, politely, in the order given.

urls: 1 to 25 http(s) addresses, on one site or several; one given twice is read once. records: also return each page's records, not only its summary; the heaviest pages' records are left out first to keep the answer under 75,000 bytes, each counted in that page's records_left_out. induce: also read repeated rows from a page that declares nothing about them; those fields say source "induced". respect_tdm: give a page whose site reserves its text and data mining rights (TDMRep) as a tdm_reserved error, never its data.

Returns {"ok", "pages", "stopped"}. Pages come in the order given, each {"ok", "url", "landed", "fetch", "canonical", "summary", "sources", "types", "links"}, and "records" when asked -- or, when it has nothing, {"ok": false, "error"} with the page's reason. A page asked again after a request that may succeed later says so in "retries". Each site is asked one request at a time, a second apart or its Crawl-delay, robots.txt obeyed; several sites at once. stopped is "done", or "time_budget" when a minute passed first and the pages after are left out. ok is false only when no page could be read, and error then says why. Past 75,000 bytes the heaviest pages' records go first, then the heaviest summary answers, named in summary_left_out, then the last pages, counted in pages_left_out. For many more addresses, or a whole site, the command line's sluicer batch has no such bounds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlsYes1 to 25 http(s) addresses, on one site or several; one given twice is read once.
induceNoalso read repeated rows from a page that declares nothing about them; those fields say source "induced".
recordsNoalso return each page's records, not only its summary; the heaviest pages' records are left out first to keep the answer under 75,000 bytes, each counted in that page's records_left_out.
respect_tdmNogive a page whose site reserves its text and data mining rights (TDMRep) as a tdm_reserved error, never its data.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
errorNo
pagesNo
stoppedNo
pages_left_outNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description reveals rate-limiting behavior, robots.txt compliance, TDM handling, retries, time-budget stopping, duplicate reads, and truncation mechanics. These are significant behavioral details the annotations alone do not provide.

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 long but every section earns its place: purpose, flag semantics, output shape, failure modes, and limits. It is front-loaded with the core action and then structured into readable chunks, though the density is high enough that it could lose some less essential details.

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 complexity of the tool and the output schema, the description is remarkably complete: it covers exact output keys, page-level success/failure shapes, ordering guarantees, truncation thresholds, rate limits, robots/TDM behavior, retries, and global failure conditions. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description repeats and elaborates on the same flag semantics found in the schema but does not add meaning beyond what the input schema already documents.

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 opens with a specific verb and resource: 'Read several pages' declared data, politely, in the order given.' It clearly distinguishes this batch read tool from single-page or site-crawling siblings by emphasizing multiple URLs, deduplication, and bounded scope.

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

Usage Guidelines5/5

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

It explicitly states the valid input range (1 to 25 http(s) addresses), deduplication behavior, and gives a clear alternative for larger jobs: 'the command line's sluicer batch has no such bounds.' This tells an agent when to choose this tool and when to look elsewhere.

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