Skip to main content
Glama
Search1API MCP Server

Search1API MCP Server

Crawl a website

deepcrawl
Read-only

Read multiple pages from one website in a single task by crawling sitemap URLs that match path rules, returning citable titles, URLs, and Markdown content for site-wide research.

Instructions

Read many pages of one website in a single task, such as a documentation section, when the user needs content from across a site rather than one page. Finds the site's URLs through its sitemap, keeps those whose path matches the path rules, and returns up to max_pages pages as citable results with title, URL, and Markdown text, plus page counts and the URLs that failed. Costs 20 credits per started task, however many pages it reads. Waits about 45 seconds; if the crawl is still running, the result holds a task_id, and calling deepcrawl again with that task_id collects the pages at no cost. Use crawl for a single page and sitemap for a list of URLs without their content.

Input Schema

NameRequiredDescriptionDefault
urlNoSite or section to crawl, such as https://example.com or https://example.com/docs/; required unless task_id is given
typeNoWhere URLs come from: sitemap uses the site's sitemap, or the links on the start page when it has none; all uses every link discovered from the start URL, which can include other sitessitemap
task_idNotask_id from an earlier deepcrawl result that was still running; collects that crawl for free instead of starting a new one, and the other arguments are ignored
max_pagesNoMost pages to read, taken in discovery order after the path rules; the price is the same for any number
exclude_pathsNoSkip URLs whose path matches one of these rules, with the same syntax as include_paths; exclusion wins over inclusion
include_pathsNoOnly read URLs whose path matches one of these rules. A rule without * is a path prefix on segment boundaries ("/docs" matches /docs/api but not /docsearch); a rule with * must match the whole path, and * also matches / ("/blog/*")

Output Schema

NameRequiredDescriptionDefault
noteNoWhat to do next: call again with task_id, or where to find text that was cut
statsNoPage counts: links discovered, links matching the path rules, matches left out by max_pages, and pages crawled or failed
failedNoPages that could not be crawled, with the reason
statusYescompleted when the crawl has finished; running when it needs more time and results is empty
messageNoSummary of the finished crawl, including why nothing was crawled
resultsYesCrawled pages in discovery order; text holds each page's Markdown, shortened when metadata.truncated is true
task_idYesCrawl task id; pass it back as task_id while status is running
truncatedNoWhether page text was shortened or left out to bound the response
result_urlNoJSON file with every crawled page in full

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's credit cost (20 credits per started task regardless of page count), the ~45 second wait, and the task_id resumption path are genuine additions. The async polling pattern is the single most important behavioral trait for correct invocation and it is spelled out. It stops short of stating crawl-concurrency or failure-mode details beyond "the URLs that failed."

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?

Front-loaded with purpose then mechanics, cost, timing, resumption, and alternatives — a sensible priority order. Some clauses overlap the schema text ("returns ... with title, URL, and Markdown text") but the density is justified for a tool with async and billing semantics.

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 6-parameter, billed, potentially asynchronous crawl with an output schema, the description covers everything needed to call it correctly: selection criteria, cost model, latency, resumption, and sibling disambiguation. Return-value detail is correctly compressed since an 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 baseline is 3; the description still adds value by linking parameters into a workflow — that path rules gate which URLs are counted against max_pages, that price is flat regardless of max_pages, and that task_id overrides the other arguments. It doesn't restate the include_paths wildcard syntax, which it correctly leaves to the 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 sentence names a specific verb and resource ("Read many pages of one website in a single task") and scopes it to a site-section use case, which an agent can immediately distinguish from a single-page fetch or a bare URL listing. It also names the sibling tools it is not.

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?

The description states the selecting condition ("when the user needs content from across a site rather than one page") and explicitly routes to alternatives: "Use crawl for a single page and sitemap for a list of URLs without their content." When-not guidance is present, not just when.

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