Skip to main content
Glama

crawl

Discover URLs from a root page, then scrape each page while respecting page limit, depth, and include/exclude filters.

Instructions

Multi-page crawl: discover URLs on root, then scrape each.

Args: root: start URL. max_pages: hard cap on pages scraped. css_selector: reserved for the llm tier. prefer: "auto" | "fast" | "stealth" | "llm" (llm = Crawl4AI BFS deep-crawl). include_paths: regex — keep only URLs matching (matched against full URL). exclude_paths: regex — drop URLs matching (e.g. /tag/|/page/\d+). max_depth: 0 = flat harvest from the root page's links (default); >0 = true BFS up to that link depth, honoring the filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYes
preferNoauto
max_depthNo
max_pagesNo
css_selectorNo
exclude_pathsNo
include_pathsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description discloses key behaviors: URL discovery then scraping, a hard cap via max_pages, BFS depth semantics, regex filtering, and the llm-tier meaning of prefer. It does not discuss rate limits, auth, domain scoping, or side effects, but what it states is concrete and accurate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The summary line plus a compact argument list is appropriately sized for a 7-parameter tool. Every line adds value, default behavior is noted for max_depth, and the most important distinction (llm deep-crawl) is inline rather than in prose.

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?

The description is complete enough to call the tool with all 7 parameters meaningfully configured, and an output schema exists so return values need not be described. It would be stronger with a sentence on URL scope (e.g., same-domain only) and on what happens when include_paths and exclude_paths overlap.

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

Parameters5/5

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

Schema description coverage is 0%, but the description documents every parameter with types/semantics: root, max_pages, css_selector, prefer values, include/exclude regex behavior, and max_depth default semantics. It even gives an exclude_paths regex example, fully compensating for the bare 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?

The opening line 'Multi-page crawl: discover URLs on root, then scrape each' names a concrete verb and resource and describes the two-phase behavior. The 'multi-page' framing separates it from siblings like scrape, which presumably handles a single page.

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

Usage Guidelines3/5

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

The description implies the use case (multi-page crawling, BFS vs flat harvest through max_depth) but never explicitly says when to choose crawl over scrape, map_site, or batch_scrape. It also gives no exclusion guidance such as 'for single-page use scrape instead.'

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