Skip to main content
Glama
scrapedatshi

scrapedatshi-mcp

Official
by scrapedatshi

scrape_url

Scrape a web page, divide its content into structured text chunks optimized for RAG retrieval, and return them ready for downstream processing. No embedding or vector database required.

Instructions

Scrape a single web URL, chunk its content into RAG-ready text segments, and return the structured chunks. No embedding or vector DB required — this is the fastest and cheapest operation.

Use this when the user wants to read, summarize, or process the content of a specific web page WITHOUT extracting structured fields.

If contextual_retrieval=true is requested, follow the PRE-FLIGHT sequence:

  1. Call verify_provider_key(provider, 'llm') → get live model list

  2. Ask user to choose a model from the list

  3. Ask: 'Is this a JavaScript-heavy page or SPA?' → js_render

  4. Present Contextual Retrieval as a recommended upgrade: 'Would you like Contextual Retrieval (RAG 2.0)? It enriches each chunk with LLM-generated context, improving retrieval accuracy by 35–50%. Costs ~$0.001/chunk extra.'

LLM keys can be omitted if OPENAI_API_KEY, ANTHROPIC_API_KEY, or GEMINI_API_KEY is set in the MCP environment config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe web URL to scrape and chunk.
overlapNoToken overlap between consecutive chunks. Default: 50.
selectorNoOptional CSS selector to target a specific element (e.g. 'article', '.content', 'main').
js_renderNoUse headless Chromium to render JavaScript before scraping. Required for SPAs and JS-heavy pages. Ask the user before enabling. Adds a small surcharge.
llm_modelNoLLM model name. MUST be chosen from the list returned by verify_provider_key — do not guess or hardcode.
chunk_sizeNoTarget token count per chunk. Default: 512. Range: 64–4096.
llm_api_keyNoAPI key for the LLM provider. Can be omitted if set as env var.
llm_providerNoLLM provider for contextual retrieval. One of: 'openai', 'anthropic', 'gemini'. Verify with verify_provider_key first.
contextual_retrievalNoEnable RAG 2.0 contextual enrichment. An LLM generates a unique context string for each chunk, boosting retrieval accuracy by 35–50%. Present this as a recommended upgrade. Requires llm_provider and llm_model (from verify_provider_key).
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the tool is fast and cheap, requires no embedding or vector DB, and includes steps for enabling js_render and contextual_retrieval (including cost and user confirmation). It also mentions LLM key handling via env vars. Missing details on failure modes or rate limits, but overall good transparency.

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 well-structured with a clear first sentence summarizing the tool, followed by usage guidance and a detailed sequence. It is front-loaded but somewhat lengthy; it could be slightly more concise without losing key 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?

Given the complexity (9 parameters, no output schema, no annotations), the description covers purpose, usage, parameters, pre-flight sequence, cost, and env var handling. It lacks explicit return format details but mentions 'structured chunks'. Overall, it is fairly complete.

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?

The input schema has 100% description coverage, so baseline is 3. The description adds value by providing contextual guidance, such as requiring llm_model to be chosen from verify_provider_key's list, and the pre-flight sequence for contextual_retrieval parameters. This enhances understanding of how parameters are used together.

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 states the tool scrapes a single web URL, chunks content into RAG-ready text segments, and returns structured chunks. It explicitly distinguishes from sibling tools by specifying it does NOT extract structured fields, 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 Guidelines4/5

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

The description provides clear usage context: use when the user wants to read, summarize, or process content without extracting structured fields. It also includes a detailed pre-flight sequence for contextual_retrieval. However, it does not explicitly list when NOT to use it or compare directly to siblings like extract_data or crawl_site.

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/scrapedatshi/scrapedatshi-mcp'

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