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., "@local-docs-mcp 経費精算規程の締め日を教えて"
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_ROOT に指定したフォルダ配下の docx / pptx / xlsx / pdf / md / txt / csv / html を対象に:
ツール | 内容 |
| ドキュメント一覧(相対パス・サイズ・更新日時) |
| 全文検索。スペース区切りでAND検索。マッチ箇所の抜粋付きで返す |
| 本文をテキスト(Markdown)として読み出し。大きい文書は offset で分割読み |
回答の組み立てはMCPクライアント(Claude)側が行う。サーバは検索と本文抽出のみを担当する。 Office系ファイルは markitdown でテキスト変換し、 抽出結果はファイル更新日時ベースでキャッシュする。
Related MCP server: Document Organizer MCP
uv が必要。依存関係は初回実行時に自動で解決される。
DOCS_ROOT=/path/to/documents uv run server.py
# エラーなく起動して待機すればOK (Ctrl+C で終了)test_docs/ に、動作確認用のサンプル文書一式が入っている(架空の会社「株式会社サンプル商事」の社内文書。対応フォーマットを網羅)。
test_docs/
├── 規程/
│ ├── 経費精算規程.docx # 締め日は毎月5日、支払日は当月25日
│ ├── 出張旅費規程.pdf # 日当2,500円、宿泊上限12,000円
│ └── 在宅勤務ガイドライン.md # 週3日上限、在宅手当 月3,000円
├── 総務/
│ ├── 有給休暇FAQ.txt # 入社6か月で10日付与、繰越は翌年度まで
│ ├── 社内連絡先一覧.xlsx # 部署・担当・内線・メールの表
│ └── 備品購入申請ルール.csv # 金額別の承認者(10万円以上は稟議書)
├── 議事録/
│ └── 2026-07-01_全社定例会議事録.md # システム切替日、夏季休業日程
└── 資料/
└── 新製品発表会企画.pptx # 日程・会場・予算上限500万円各ファイルには答え合わせ可能な事実を仕込んであるので、DOCS_ROOT をこのフォルダに向けて
「経費精算の締め日はいつ?」「出張の宿泊費の上限は?」「経理部の内線番号は?」などと質問すれば、
検索 → 本文読解 → 回答の一連の流れをテストできる。
DOCS_ROOT=$(pwd)/test_docs uv run server.pyclaude mcp add local-docs \
-e DOCS_ROOT=/path/to/documents \
-- uv --directory /path/to/this/repo run server.py登録後、Claude Code で「◯◯について規程ではどうなってる?」のように聞くと、 検索 → 該当文書の読解 → 回答、が自動で行われる。
検索対象フォルダ (DOCS_ROOT) 配下のドキュメント一覧を返す。
Returns:
各ドキュメントの相対パス・サイズ(バイト)・更新日時のリスト。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the function returns a list with specific fields and implies read-only behavior. However, it does not mention order, pagination, or behavior for empty/error states.
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 extremely concise with two sentences, front-loading the purpose and then listing return fields. No superfluous information.
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?
While the description covers the basic purpose and output, it lacks details like whether the listing is recursive, if there are any sorting defaults, or how errors are handled. For a simple list tool, this is adequate but not fully complete.
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?
No parameters exist, so schema coverage is complete. The description adds value by explaining what DOCS_ROOT is and what output is provided, giving context beyond the empty 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?
The description clearly states it returns a list of documents under DOCS_ROOT, specifying returned fields (relative path, size, bytes, update timestamp). It distinguishes from siblings read_document and search_documents by focusing on broad listing.
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 listing all documents but does not explicitly state when to use this vs. search_documents, nor does it mention any prerequisites or limitations. It lacks explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ドキュメントの本文をテキスト(Markdown)として読み出す。
Args:
path: search_documents / list_documents が返した相対パス。
offset: 読み出し開始位置(文字数)。大きい文書の続きを読むときに使う。
max_chars: 一度に返す最大文字数。
Returns:
本文テキストと、全体の文字数・続きがあるかどうか。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| offset | No | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately discloses that the tool is a read operation returning text, total length, and continuation status. However, it does not mention prerequisites like permissions, error handling, or whether the operation is idempotent. The behavior is implied but not fully transparent.
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 concise and well-structured. It leads with the purpose, followed by argument details, and ends with the return value description. Every sentence provides essential information without redundancy.
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 no output schema, the description explains return values (body text, total length, continuation flag). It covers the main use case adequately. Minor gaps: no mention of handling invalid paths or error scenarios, but the description is sufficient for a simple read tool with good context signals.
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 description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'path' comes from search/list documents, 'offset' is for continuation reading, and 'max_chars' controls response size. This fully compensates for the schema's lack of descriptions.
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 action (read) and resource (document body as Markdown). It effectively differentiates from sibling tools list_documents and search_documents by specifying what this tool does (read content) as opposed to listing or searching.
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 explains how to use arguments (path from search/list, offset for continuation, max_chars) but does not explicitly state when to use this tool versus alternatives or provide exclusion conditions. The guidance is implicit through the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DOCS_ROOT 配下のドキュメントを全文検索する。
Args:
query: 検索キーワード。スペース区切りで複数指定するとAND検索(大文字小文字は区別しない)。
max_results: 返す文書数の上限。
Returns:
マッチした文書ごとに 相対パス・マッチ回数・前後の抜粋(snippets) を、マッチ回数の多い順で返す。
本文全体が必要なら read_document を使うこと。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. It discloses search semantics (AND, case-insensitive), return format (relative path, match count, snippets), and ordering. Lacks explicit statement of read-only nature, but search inherently non-destructive.
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?
Very concise: one sentence for purpose, bullet-like Args/Returns with no redundant text. Every sentence adds value.
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 search tool with output schema, description covers search behavior, return ordering, and directs to read_document for full text. Fully sufficient.
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 has 0% description coverage, but description explains 'query' as space-separated AND search and case-insensitive, and 'max_results' as upper limit with default 10. Adds significant meaning beyond 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?
The description clearly states it performs full-text search on documents under DOCS_ROOT. It distinguishes from siblings: 'If need full text, use read_document' and implicitly lists vs search.
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?
Explicitly says to use read_document for full text, describes AND search with space-separated keywords, and gives return order. Provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0list_documentsread_documentsearch_documentsEach tool has a clearly distinct purpose: listing all documents, reading a specific document with pagination, and full-text searching. No ambiguity or overlap.
All tool names follow a consistent verb_noun pattern in snake_case (list_documents, read_document, search_documents), making them predictable.
Three tools are well-scoped for a document server, covering the essential operations without unnecessary bloat or deficiency.
The tool set provides listing, reading with pagination, and full-text search, which is complete for a read-only document retrieval system. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, browse, and read your Dropbox files. Find documents by name or content, list folders, and…
Securely search and manage workspace context files for AI agents and teams.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Ingest, manage, and retrieve documents for RAG-powered AI applications
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BitFigther/local-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server