Skip to main content
Glama
ptrken01

searxng-mcp-scraper

by ptrken01

deep_scrape

Crawl a blog to fetch every post, then download and extract text from all linked documents (PDF, DOCX, etc.) into one Markdown file.

Instructions

Discover every post on a blog, fetch each, AND download + extract every linked document (PDF/DOCX/XLSX/PPTX/CSV/JSON/XML/MD/EPUB/...).

Same discovery as `scrape_blog` (RSS/Atom first, HTML index
fallback). For every post fetched, the raw HTML is scanned for
links whose URL ends in a recognized document extension. Each
such document is downloaded (capped by
`deep_scrape_max_documents_per_blog`, 100 by default) and its
text is extracted via markitdown. The original blog post text
and every document's extracted text are all inlined into one
Markdown file at:

  {blog_scrape_output_dir}/<safe-host>_<safe-path>_<unix-ts>_deep.md

Downloaded binaries are saved alongside, under:

  {blog_scrape_output_dir}/deep_assets/

Per-post and per-document failures are noted in-band as
`- Fetch error: <code>` / `- Error: <code>` bullets, not by
aborting the whole run. The returned summary dict only carries
an `error` field when discovery itself failed (no posts).

Args:
    blog_url: Root URL of the blog (e.g. "https://blog.example.com/").

Returns:
    Small summary dict — never the file contents:
      {blog_url, output_path, assets_dir, post_count, post_count_ok,
       documents_found, documents_extracted, post_byte_count,
       document_byte_count, duration_s, discovery}
    On failure: {blog_url, error: <stable_code>, message}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctxNo
blog_urlYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries full burden and does so excellently. It discloses output file paths, per-post and per-document error handling (failures noted in-band), the document count cap, binary asset location, and the exact return dict shape including failure modes. This is far beyond typical transparency.

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?

Although lengthy, the description is well-structured with clear sections (overview, discovery, output paths, error handling, args, returns). Every sentence adds meaningful information, and the formatting (code blocks, bullet lists) aids readability without waste.

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?

The tool is complex with many behaviors, but the description fully covers inputs, outputs, error semantics, file paths, and even operational limits. The output schema is also provided, but the description redundantly explains the return dict, which is acceptable given the richness. No critical gaps exist.

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 0% description coverage, but the tool description explains the required parameter blog_url ('Root URL of the blog') and adds essential behavioral context (e.g., the deep_scrape_max_documents_per_blog env var). However, the optional 'ctx' parameter is left unexplained, and no details are given about its expected format or purpose.

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 uses specific verbs ('Discover', 'fetch', 'download + extract') and clearly identifies the resource (blog posts and linked documents). It explicitly distinguishes itself from the sibling tool scrape_blog by describing the additional document handling, making the purpose unambiguous.

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 clearly states the tool's scope ('Same discovery as scrape_blog' plus document extraction) and provides detailed behavior, but it does not explicitly say when to prefer this over scrape_blog or under what conditions to avoid it. The context strongly implies the usage distinction, but a direct when/when-not statement is missing.

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/ptrken01/searxng-mcp-scraper'

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