Skip to main content
Glama
herring101

Docs-MCP

by herring101
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

docs-mcp

Test License: MIT

ユーザーが設定したドキュメントを効率的に検索・参照できるMCPサーバーです。

前提条件

docs-mcpを使用するにはuvが必要です。uvはPythonパッケージとプロジェクト管理のための高速なツールです。

uvのインストール

macOS/Linux

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

Windows

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Homebrew (macOS)

brew install uv

pipでのインストール

pip install uv

詳細はuvのインストールガイドを参照してください。

Related MCP server: RAG Docs MCP Server

主な機能

  • 📄 ドキュメント一覧表示 - すべてのドキュメントとその説明を一覧表示

  • 🔍 grep検索 - 正規表現を使った高速な全文検索

  • 🧠 セマンティック検索 - OpenAI Embeddingsを使った意味的な類似検索（要設定）

  • 📝 ドキュメント取得 - 指定したドキュメントの全内容を取得

  • 📖 ページネーション対応 - 大きなドキュメントをページ単位で効率的に閲覧

クイックスタート

🚀 最もシンプルな使い方

既存のドキュメントがあるプロジェクトですぐに使えます：

# ドキュメント管理用フォルダを作成
mkdir -p my-docs/docs
# ドキュメントファイルをdocs/に配置

Claude Desktopの設定（claude_desktop_config.json）に追加：

{
  "mcpServers": {
    "docs": {
      "command": "uvx",
      "args": ["docs-mcp"],
      "env": {
        "DOCS_BASE_DIR": "/path/to/my-docs"
      }
    }
  }
}

重要: docs-mcpは常にプロジェクトフォルダ内のdocs/ディレクトリを参照します。

セットアップガイド

方法1: 既存のドキュメントで使う

手元にあるMarkdownやテキストファイルをすぐに検索可能にできます：

  1. プロジェクトフォルダを作成

  2. docs/ディレクトリにドキュメントを配置

  3. Claude Desktopの設定を更新

✅ メリット: コマンドライン操作不要、すぐに使える
❌ デメリット: インポートツールが使えない

方法2: インポートツールを活用する

GitHubやWebサイトからドキュメントを取り込む場合：

# ドキュメント管理プロジェクトをセットアップ
uv init my-docs
cd my-docs
uv add docs-mcp

# GitHubからドキュメントをインポート
uv run docs-mcp-import-github https://github.com/owner/repo

# 特定のディレクトリだけインポート
uv run docs-mcp-import-github https://github.com/owner/repo/tree/main/docs -o project-docs

✅ メリット: 外部ドキュメントを簡単に取り込める
❌ デメリット: uvのセットアップが必要

高度な機能

🧠 セマンティック検索を有効にする

OpenAI Embeddingsを使った意味的な検索を追加できます：

# 1. OpenAI APIキーを設定
export OPENAI_API_KEY="sk-..."

# 2. メタデータを生成（プロジェクトディレクトリで実行）
uv run docs-mcp-generate-metadata

Claude Desktopの設定でAPIキーを追加：

{
  "mcpServers": {
    "docs": {
      "command": "uvx",
      "args": ["docs-mcp"],
      "env": {
        "DOCS_BASE_DIR": "/path/to/my-docs",
        "OPENAI_API_KEY": "sk-..."  // セマンティック検索が有効になる
      }
    }
  }
}

詳細な設定オプション

{
  "mcpServers": {
    "docs": {
      "command": "uvx",
      "args": ["docs-mcp"],
      "env": {
        "DOCS_BASE_DIR": "/path/to/my-docs",
        "OPENAI_API_KEY": "sk-...",
        "DOCS_FOLDERS": "api,guides,examples",  // 特定のフォルダのみ読み込み
        "DOCS_FILE_EXTENSIONS": ".md,.mdx,.txt,.py",  // 対象ファイル拡張子を制限
        "DOCS_MAX_CHARS_PER_PAGE": "5000",  // 1ページあたりの最大文字数
        "DOCS_LARGE_FILE_THRESHOLD": "10000"  // 自動ページネーション閾値（文字数）
      }
    }
  }
}

利用可能なツール

MCPツール（Claude内で使用）

  • list_docs - ドキュメント一覧表示

  • get_doc - ドキュメント内容取得（ページネーション対応）

  • grep_docs - 正規表現検索

  • semantic_search - 意味的な類似検索（要OpenAI APIキー）

📖 ページネーション機能の使い方

大きなドキュメント（15,000文字超）では自動的に1ページ目が表示され、ページネーションの使用が推奨されます：

