docs-mcp-server

Overview Schema Source Related Servers Discussions Admin

scrape_docs

Destructive

Index documentation from a library URL to create a searchable version for a new library or release; enable replace to rebuild an existing version when needed.

Instructions

Scrape and index documentation from a URL for a library. Use this tool to index a new library or a new version. Scraping a library version that already exists is rejected unless replace is true; use refresh_version to update an existing version in place.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "library": "<library>"
    },
    "name": "scrape_docs"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Documentation root URL to scrape.
`scope`	No	Crawling boundary: 'subpages', 'hostname', or 'domain'.	subpages
`library`	Yes	Library name.
`replace`	No	Rebuild the version from scratch if it already exists. Without it, an existing version is left untouched and the request fails.
`version`	No	Library version (optional).
`maxDepth`	No	Maximum navigation depth (default: 3).
`maxPages`	No	Maximum number of pages to scrape (default: 1000).
`preserveHashes`	No	Preserve hash fragments for hash-routed SPA documentation sites.
`excludePatterns`	No	Patterns for excluding URLs during scraping. Pass one or more patterns as a comma-separated string or as an array. Commas inside { }, [ ] or ( ) are preserved; escape a literal comma with a backslash. Exclude takes precedence over include. Regex patterns must be wrapped in slashes, e.g. /pattern/.
`followRedirects`	No	Follow HTTP redirects (3xx responses).
`includePatterns`	No	Patterns for including URLs during scraping. Pass one or more patterns as a comma-separated string or as an array. Commas inside { }, [ ] or ( ) are preserved; escape a literal comma with a backslash. Regex patterns must be wrapped in slashes, e.g. /pattern/. If not set, all are included by default.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.4.1Nov 12, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true and destructiveHint=true, so the safety profile is partly covered. The description adds genuinely useful behavior: existing versions are rejected, replace rebuilds from scratch, and refresh_version is the in-place path. It does not disclose that scraping likely runs asynchronously as a job (the sibling set includes get_job_info, list_jobs, cancel_job), which is the one meaningful behavioral gap.

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?

Two sentences, front-loaded with the core action, then the constraint and the alternative. Nothing is redundant or padding, and the rejection rule is placed before the redirect to refresh_version where an agent needs it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, destructive, open-world ingestion tool with no output schema, the description covers the create-vs-update decision but leaves out what the call actually produces (job id, progress, polling) and any confirmation expectations before a destructive replace. It is adequate to choose the tool, but not fully complete for invoking and following through on it.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters like scope, maxDepth, excludePatterns and followRedirects are already fully documented in the schema. The description only echoes the replace semantics and the URL target, adding no syntax or format meaning beyond structured data. Baseline 3 is appropriate when the schema carries this much detail.

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?

States a specific verb (scrape and index), resource (documentation from a URL), and target (a library). The second sentence draws an explicit boundary against refresh_version, so an agent can distinguish the two without opening either schema.

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?

Gives explicit when-to-use guidance ('index a new library or a new version') and a when-not rule ('Scraping a library version that already exists is rejected unless replace is true'), then names the correct alternative, refresh_version, for the update case. This is a complete routing decision.

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

Deploy Server