Skip to main content
Glama
wolfyy970

Docs Fetch MCP Server

by wolfyy970

Docs Fetch MCP Server

A Bun-based Model Context Protocol (MCP) server for fetching documentation pages and bounded documentation crawls.

The server exposes one MCP tool, fetch_doc_content. It fetches a root URL, extracts readable Markdown, ranks links, and can crawl linked pages within explicit depth, page, timeout, and scope limits. Results are returned as structured JSON with crawl metadata, page content, ranked links, truncation flags, and per-page errors.

Features

  • Fast static fetch path with axios

  • Optional Puppeteer rendering for client-rendered or thin pages

  • Markdown extraction with headings, lists, code blocks, tables, blockquotes, and links

  • Real crawl depth semantics:

    • depth: 1 returns only the root page

    • depth: 2 includes direct child links

    • depth: 3 includes grandchildren, up to the maximum of 5

  • URL normalization before dedupe: fragments, tracking params, default ports, and trailing slash duplicates are removed

  • Crawl scoping by same origin and optional pathPrefix

  • Bounded maxPages, maxConcurrency, global timeout, per-page timeout, and per-page content truncation

  • Partial results with explicit per-page failures

  • Runtime argument validation shared with the advertised tool schema

Related MCP server: Fetch MCP Server

Requirements

  • Bun >=1.3.0

  • Puppeteer's browser installation if render is auto or always

This project uses Bun for dependency management, runtime execution, builds, and tests.

Installation

bun install
bun run build

Configure your MCP client:

{
  "mcpServers": {
    "docs-fetch": {
      "command": "bun",
      "args": ["/path/to/docs-fetch-mcp/build/index.js"]
    }
  }
}

For local development without a build:

{
  "mcpServers": {
    "docs-fetch": {
      "command": "bun",
      "args": ["/path/to/docs-fetch-mcp/src/index.ts"]
    }
  }
}

Tool

fetch_doc_content

Fetch one URL and optionally crawl linked pages.

Parameters:

Name

Type

Default

Limit

Description

url

string

required

HTTP/HTTPS only

Root URL to fetch.

depth

number

1

1 to 5

Link distance from the root.

maxPages

number

10

1 to 50

Maximum pages returned across the crawl.

maxConcurrency

number

3

1 to 8

Maximum pages fetched at once.

timeoutMs

number

45000

5000 to 120000

Global crawl timeout.

perPageTimeoutMs

number

10000

1000 to 60000

Per-page fetch timeout.

render

string

auto

auto, always, never

Browser rendering strategy.

sameOrigin

boolean

true

n/a

Restrict crawled links to the same origin.

pathPrefix

string

omitted

n/a

Optional path prefix crawl scope, such as /docs.

contentLimit

number

12000

1000 to 50000

Markdown characters per page before truncation.

includeLinks

boolean

true

n/a

Include ranked links in returned page objects.

Example request:

{
  "url": "https://example.com/docs",
  "depth": 2,
  "maxPages": 8,
  "pathPrefix": "/docs",
  "render": "auto"
}

Response shape:

{
  "rootUrl": "https://example.com/docs",
  "normalizedRootUrl": "https://example.com/docs",
  "explorationDepth": 2,
  "maxPages": 8,
  "pagesExplored": 3,
  "pagesFailed": 1,
  "timedOut": false,
  "durationMs": 1234,
  "crawl": {
    "sameOrigin": true,
    "pathPrefix": "/docs",
    "maxConcurrency": 3,
    "render": "auto",
    "perPageTimeoutMs": 10000
  },
  "content": [
    {
      "url": "https://example.com/docs",
      "finalUrl": "https://example.com/docs",
      "depth": 0,
      "status": 200,
      "title": "Documentation",
      "description": "Example documentation",
      "canonicalUrl": "https://example.com/docs",
      "headings": ["Documentation"],
      "content": "# Documentation\n\n...",
      "contentLength": 2400,
      "truncated": false,
      "fetchedWith": "http",
      "links": [
        {
          "url": "https://example.com/docs/api",
          "text": "API reference",
          "score": 18.5,
          "internal": true
        }
      ]
    }
  ],
  "errors": [
    {
      "url": "https://example.com/docs/missing",
      "depth": 1,
      "error": "Request failed with status code 404",
      "status": 404
    }
  ]
}

Crawl Behavior

  • Crawling is breadth-first.

  • URLs are normalized before dedupe and enqueue.

  • sameOrigin: true rejects links whose origin differs from the normalized root URL.

  • pathPrefix further restricts links to a path prefix on the root origin.

  • includeLinks: false hides links in returned page objects but does not disable link discovery for crawling.

  • render: "never" uses only the HTTP fetch path.

  • render: "always" uses Puppeteer for every fetched page.

  • render: "auto" tries HTTP first, then uses Puppeteer when HTTP fails or extracted content is very thin.

  • Browser fallback currently preserves the rendered response status and extracts the page body even for non-2xx pages.

Architecture