# 基本的な使い方（従来通り）
get_doc("path/to/document.md")  # 小さなファイルは全文表示、大きなファイルは自動的に1ページ目

# ページネーション使用
get_doc("path/to/document.md", page=1)  # 1ページ目（デフォルト10,000文字まで）
get_doc("path/to/document.md", page=2)  # 2ページ目
get_doc("path/to/document.md", page=3)  # 3ページ目

ページネーション出力例：

📄 Document: pytest/reference/plugin_list.rst
📖 Page 2/5 (chars 10,001-20,000/45,123)
📏 Lines 285-570/1,324 | Max chars per page: 10,000
⚠️  Large document auto-paginated. To see other pages:
💡 get_doc('pytest/reference/plugin_list.rst', page=3)  # Next page
💡 get_doc('pytest/reference/plugin_list.rst', page=5)  # Last page
────────────────────────────────────────────────────────────

[ドキュメントの内容]

コマンドラインツール（ドキュメント管理用）

  • docs-mcp-import-url - Webサイトからドキュメントをインポート

  • docs-mcp-import-github - GitHubリポジトリからインポート

  • docs-mcp-generate-metadata - セマンティック検索用メタデータを生成

必要な環境

  • uv - Python環境とパッケージ管理ツール（uvxコマンドで実行）

  • Python 3.12以上（uvが自動的に管理）

  • OpenAI APIキー（セマンティック検索を使用する場合のみ）

詳細設定

環境変数

変数名

説明

デフォルト値

OPENAI_API_KEY

OpenAI APIキー（セマンティック検索用）

なし

DOCS_BASE_DIR

ドキュメントプロジェクトのルート

現在のディレクトリ

DOCS_FOLDERS

読み込むフォルダ（カンマ区切り）

docs/内の全フォルダ

DOCS_FILE_EXTENSIONS

対象ファイル拡張子

デフォルトの拡張子リスト

DOCS_MAX_CHARS_PER_PAGE

ページネーションの1ページあたりの最大文字数

10000

DOCS_LARGE_FILE_THRESHOLD

大きなファイルの自動ページネーション閾値（文字数）

15000

サポートされるファイル形式

  • ドキュメント: .md, .mdx, .txt, .rst, .asciidoc, .org

  • 設定: .json, .yaml, .yml, .toml, .ini, .cfg, .conf, .xml, .csv

  • コード: .py, .js, .jsx, .ts, .tsx, .java, .cpp, .c, .h, .go, .rs, .rb, .php

  • スクリプト: .sh, .bash, .zsh, .ps1, .bat

  • Web: .html, .css, .scss, .vue, .svelte

  • その他: .sql, .graphql, .proto, .ipynb, .dockerfile, .gitignore

ディレクトリ構造の例

my-docs/
└── docs/
    ├── api/
    │   └── reference.md
    ├── guides/
    │   └── quickstart.md
    └── examples/
        └── sample.py

開発者向け情報

ソースからの開発

git clone https://github.com/herring101/docs-mcp.git
cd docs-mcp
uv sync

# テスト
uv run pytest tests/

# ビルド
uv build

コマンドラインツールの詳細

docs-mcp-import-url

Webサイトからドキュメントをインポート

docs-mcp-import-url https://example.com/docs --output-dir imported

オプション:

  • --output-dir, -o: 出力ディレクトリ名（docs/配下に保存）

  • --depth, -d: クロール深度

  • --include-pattern, -i: 含めるURLパターン

  • --exclude-pattern, -e: 除外するURLパターン

  • --concurrent, -c: 同時ダウンロード数

docs-mcp-import-github

GitHubリポジトリからインポート。ブランチを指定しない場合はデフォルトブランチ（main/master等）を自動検出します。

# リポジトリ全体をインポート
docs-mcp-import-github https://github.com/owner/repo

# 特定のパスのみインポート（docs/importedに保存される）
docs-mcp-import-github https://github.com/owner/repo/tree/main/docs --output-dir imported

# masterブランチのリポジトリも自動検出
docs-mcp-import-github https://github.com/Cysharp/UniTask

オプション:

  • --output-dir, -o: 出力ディレクトリ名（docs/配下に保存。デフォルト: リポジトリ名）

docs-mcp-generate-metadata

セマンティック検索用のメタデータを生成

export OPENAI_API_KEY="your-key"
docs-mcp-generate-metadata

セキュリティ

  • APIキーは環境変数で管理

  • DOCS_FOLDERSとDOCS_FILE_EXTENSIONSでアクセスを制限

  • 外部ネットワークアクセスはOpenAI APIのみ

トラブルシューティング

