Skip to main content
Glama
praveenc

mcp-docs-server

by praveenc

MCP Docs Server

A Model Context Protocol (MCP) server for searching MCP protocol documentation. Built with TypeScript using the official MCP SDK.

npm version MCP Registry

Features

  • BM25 Search - High-quality ranked search using BM25 algorithm with Porter stemming

  • Fast Startup - Indexes document titles at startup, fetches content on-demand

  • Markdown Aware - Weights headers, code blocks, and links for better relevance

  • stdio Transport - Runs as a local process for easy integration

Related MCP server: Markdown RAG MCP

Installation

Add to your MCP client configuration (Claude Desktop, Kiro, etc.):

{
  "mcpServers": {
    "mcp-docs-server": {
      "command": "npx",
      "args": ["-y", "@praveenc/mcp-docs-server"]
    }
  }
}

That's it! The server will be downloaded and run automatically.

Global Install

npm install -g @praveenc/mcp-docs-server

Then configure your MCP client:

{
  "mcpServers": {
    "mcp-docs-server": {
      "command": "mcp-docs-server"
    }
  }
}

Tools

search_mcp_docs

Search MCP protocol documentation with ranked results.

Parameters:

  • query (string, required): Search query string

  • k (number, optional): Maximum results to return (default: 5). Returns fewer if fewer documents match.

Example:

{
  "query": "transports",
  "k": 5
}

Returns:

[
  {
    "url": "https://modelcontextprotocol.io/specification/2025-11-25/basic/transports.md",
    "title": "Transports",
    "score": 15.725,
    "snippet": "MCP uses JSON-RPC to encode messages..."
  }
]

fetch_mcp_doc

Fetch full document content by URL.

Parameters:

  • uri (string, required): Document URL from modelcontextprotocol.io

Example:

{
  "uri": "https://modelcontextprotocol.io/specification/2025-11-25/server/tools.md"
}

Returns:

{
  "url": "https://modelcontextprotocol.io/specification/2025-11-25/server/tools.md",
  "title": "Tools",
  "content": "# Tools\n\nTools enable servers to expose executable functionality..."
}

Testing with MCP Inspector

npx @modelcontextprotocol/inspector npx -y @praveenc/mcp-docs-server

Development

Clone the repository for local development:

git clone https://github.com/praveenc/mcp-docs-server.git
cd mcp-docs-server
npm install

Commands

# Run in development mode
npm run dev

# Run tests
npm test

# Type check
npm run typecheck

# Build
npm run build

# Test with MCP Inspector (development)
npm run inspect:dev

Local MCP Client Config (Development)

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

Architecture

src/
├── index.ts          # MCP server entry point
├── config.ts         # Configuration
├── tools/
│   └── docs.ts       # search_mcp_docs, fetch_mcp_doc
└── utils/
    ├── cache.ts      # Document caching
    ├── doc-fetcher.ts # HTTP fetching & HTML parsing
    ├── indexer.ts    # BM25 search index
    ├── logger.ts     # Logging utilities
    ├── stopwords.ts  # Stop words list
    ├── text-processor.ts # Text utilities
    └── url-validator.ts  # URL validation

Search Algorithm

The search uses BM25 (Best Matching 25) with enhancements:

  • Porter Stemming - Matches word variants (e.g., "running" → "run")

  • Bigrams - Captures phrase matches (e.g., "tool input")

  • Weighted Scoring:

    • Title matches: 3-8x boost

    • Header matches: 4x weight

    • Code blocks: 2x weight

    • Link text: 2x weight

  • Domain Term Preservation - Technical terms like "mcp", "json", "stdio" are not stemmed

License

MIT

Available Tools

2 tools
fetch_mcp_docA

Fetch full document content by URL from MCP protocol documentation. Only URLs from modelcontextprotocol.io are allowed.

ParametersJSON Schema
NameRequiredDescriptionDefault
uriYesDocument URI (http/https URL from modelcontextprotocol.io)

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only discloses the URL restriction but omits other behaviors like return format, error handling, or call limits.

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 with no wasted words. Front-loaded with the core purpose and constraint.

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 a simple fetch tool, the description covers purpose and constraint, but lacks information about the return format (e.g., plain text, HTML) and potential errors.

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 input schema already describes the parameter thoroughly ('Document URI (http/https URL from modelcontextprotocol.io)'), and the description repeats the restriction without adding new semantic value beyond the schema.

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?

Description clearly states the action ('Fetch') and the resource ('full document content by URL'), and includes a specific constraint ('Only URLs from modelcontextprotocol.io are allowed') that distinguishes it from the sibling tool 'search_mcp_docs'.

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

Usage Guidelines3/5

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

The description implies when to use (have a URL, need content) but does not explicitly say when not to use or mention the alternative 'search_mcp_docs'.

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

search_mcp_docsA

Search MCP protocol documentation with ranked results. Uses BM25 ranking with Porter stemming for high-quality search.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query string (e.g., 'tool input schema', 'stdio transport')
kNoMaximum number of results to return

TDQS

A3.6/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the use of BM25 ranking with Porter stemming, which adds behavioral insight beyond a generic search. However, it omits any mention of destructive actions, auth requirements, or rate limits. For a read-only search tool, this is acceptable but not comprehensive.

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?

Concise two-sentence description. Front-loaded with the purpose, followed by a brief technical detail. Every sentence serves a purpose with no waste.

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 tool's simplicity (two parameters, no nested objects), the description adequately covers its purpose and key feature. It lacks details on the scope of documentation (e.g., which version), but given sibling tools, this is implicitly clear.

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 coverage is 100% with descriptive parameter definitions. The description adds no additional meaning beyond what the schema already provides for query and k. Baseline of 3 is appropriate since the schema does the heavy lifting.

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?

Description clearly states the verb 'search' and the resource 'MCP protocol documentation'. It effectively distinguishes from the sibling tool 'fetch_mcp_doc' by implying this tool provides ranked results for searching, while the sibling likely fetches a specific document.

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?

No explicit guidance on when to use search vs. fetch_mcp_doc, nor any conditions for using this tool. The description only mentions ranking behavior but does not set context for usage or alternatives.

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. 2 tool updatesv0.1.0
    • First observedfetch_mcp_doc
    • First observedsearch_mcp_docs

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one fetches a specific document by URL, the other searches across documents. No overlap in functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (fetch_mcp_doc, search_mcp_docs) and use snake_case uniformly.

Tool Count3/5

With only two tools, the server is minimal but still covers the core operations of searching and fetching documentation. However, it feels slightly thin for a documentation server.

Completeness3/5

The server allows searching and fetching full documents, but lacks operations like listing all available documents or browsing by category, which are common in documentation servers.

Maintenance

ActivityInactive
ResponsivenessNo issues

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
    A
    quality
    C
    maintenance
    Provides searchable access to official MCP protocol specification and FastMCP framework documentation, helping developers build correct MCP servers by querying live documentation with BM25 full-text search.
    2
    3
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides semantic search over markdown documentation using RAG, allowing natural language queries and integration with MCP clients.
    1
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to intelligently search and reference documentation using hybrid semantic + keyword search via MCP protocol.
    -
  • A
    license
    A
    quality
    B
    maintenance
    MCP server for the StitchAPI docs: search_docs (hybrid BM25+vector) + get_doc. Local/offline npm package (@stitchapi/docs-mcp, docs bundled, no per-query network) and a hosted Streamable-HTTP server (stitchapi.dev/api/mcp).
    2
    18
    Apache 2.0

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/praveenc/mcp-docs-server'

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