Docs MCP Server
ドキュメント MCP サーバー
このプロジェクトは、 Probeを搭載した柔軟な Model Context Protocol (MCP) サーバーを提供し、ドキュメントやコードベースを AI アシスタントで検索できるように設計されています。
Git リポジトリまたはフォルダーをポイントするだけで、コードやドキュメントとチャットできます。
npx -y @buger/docs-mcp@latest --gitUrl https://github.com/buger/probeユースケース:
**任意の GitHub リポジトリとチャット:**サーバーをパブリックまたはプライベートの Git リポジトリにポイントして、そのコンテンツに関する自然言語クエリを有効にします。
**ドキュメントの検索:**プロジェクトのドキュメント (ローカル ディレクトリまたは Git から) を統合して簡単に検索できるようにします。
**カスタム MCP サーバーの構築:**このプロジェクトをテンプレートとして使用して、特定のドキュメント セットやコードベースに合わせてカスタマイズされた独自の公式 MCP サーバーを作成します。
コンテンツソース(ドキュメントまたはコード)は、 npm run buildステップでパッケージに事前にビルドすることも、ローカルディレクトリまたは Git リポジトリを使用して実行時に動的に設定することもできます。デフォルトでは、自動更新を有効にせずにgitUrlを使用すると、サーバーは起動を高速化するために.tar.gzアーカイブをダウンロードします。完全な Git クローンは、 autoUpdateIntervalが 0 より大きい場合にのみ使用されます。
特徴
Probe を搭載: Probe検索エンジンを活用して、効率的で関連性の高い結果を取得します。
**柔軟なコンテンツ ソース:**特定のローカル ディレクトリを含めるか、Git リポジトリのクローンを作成します。
**事前ビルドコンテンツ:**オプションで、ドキュメント/コード コンテンツをパッケージに直接バンドルします。
**動的構成:**構成ファイル、CLI 引数、または環境変数を使用して、コンテンツ ソース、Git 設定、MCP ツールの詳細を構成します。
**自動 Git 更新:**設定可能な間隔で Git リポジトリから変更を自動的に取得して、コンテンツを最新の状態に保ちます。
カスタマイズ可能な MCP ツール: AI アシスタントに公開される検索ツールの名前と説明を定義します。
**AI 統合:**モデル コンテキスト プロトコル (MCP) をサポートする AI アシスタントとシームレスに統合します。
Related MCP server: CodeAlive MCP
使用法
このサーバーの主な使用方法はnpx経由です。npx はローカルインストールを必要とせず、パッケージをダウンロードして実行します。これにより、AIアシスタントやMCPクライアント(IDE拡張機能など)との統合が容易になります。
Smithery経由でインストール
Smithery経由で Claude Desktop 用の Docs MCP Server を自動的にインストールするには:
npx -y @smithery/cli install @buger/docs-mcp --client claudeMCP クライアント (IDE など) との統合
MCPクライアントは、 npxを使用してこのサーバーを起動するように設定できます。クライアントの設定例を以下に示します(構文はクライアントによって異なる場合があります)。
例 1: Git リポジトリの動的な検索 (Tyk ドキュメント)
この設定は、クライアントにnpxを使用して最新の@buger/docs-mcpパッケージを実行するように指示し、Tyk ドキュメントリポジトリを動的に指定します。 -y引数は、 npxインストールプロンプトを自動的に確認します。-- --toolNameおよび--toolDescription引数は、AI アシスタントに表示される検索ツールの表示方法をカスタマイズします。
{
"mcpServers": {
"tyk-docs-search": {
"command": "npx",
"args": [
"-y",
"@buger/docs-mcp@latest",
"--gitUrl",
"https://github.com/TykTechnologies/tyk-docs",
"--toolName",
"search_tyk_docs",
"--toolDescription",
"Search Tyk API Management Documentation"
],
"enabled": true
}
}
}あるいは、クライアントによってはコマンド全体を直接指定できる場合もあります。例1と同じことを、次のように記述することで実現できます。
npx -y @buger/docs-mcp@latest --gitUrl https://github.com/TykTechnologies/tyk-docs --toolName search_tyk_docs --toolDescription "Search Tyk API Management Documentation"例2: 事前に構築されたブランドMCPサーバー(例:Tykパッケージ)の使用
チームが特定のドキュメントを含むビルド済みパッケージ( @tyk-technologies/docs-mcpなど)を公開する場合、コンテンツソースとツールの詳細がそのパッケージに組み込まれるため、設定はよりシンプルになりますnpxでは-y引数の使用が引き続き推奨されます。
{
"mcpServers": {
"tyk-official-docs": {
"command": "npx",
"args": [
"-y",
"@tyk-technologies/docs-mcp@latest"
],
"enabled": true
}
}
}このアプローチは、公式ドキュメントやコードベース向けの標準化された検索エクスペリエンスを提供するのに最適です。以下の「独自のプレビルドMCPサーバーの作成」セクションをご覧ください。
Tyk チームが独自のドキュメント MCP サーバーを構築する方法の例は、 https://github.com/TykTechnologies/docs-mcp にあります。
構成
ルート ディレクトリにdocs-mcp.config.jsonファイルを作成し、ビルド時および実行時に使用されるデフォルトのコンテンツ ソースと MCP ツールの詳細を定義します (CLI 引数または環境変数によって上書きされない限り)。
例1: ローカルディレクトリの使用
{
"includeDir": "/Users/username/projects/my-project/docs",
"toolName": "search_my_project_docs",
"toolDescription": "Search the documentation for My Project.",
"ignorePatterns": [
"node_modules",
".git",
"build",
"*.log"
]
}例2: Gitリポジトリの使用
{
"gitUrl": "https://github.com/your-org/your-codebase.git",
"gitRef": "develop",
"autoUpdateInterval": 15,
"toolName": "search_codebase",
"toolDescription": "Search the main company codebase.",
"ignorePatterns": [
"*.test.js",
"dist/",
"__snapshots__"
]
}設定オプション
includeDir: **(ビルド/ランタイム)**ビルド時にdataディレクトリにコピーされるローカルディレクトリへの絶対パス。dataDir が指定されていない場合は、実行時に直接使用されます。このdataDirまたはgitUrl使用してください。gitUrl: (ビルド/ランタイム) GitリポジトリのURL。これかincludeDir使用してください。autoUpdateIntervalが 0(デフォルト)の場合、サーバーは.tar.gzアーカイブを直接ダウンロードしようとします(現在は GitHub の URL 構造(https://github.com/{owner}/{repo}/archive/{ref}.tar.gz)を想定しています)。これは高速ですが、更新はサポートされません。autoUpdateInterval> 0 の場合、サーバーはgit cloneを実行し、定期的な更新を有効にします。
gitRef: (ビルド/ランタイム)gitUrlから使用するブランチ、タグ、またはコミットハッシュ (デフォルト:main)。tarball のダウンロードと Git のクローン/プルの両方で使用されます。autoUpdateInterval: (実行時) Git アップデートを自動チェックする間隔(分)(デフォルト: 0、無効)。この値を 0 より大きい値に設定すると、gitのクローン作成と定期的なgit pull操作が有効になります。git コマンドがシステムパスで使用可能になっている必要があります。dataDir: **(実行時)**実行時に検索するコンテンツを含むディレクトリへのパス。設定ファイルまたはパッケージに組み込まれているincludeDirまたはgitUrlから取得したコンテンツを上書きします。再構築せずにサーバーにライブデータを指定する場合に便利です。toolName: **(ビルド/ランタイム)**サーバーによって公開される MCP ツールの名前 (デフォルト:search_docs)。コンテンツに関連するわかりやすい名前を選択してください。toolDescription: (ビルド/ランタイム) AI アシスタントに表示される MCP ツールの説明 (デフォルト:「プローブ検索エンジンを使用してドキュメントを検索します。」)。ignorePatterns: (ビルド/ランタイム) glob パターンの配列。enableBuildCleanup: (ビルド)true(デフォルト)の場合、ビルドステップ後にdataディレクトリから一般的なバイナリ/メディアファイル(画像、動画、アーカイブなど)と100KBを超えるファイルを削除します。このクリーンアップを無効にするには、falseに設定します。ビルド中に
includeDir使用する場合: これらのパターンに一致するファイルは、dataにコピーするときに除外されます.gitignoreルールも尊重されます。実行時に
gitUrlまたはdataDirを使用する場合:dataディレクトリ内のこれらのパターンに一致するファイルは、検索インデクサーによって無視されます。
優先順位:
ランタイム構成(最高): CLI 引数(
--dataDir、--gitUrlなど)と環境変数(DATA_DIR、GIT_URLなど)は、他のすべての設定を上書きします。CLI 引数は環境変数よりも優先されます。ビルド時の構成:
docs-mcp.config.json内の設定 (includeDir、gitUrl、toolNameなど) は、npm run build中に使用されるデフォルトを定義し、上書きされない場合は実行時のデフォルトとしても機能します。**デフォルト値 (最低):**構成が指定されていない場合は、内部のデフォルトが使用されます (例:
toolName: 'search_docs'、autoUpdateInterval: 5)。
注意: includeDirとgitUrl両方が同じ構成ソースで指定されている場合 (たとえば、両方が構成ファイル内、または両方が CLI 引数として指定されている場合)、 gitUrl優先されます。
独自のプレビルドMCPサーバーを作成する
このプロジェクトをテンプレートとして使用し、ドキュメントやコードを事前に組み込んだ独自のnpmパッケージを作成して公開できます。これにより、ユーザーは設定不要ですぐに利用できるようになります(上記の例2を参照)。
**このリポジトリをフォーク/クローン:**このプロジェクトのコードから開始します。
**
docs-mcp.config.jsonを設定します。**コンテンツソースを指すincludeDirまたはgitUrlを定義します。デフォルトのtoolNameとtoolDescriptionを設定します。package.jsonを更新します。name(例:@my-org/my-docs-mcp)、version、descriptionなどを変更します。ビルド:
npm run buildを実行します。これにより、コンテンツがdataディレクトリに複製/コピーされ、パッケージが準備完了になります。公開:
npm publishを実行します (npm 認証を設定する必要があります)。
これで、ユーザーは特定のドキュメント サーバーを簡単に実行できるようになります: npx @my-org/my-docs-mcp@latest 。
(以前の「実行」、「実行時の動的構成」、および「環境変数」セクションは、クライアント構成内で引数を使用してnpx使用する方法が主に文書化された方法になったため、削除されました。)
AIアシスタントと併用する
このMCPサーバーは、モデルコンテキストプロトコルを介して接続されたAIアシスタントに検索ツールを公開します。ツールの名前と説明は設定可能です(設定セクションを参照)。このツールは、現在アクティブなdataディレクトリ(ビルド設定、設定ファイル、CLI引数、または環境変数によって決定されます)内のコンテンツを検索します。
ツールパラメータ:
query: 検索対象を表す自然言語クエリまたはキーワード(例:「ゲートウェイの設定方法」、「データベース接続例」、「ユーザー認証」)。サーバーはProbeの検索機能を使用して関連コンテンツを検索します。(必須)page: 多数の一致がある場合の結果のページ番号。省略した場合はデフォルトで1になります。(オプション)
ツール呼び出しの例 (使用例 1 のsearch_tyk_docsを使用):
{
"tool_name": "search_tyk_docs",
"arguments": {
"query": "gateway rate limiting",
"page": 1 // Requesting the first page
}
}ツール呼び出しの例 ( @tyk/docs-mcpパッケージのツールを使用):
ビルド済みパッケージ@tyk/docs-mcpツール名をsearch_tyk_official_docsとして定義していると仮定します。
{
"tool_name": "search_tyk_official_docs",
"arguments": {
"query": "dashboard api access",
"page": 2 // Requesting the second page
}
}(以前の「npm パッケージとして公開する」セクションは、上記の「独自のビルド済み MCP サーバーを作成する」セクションに置き換えられました。)
ライセンス
マサチューセッツ工科大学
Available Tools
1 toolsearch_docsA
Search documentation using the probe search engine.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Elasticsearch query string. Focus on keywords and use ES syntax (e.g., "install AND guide", "configure OR setup", "api NOT internal"). | |
| page | No | Optional page number for pagination of results (e.g., 1, 2, 3...). Default is 1. |
TDQS
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 only states 'Search documentation' which implies a read operation, but does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. The description is minimal.
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?
The description is a single concise sentence that clearly conveys the tool's action. It is appropriately sized and front-loaded with the main purpose.
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 simplicity of the tool (2 parameters, no output schema, no siblings, no annotations), the description adequately covers the essential information. It explains the tool's function and the search engine used, which is sufficient for an agent to understand its purpose.
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 description coverage is 100%, with detailed descriptions for both parameters (query with ES syntax, page with pagination). The tool description adds no extra information beyond the schema, which is acceptable given high coverage.
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?
The description clearly states the verb 'Search' and the resource 'documentation', and specifies the search engine 'probe search engine'. It is specific and directly communicates the tool's purpose.
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 does not provide explicit guidance on when to use this tool versus alternatives. Since there are no sibling tools, it is less critical, but it could still mention scenarios or prerequisites. The mention of the search engine provides some 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.
1 tool update
- First observed
search_docs
TDQS
Scored across 1 tool
With only one tool, there is no risk of confusion or overlap between tools.
Single tool, so naming consistency is perfect by default.
A single tool for a documentation search server is too few, limiting its utility.
Only search is provided; missing tools to list, retrieve, or manage documentation sources.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
An MCP server that gives your AI access to the source code and docs of all public github repos
Versioned documentation registry and semantic search for AI tools and coding assistants.
Related MCP Servers
- AlicenseAqualityAmaintenanceA Model Context Protocol (MCP) server that helps large language models index, search, and analyze code repositories with minimal setup141,272 PyPI1,002MIT

CodeAlive MCPofficial
AlicenseNot gradedqualityAmaintenanceA Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.90MIT- AlicenseNot gradedqualityDmaintenanceA server that provides organized documentation content for various applications using the Model Context Protocol, enabling AI assistants to access quickstart guides and code examples.MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server providing file search and question tools for AI models. Enables keyword search in files with line numbers and integration with external chat services.284 npmMIT