src/index.ts                         CLI entrypoint
src/server.ts                        MCP server wiring and tool registration
src/config/tool-options.ts           Shared tool schema/default/range metadata
src/tool/fetch-doc-content-args.ts   Runtime argument validation
src/crawler/docs-crawler.ts          Crawl orchestration and queue management
src/crawler/page-fetcher.ts          HTTP fetch, browser fallback, extraction coordination
src/browser/browser-manager.ts       Reusable Puppeteer browser/page handling
src/content/content-extractor.ts     Page metadata/content extraction facade
src/content/main-content-selector.ts Main content selection
src/content/link-extractor.ts        Link normalization, dedupe, and ranking
src/content/markdown-renderer.ts     HTML-to-Markdown rendering
src/content/text-cleanup.ts          Shared text normalization helpers
src/utils/url.ts                     URL normalization and scope utilities
src/types/index.ts                   Shared TypeScript types

The MCP schema and runtime option normalization share the same metadata source in src/config/tool-options.ts. Keep new options there first, then wire behavior through validation and crawler options.

Development

bun install
bun run dev
bun run test
bun run typecheck
bun run build

Scripts:

  • bun run dev: run the MCP server from TypeScript source.

  • bun run test: run Bun tests under src.

  • bun run typecheck: run TypeScript with --noEmit.

  • bun run build: emit build/index.js with a Bun shebang.

  • bun run start: run the built MCP server.

Testing

Tests are colocated with the modules they cover:

  • src/crawler/docs-crawler.test.ts: crawl depth, scoping, failures, and link visibility.

  • src/crawler/page-fetcher.test.ts: fetch/render fallback characterization.

  • src/content/content-extractor.test.ts: Markdown extraction and truncation.

  • src/tool/fetch-doc-content-args.test.ts: boundary validation and schema/default sync.

  • src/utils/url.test.ts: URL normalization and scope helpers.

When changing behavior, add or update characterization tests first. For refactors, keep bun run test, bun run typecheck, and bun run build green.

Notes

  • Use render: "never" for fast static documentation crawls and tests.

  • Use pathPrefix for documentation sites that share a domain with marketing pages, blogs, or apps.

  • Puppeteer browser installation can be skipped only if callers use render: "never".

  • The custom Markdown renderer is intentionally covered by characterization tests; preserve output compatibility unless making an explicit behavior change.

License

MIT

Available Tools

1 tool
fetch_doc_contentC

Fetch web page content with the ability to explore linked pages up to a specified depth

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoMaximum depth of directory/link exploration (default: 1)
urlYesURL of the web page to fetch

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality (fetching and exploring links) but lacks details on permissions, rate limits, error handling, or what the response looks like (e.g., format, size limits). This leaves significant gaps for a tool that interacts with external web resources.

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 a single, efficient sentence that clearly states the tool's purpose and key feature (exploring linked pages). It is front-loaded with the main action and includes no redundant information, making it highly concise and well-structured.

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

Completeness2/5

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

Given the complexity of fetching web content with link exploration, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or response format, which are critical for effective tool use in this context.

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?

The schema description coverage is 100%, so the schema already documents both parameters ('url' and 'depth') with descriptions and constraints. The description adds minimal value by implying the depth parameter relates to link exploration, but it doesn't provide additional syntax or format details beyond what the schema specifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('fetch') and resource ('web page content'), and it adds valuable context about exploring linked pages. However, since there are no sibling tools mentioned, it doesn't need to differentiate from alternatives, which keeps it from reaching a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It mentions the ability to explore linked pages up to a specified depth, but this is more about functionality than usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedfetch_doc_content

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'fetch_doc_content' has a clear and distinct purpose, making it impossible for an agent to confuse it with other tools.

Naming Consistency5/5

Since there is only one tool, it inherently follows a consistent naming pattern. The tool name 'fetch_doc_content' uses a verb_noun structure, which is clear and predictable, and there are no other tools to cause inconsistency.

Tool Count2/5

A single tool is too few for a server named 'Docs Fetch MCP Server', which implies a domain involving document fetching and exploration. While the tool is well-described, one tool feels thin and insufficient for comprehensive operations like managing fetched content or handling different document types, limiting the server's utility.

Completeness2/5

The tool surface is severely incomplete for the inferred domain of document fetching. It only provides a fetch operation with depth control, missing essential functions such as listing fetched documents, updating or deleting cached content, searching within documents, or handling errors, which are necessary for a complete workflow.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides AI agents and coding assistants with advanced web crawling and RAG capabilities, allowing them to scrape websites and leverage that knowledge through various retrieval strategies.
    2
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Enables LLMs to retrieve and process web content by fetching URLs and converting HTML to markdown format. Supports chunked reading of large pages and can access both public websites and local networks.
    1
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables crawling and extracting clean content from documentation websites with optional LLM-powered analysis for intelligent summaries, code example extraction, and content classification.
    -
  • A
    license
    A
    quality
    D
    maintenance
    Enables LLMs to fetch and process web content by converting HTML into markdown for easier consumption. It supports chunked reading via pagination and provides configuration options for robots.txt compliance and proxy usage.
    1
    MIT

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/wolfyy970/docs-fetch-mcp'

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