mcp-docs-server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-docs-serversearch for transports in MCP documentation"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Docs Server
A Model Context Protocol (MCP) server for searching MCP protocol documentation. Built with TypeScript using the official MCP SDK.
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
Quick Start (Recommended)
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-serverThen 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 stringk(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-serverDevelopment
Clone the repository for local development:
git clone https://github.com/praveenc/mcp-docs-server.git
cd mcp-docs-server
npm installCommands
# 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:devLocal 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 validationSearch 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 toolsfetch_mcp_docA
Fetch full document content by URL from MCP protocol documentation. Only URLs from modelcontextprotocol.io are allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | Document URI (http/https URL from modelcontextprotocol.io) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string (e.g., 'tool input schema', 'stdio transport') | |
| k | No | Maximum number of results to return |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
fetch_mcp_doc - First observed
search_mcp_docs
TDQS
The two tools have clearly distinct purposes: one fetches a specific document by URL, the other searches across documents. No overlap in functionality.
Both tool names follow a consistent verb_noun pattern (fetch_mcp_doc, search_mcp_docs) and use snake_case uniformly.
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.
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
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
Search and read the official MintMCP documentation, the enterprise MCP gateway.
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Search and fetch AgendaForge public documentation and marketing content. No authentication needed.
Political Comms documentation MCP server: search docs, query the docs filesystem. No auth.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides 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.23MIT
- AlicenseNot gradedqualityDmaintenanceProvides semantic search over markdown documentation using RAG, allowing natural language queries and integration with MCP clients.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to intelligently search and reference documentation using hybrid semantic + keyword search via MCP protocol.-
- AlicenseAqualityBmaintenanceMCP 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).218Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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