Claude Desktopに表示されない

  • 設定ファイルの構文を確認

  • DOCS_BASE_DIRが正しいパスを指しているか確認

  • Claude Desktopを再起動

セマンティック検索が動作しない

  • OPENAI_API_KEYが設定されているか確認

  • docs-mcp-generate-metadataを実行したか確認

インポートが失敗する

  • URL/GitHubリポジトリがアクセス可能か確認

  • ネットワーク接続を確認

ライセンス

MIT License - LICENSE

コントリビューション

CONTRIBUTING.mdを参照してください。

Available Tools

4 tools
get_docA

指定したドキュメントの内容を取得（ページネーション対応）

Args:
    path: ドキュメントのファイルパス
    page: ページ番号（1から開始、Noneの場合は全文取得）
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
pageNo

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It explains pagination behavior (page number starting at 1, None for full content), adding value beyond the schema. However, it does not mention other traits like permissions or rate limits, but for a simple read tool, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two brief lines for parameters. It is front-loaded with the main purpose and then key parameter details. Could be slightly more structured, but no extraneous content.

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 (2 parameters, no output schema), the description covers the main behavior (reading content with pagination). It could mention the return format, but overall it is adequate for an agent to invoke correctly.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates by explaining the 'path' parameter as file path and 'page' as page number with special handling for None. This adds meaning beyond the schema's minimal type information.

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?

The description clearly states the tool retrieves document content with pagination support, using a specific verb ('get') and resource ('document content'). This distinguishes it from siblings like grep_docs, list_docs, and semantic_search.

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 (e.g., grep_docs, semantic_search). It only mentions pagination but does not specify contexts or exclusions.

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

grep_docsA

ドキュメント内をgrepで検索

Args:
    pattern: 検索パターン（正規表現対応）
    ignore_case: 大文字小文字を無視するか（デフォルト: True）
ParametersJSON Schema
NameRequiredDescriptionDefault
patternYes
ignore_caseNo

TDQS

A3.8/5.0
Behavior3/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. It discloses the search behavior, regex support, and case sensitivity option, but does not mention return format or any side effects. Adequate but not rich.

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?

Very concise: two sentences for purpose and an Args list for parameters. No wasted words, front-loaded with the main action.

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?

For a simple two-parameter tool with no output schema, the description covers the essential behavior and parameter meanings. Could optionally mention what is returned, but not a major gap.

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

Parameters4/5

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

Schema coverage is 0%, but the description adds meaningful explanations: pattern is 'search pattern (regex supported)' and ignore_case is 'whether to ignore case (default: True)'. This goes beyond the schema's type/default fields.

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?

The description clearly states 'Search inside documents using grep' and mentions regex support. It contrasts with sibling tools like get_doc, list_docs, and semantic_search by specifying a regex-based search.

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 guidance on when to use this tool versus alternatives like semantic_search. No exclusion criteria or prerequisites are provided.

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

list_docsA

所持しているドキュメントの一覧を取得

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations exist; the description only says 'get a list,' implying a read operation, but lacks details like limits, ordering, or whether it returns all documents.

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?

A single concise sentence that immediately conveys the tool's purpose with no unnecessary words.

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?

While adequate for a simple list tool with no parameters and no output schema, it lacks contextual details like scope or constraints, making it minimally complete.

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

Parameters4/5

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

Input schema has 0 parameters (100% coverage trivially), and the description adds sufficient meaning by describing the action. No extra parameter info needed.

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?

The description clearly states the action (get a list) and resource (documents), and distinguishes from siblings like get_doc (single) and grep_docs/semantic_search (search).

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 vs alternatives, such as grep_docs or semantic_search, leaving the agent to infer from names.

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. 4 tool updatesv1.0.0
    • First observedget_doc
    • First observedgrep_docs
    • First observedlist_docs
    • First observedsemantic_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool serves a distinct purpose: listing documents, retrieving content, regex search, and semantic search. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_doc, grep_docs, list_docs, semantic_search).

Tool Count5/5

With 4 tools, the set is well-scoped for a documentation server, covering essential operations without bloat.

Completeness5/5

The tool surface covers the full lifecycle of reading documentation: listing, retrieving, and two complementary search methods.

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

  • RAG Docs MCP Server

    gorizond
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that provides tools for retrieving and processing documentation through vector search, enabling AI assistants to augment their responses with relevant documentation context.
    17
    MIT

  • Saga

    maxinedotdev
    A
    license
    Not graded
    quality
    C
    maintenance
    A local-first MCP server for document ingestion and semantic search, providing tools to add, search, and retrieve documents, chunks, and code blocks.
    13
    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/herring101/docs-mcp'

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