Skip to main content
Glama
spidra-io

spidra-mcp-server

Official
by spidra-io

spidra_crawl

Read-only

Crawl websites from a single starting URL by following links per your instructions. Extract structured data from discovered pages; returns a job ID for async status checks.

Instructions

Crawl a website starting from one URL: Spidra discovers pages by following links according to your plain-language instruction, and optionally extracts structured data from every page. Returns IMMEDIATELY with a jobId — it does not wait.

Best for: extracting from many pages when you do NOT know their URLs upfront (docs sites, blogs, product catalogs). Not for: URLs you already know (use spidra_scrape or spidra_batch_scrape — cheaper and faster). Workflow: call this, then poll spidra_check_crawl_status with the jobId every 10-15 seconds until terminal. Do NOT resubmit while a crawl is pending. Cancel a mistake with spidra_cancel_crawl.

Behavior notes:

  • "crawlInstruction" controls which links are followed (e.g. "Follow blog post links only, skip tag pages").

  • "transformInstruction" controls what is extracted per page; omit it (and schema) for raw markdown with no AI token cost.

  • Keep "maxPages" small (default 5, max 50) — every page costs credits.

Usage example:

{
  "name": "spidra_crawl",
  "arguments": {
    "baseUrl": "https://example.com/blog",
    "crawlInstruction": "Follow blog post links only, skip tag and category pages",
    "transformInstruction": "Extract the title, author, and publish date",
    "maxPages": 10
  }
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemaNoJSON Schema enforcing the exact output shape. Define EVERY field you want extracted — an untyped object with no properties comes back empty. Missing fields return null instead of hallucinated values.
baseUrlYesStarting URL for the crawl
cookiesNo
maxDepthNoMax link depth from the base URL. 0 = base URL only.
maxPagesNoMax pages to crawl (default 5). Keep small — each page costs credits.
useProxyNoRoute through a residential proxy (for blocked/geo-restricted sites)
excludePathsNoURL path patterns to skip, e.g. ["/tag/*"]
includePathsNoURL path patterns to include, e.g. ["/blog/*"]
proxyCountryNoTwo-letter country code for the proxy, e.g. "us", "de", "jp", or "eu"/"global"
allowSubdomainsNo
crawlInstructionYesWhich links to follow, in plain language
crawlEntireDomainNo
ignoreQueryParamsNo
transformInstructionNoWhat to extract from each page. Omit for raw markdown (no AI cost).
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses that the tool returns immediately with a jobId and runs asynchronously. It warns not to resubmit while pending, explains the cost implications of maxPages, and details how crawlInstruction and transformInstruction affect link-following and extraction. These are valuable behavioral details not present in the annotations.

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 description is well-structured with a clear opening sentence, then 'Best for', 'Not for', workflow, behavior notes, and a usage example. Every section contributes useful information; there is no repetition of schema details or fluff. It is appropriately detailed for a complex async tool, and front-loads the most important information.

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 covers the tool's purpose, async behavior, workflow, cost implications, and key parameters, and provides an example. While it doesn't explain every optional parameter or the exact return format, the schema covers most parameters and the description gives enough context for an agent to select and invoke the tool correctly. The missing output schema is partially compensated by the workflow explanation, but some details about response structure are absent.

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?

While the schema already documents 71% of parameters, the description adds important semantics for the two central instruction parameters (crawlInstruction, transformInstruction) and maxPages, clarifying defaults and cost. It also provides a concrete usage example that shows how to combine parameters. This goes beyond the schema's basic descriptions, though it doesn't explain every optional parameter in depth.

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 clearly defines the tool: it crawls a website from a starting URL, follows links based on a crawlInstruction, and optionally extracts structured data. It also distinguishes itself from related tools by stating what it is 'Not for' and naming alternatives like spidra_scrape and spidra_batch_scrape. This goes beyond a simple restatement, giving a specific verb and resource.

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 explicitly provides 'Best for' and 'Not for' scenarios, naming spidra_scrape and spidra_batch_scrape as cheaper alternatives when URLs are known. It also outlines the required workflow, including polling with spidra_check_crawl_status and canceling with spidra_cancel_crawl. This is model guidance that clearly tells the agent when to use this tool and when to pick a sibling tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/spidra-io/spidra-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server