Skip to main content
Glama

MCP Docs Server

A simple way to make your documentation files available to AI assistants like Claude.

What Does This Do?

Think of this as a library catalog for your documentation. You have a bunch of markdown files (.md files) with documentation, guides, or notes. This server:

  1. Finds all your markdown files automatically

  2. Makes them available to AI tools through something called MCP (Model Context Protocol)

  3. Lets AI assistants search through and read your documentation

It's like giving Claude or other AI tools a filing cabinet of your documentation that they can open and read whenever they need information.

Related MCP server: docubridge

How It Works (Simple Explanation)

  1. You put documentation files in folders - Just save your .md files in organized folders

  2. The server finds them automatically - No need to manually register each file

  3. AI can read them - AI assistants can now access and search your documentation

Real Example

Let's say you have documentation for "Service 1" with these files:

  • user-functions.md - How user features work

  • call-functions.md - How calling features work

  • calendar-functions.md - How calendar features work

You would organize them like this:

docs/
└── service-1/
    ├── user-functions.md
    ├── call-functions.md
    └── calendar-functions.md

That's it! The server will automatically find these files and make them available as:

  • docs://service-1/user-functions

  • docs://service-1/call-functions

  • docs://service-1/calendar-functions

Quick Start (Step by Step)

Step 1: Install Python Requirements

You need Python 3.10 or newer and uv (a Python package manager) installed.

Install uv if you don't have it:

curl -LsSf https://astral.sh/uv/install.sh | sh

Then install the required package:

uv pip install mcp

Step 2: Add Your Documentation Files

Put your markdown files in the docs/ folder. Organize them in subfolders by topic or service:

docs/
├── service-1/
│   ├── user-functions.md
│   ├── call-functions.md
│   └── calendar-functions.md
├── service-2/
│   └── api-guide.md
└── getting-started/
    └── introduction.md

The subfolder name (like service-1) becomes the category.

Step 3: Connect to Claude Code

The easiest way is to use the Claude Code CLI. From this project folder, run:

claude mcp add --transport stdio docs -- uv run python /full/path/to/mcp-example/src/mcp_docs_server.py

Replace /full/path/to/mcp-example with your actual project path.

Verify it's connected:

claude mcp list

You should see: docs: ... - ✓ Connected

That's it! Claude Code can now access your documentation.

Adding New Documentation

To add new documentation at any time:

  1. Create a new .md file in the appropriate folder under docs/

  2. That's it! The server finds new files automatically

For example, to add documentation for a new service:

docs/
└── service-3/          # Create new folder
    └── setup.md        # Add your documentation file

No need to restart the server or change any code.

Using with Claude Code

If you're using Claude Code (the CLI tool), follow Step 3 above. The server is already configured and running!

You can now ask Claude Code questions like:

  • "List all available docs resources"

  • "Read the service-1/user-functions documentation"

  • "Search the docs for authentication"

Claude Code will automatically access your documentation files.

Managing the Server

Check if the server is connected:

claude mcp list

Remove the server:

claude mcp remove docs

Re-add the server if needed:

claude mcp add --transport stdio docs -- uv run python /full/path/to/mcp-example/src/mcp_docs_server.py

Connecting to Claude Desktop

To make your documentation available in Claude Desktop:

  1. Find your Claude Desktop config file:

    • Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%/Claude/claude_desktop_config.json

  2. Open the file and add this (replace /path/to/mcp-example with your actual folder path):

{
  "mcpServers": {
    "docs": {
      "command": "python",
      "args": ["/path/to/mcp-example/src/mcp_docs_server.py"]
    }
  }
}

Learn More

Available Tools

1 tool
search_docsC

Search through all documentation files for a given query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query to find in documentation
categoryNoOptional category to filter search results

TDQS

C2.9/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 the full burden of behavioral disclosure. It mentions searching through 'all documentation files' but fails to describe important traits like pagination, result limits, authentication requirements, error handling, or performance characteristics. This leaves significant gaps in understanding how the tool behaves.

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 directly states the tool's function without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of files, snippets, metadata), how results are structured, or any limitations. For a search tool with no structured output documentation, this leaves critical gaps in understanding the tool's full 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 input schema has 100% description coverage, clearly documenting both parameters. The description adds minimal value beyond the schema by implying the scope ('all documentation files') but doesn't provide additional syntax, format details, or examples. This meets the baseline for high schema coverage.

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 ('search') and resource ('documentation files'), making it immediately understandable. However, since there are no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, which prevents a perfect score of 5.

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 contextual constraints. It simply states what the tool does without any usage instructions or exclusions, which is insufficient for effective agent decision-making.

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 updatev0.1.0
    • First observedsearch_docs

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'search_docs' has a clear and distinct purpose that cannot be confused with any other tool in the set.

Naming Consistency5/5

The single tool follows a consistent verb_noun pattern with 'search_docs'. Since there is only one tool, the naming is inherently consistent with no deviations or mixed conventions to evaluate.

Tool Count2/5

A single tool is too few for a server named 'MCP Docs Server', which suggests a documentation-focused domain. This minimal set lacks basic operations like retrieving, creating, updating, or deleting documents, making it feel thin and incomplete for the apparent scope.

Completeness2/5

The tool set is severely incomplete for a documentation server. While 'search_docs' provides a useful function, there are obvious gaps such as no CRUD operations (e.g., get_doc, create_doc, update_doc, delete_doc) or other lifecycle management tools, which will likely cause agent failures in handling documentation tasks.

Maintenance

ActivityInactive
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
    A
    quality
    A
    maintenance
    Enables AI agents to discover, read, search, and install Markdown-based knowledge (rules, skills, workflows) from a local directory via MCP tools.
    12
    29
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    MCP server that exposes one or more documentation folders (Markdown, MDX, TXT) to AI agents, enabling listing, reading, and searching of documentation files.
    -

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/reflex-dev/mcp-example'

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