Skip to main content
Glama

web_crawl

Read-only

Crawl one site from a start URL and return each page as deduplicated Markdown while obeying robots.txt. Use when page URLs are not known in advance.

Instructions

Crawl one site from a start URL and return every page as markdown, deduplicated, robots.txt obeyed. Use when the pages are not known in advance; when they are, web_fetch_many is cheaper, and web_map lists a site's URLs for a few hundred tokens before deciding to crawl. max_pages (20), max_depth (2), include (URL substring), query (rank by relevance, stop when saturated), strategy=dfs for a manual or a paginated listing, schema or tables for rows from every page. For many rows pass out_file (.csv, .json, .jsonl): a path comes back instead of the pages. Returns the pages and a crawl_id; pass it back as crawl_id to resume an interrupted crawl. Links to a page's own site are paths, to be joined to that page's url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesStart URL. Crawl stays on this domain.
alsoNoMore sites to crawl alongside `url`, under the same page and token budget. Each domain gets an equal share of the pages, so one large site cannot spend the whole run.
modeNoLeave unset: auto learns the tier per domain.
dedupNoSkip near-duplicate pages, reporting what they duplicate instead of their content. Default true.
queryNoRank pages by relevance to these words, keep only the relevant blocks, and stop when new pages add nothing (see `stop_when_saturated`).
outputNoOutput shape: pages (default), llms.txt, llms-full.txt.
robotsNorobots.txt policy: obey (default for crawling), warn, ignore.
schemaNoRows instead of prose from every page, as on web_fetch: "auto" or your own selectors. With `out_file`, one row per item, each carrying its page's `url`.
scrollNoScroll every page until it stops growing before reading it (`"auto"` or a round count), for sites whose listings load as you scroll. Implies browser tiers; slower.
tablesNoEvery page's data tables as typed rows, as on web_fetch.
includeNoOnly follow URLs containing this substring (e.g. "/docs/").
timeoutNoTimeout in ms per page. Default 45000.
crawl_idNoResume an interrupted crawl by the `crawl_id` it returned: queue, pages already fetched and parameters all come back. web_status lists the ones with work left.
out_fileNoWrite the pages to this file instead of returning them, as CSV, JSON or JSON Lines depending on the extension. What comes back is a path and a count.
strategyNoOrdering: best_first (default when a query is given), bfs, or dfs to follow one branch to its end before starting the next — what a manual or a paginated listing wants.
max_depthNoLink depth from the start URL. Default 2.
max_pagesNoMaximum pages to fetch. Default 20, max 200.
extractionNomarkdown (default), text, or html.
max_duration_msNoGive up after this long regardless. Default 120000.
max_tokens_totalNoWhole-crawl token cap. Default 60000.
since_last_crawlNoSeed from the site's sitemap and fetch only what its `lastmod` says has changed since this machine last read it. A page with no date is always fetched: silence is not "unchanged".
max_chars_per_pageNoPer-page content cap in chars. Default 8000.
stop_when_saturatedNoStop once the crawl stops learning anything new about `query`. Default true when a query is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds substantial context beyond that: robots.txt obedience, dedup defaults, resume semantics via crawl_id, saturation stopping, out_file changing the return shape to a path+count, and link-joining note. Does not cover rate limits or token/cost tradeoffs, so not 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded main purpose is good, but the param rundown sentence is dense and lists roughly a dozen parameters inline, some of which (max_pages default 20, max_depth 2) repeat schema defaults. Informative but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 23-param crawling tool with no output schema, the description covers the essential behavior an agent needs: scope, dedup, robots, resumption, saturation, output-shape switching. Return format is described at a high level (pages + crawl_id) which is sufficient since no output schema exists.

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 schema already documents all 23 params; baseline 3. The description still adds cross-field meaning: out_file changing return type, include-URL-substring, query+stop_when_saturated coupling, strategy=dfs use case, schema/tables producing rows, crawl_id resumption. Marginally above baseline but largely restates schema.

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?

States a specific verb (crawl) and resource (one site from a start URL), and names the return (every page as markdown) with modifiers (deduplicated, robots.txt obeyed). Explicitly distinguishes from siblings web_fetch_many and web_map with the condition that selects each.

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?

Gives the core when-to-use ('pages are not known in advance') and two named alternatives with their own selection conditions: web_fetch_many when pages are known (cheaper), web_map for pre-crawl URL listing. Routes the agent without schema inspection.

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