docsearch
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., "@docsearchsearch for 'Q4 targets' in the reports folder"
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.
docsearch
MCP server for searching and reading binary document files.
Requirements
uv (for
uvx)
Related MCP server: File Search Tool
Install
Claude Code
User-scope (available in all projects):
claude mcp add --scope user docsearch -- uvx --from git+https://github.com/AllenComm/mcp-docsearch docsearchProject-scope (available only in the current project):
claude mcp add docsearch -- uvx --from git+https://github.com/AllenComm/mcp-docsearch docsearchOr add directly to your MCP config (~/.claude/.mcp.json for user-scope, .mcp.json for project-scope):
{
"mcpServers": {
"docsearch": {
"command": "uvx",
"args": ["--from", "git+https://github.com/AllenComm/mcp-docsearch", "docsearch"]
}
}
}OpenCode
Add to your opencode.json:
{
"mcp": {
"docsearch": {
"type": "local",
"command": ["uvx", "--from", "git+https://github.com/AllenComm/mcp-docsearch", "docsearch"],
"enabled": true,
"timeout": 30000
}
}
}Agent Instructions
Add to your AGENTS.md or CLAUDE.md so your agent knows when to use these tools:
Use the docgrep and docread MCP tools instead of grep/read for binary documents (PDF, DOCX, PPTX, XLSX, ODT, ODS, ODP, RTF, EPUB).Supported Formats
Format | Extension | Extraction |
| Page-by-page text | |
Word |
| Paragraphs + tables |
PowerPoint |
| Slide-by-slide text frames + tables |
Excel |
| Sheet-by-sheet, tab-separated rows |
OpenDocument Text |
| Paragraphs |
OpenDocument Spreadsheet |
| Sheet-by-sheet, tab-separated rows |
OpenDocument Presentation |
| Slide-by-slide text |
Rich Text Format |
| Full text |
EPUB |
| Chapter-by-chapter text (spine order) |
Tools
docgrep
Search through documents for text matching a regex pattern. Returns filepath:section:matching_line.
Parameters:
directory(required) — path to search recursivelypattern(required) — regex pattern to matchcase_sensitive— defaultfalsefile_types— filter to specific extensions, e.g.["pdf", "docx"]max_results— default100
docgrep(directory="/home/user/reports", pattern="quarterly revenue")
docgrep(directory="/home/user/docs", pattern="TODO|FIXME", file_types=["docx"])docread
Read full text content from a single document. Output is auto-truncated at 40,000 characters — use range to narrow results for large documents.
Parameters:
filepath(required) — path to the documentrange— filter to specific sections by format:PDF: page numbers, e.g.
"1-5","3","1,3,5-7"PPTX/ODP: slide numbers, e.g.
"2-3"XLSX/ODS: sheet name or 1-based index, with optional row range after colon, e.g.
"1","Sheet1","1:1-100","Revenue:50-200"EPUB: chapter numbers, e.g.
"1-5"DOCX/ODT/RTF: line numbers, e.g.
"1-50","100-200"
docread(filepath="/home/user/reports/q4.pdf", range="1-3")
docread(filepath="/home/user/data/sales.xlsx", range="1:1-100")
docread(filepath="/home/user/data/sales.xlsx", range="Revenue:50-200")Available Tools
2 toolsdocgrepA
Search through document files (PDF, DOCX, PPTX, XLSX, ODT, ODS, ODP, RTF, EPUB) for text matching a regex pattern. Returns grep-like output: filepath:section:matching_line
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Python regex pattern to match against line content. | |
| directory | Yes | Path to the directory to search. Searched recursively, skipping hidden directories. | |
| file_types | No | Limit to specific file types, with or without dots (e.g. ['pdf', 'docx']). Defaults to all supported types. | |
| max_results | No | Maximum number of matching lines to return. | |
| case_sensitive | No | Use case-sensitive matching. Default is case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses recursive search, skipping hidden directories, default case-insensitivity, max results limit, and output format. However, it does not explicitly state that the tool is read-only or discuss performance implications for large searches.
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 sentence with an additional sentence for output format, both front-loaded and to the point. No unnecessary words.
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 output schema exists, the description covers input, behavior, and output format adequately. For a search tool with five parameters, it is complete and leaves no major gaps.
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%, so baseline is 3. The description adds little beyond the schema: it repeats that the pattern is a Python regex and mentions recursive search, which is already in the directory parameter description.
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 tool searches document files for text matching a regex pattern, listing supported file types and output format. It distinguishes from the sibling tool 'docread' by specifying the search functionality.
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 provides clear context for when to use the tool (searching documents for patterns) but does not explicitly state when not to use it or mention alternatives. The sibling 'docread' is implied for reading files, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
docreadA
Read and extract text from a document file (PDF, DOCX, PPTX, XLSX, ODT, ODS, ODP, RTF, EPUB). Returns sections formatted as '=== section_label ===\ntext'. Output auto-truncated at 40000 chars.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | Filter output to specific sections. Format depends on file type: - PDF: page numbers (e.g. '1-3', '1,3,5-7') - PPTX/ODP: slide numbers (e.g. '2-4') - EPUB: chapter numbers (e.g. '1-5') - XLSX/ODS: sheet name or 1-based index, with optional row range after colon (e.g. '1', 'Sheet1', '1:1-100', 'Revenue:50-200') - DOCX/ODT/RTF: line numbers (e.g. '1-50', '100-200') | |
| filepath | Yes | Path to the document file. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output section formatting and auto-truncation at 40000 chars. No annotations provided, so description carries burden. Missing details on error handling or performance, but key behaviors are covered.
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, first lists formats efficiently, second explains output format and truncation. Slightly dense but every word adds value. No 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?
With output schema present, return values need no extra description. Covers truncation and section formatting. Lacks info on file size limits or required permissions, but sufficient for typical use.
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%, but description adds significant value for 'range' parameter by detailing format per file type (PDF, PPTX, etc.). 'filepath' is straightforward. Enhances schema meaningfully.
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?
Clearly states the tool reads and extracts text from document files, listing multiple supported formats. Differentiates from sibling 'docgrep' which likely searches within documents.
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?
Implicitly clear this is for reading full text; sibling 'docgrep' suggests a search tool. Lacks explicit when-not-to-use but context provides sufficient differentiation.
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
docgrep - First observed
docread
TDQS
The two tools have clearly distinct purposes: docgrep searches for regex patterns across documents, while docread extracts full text. No overlap in functionality.
Both tools follow a consistent 'doc' prefix + action verb pattern (docgrep, docread), making their purpose immediately clear.
With only two tools, the server is minimal but covers the core actions of searching and reading documents. While a bit sparse, it's reasonable for a focused utility like document search.
The server lacks essential operations for managing the document collection, such as listing, adding, or deleting documents. Users cannot upload or remove documents, limiting the toolset to read-only access.
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
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceUniversal MCP server for extracting text from various document formats including PDF, Excel, Word, CSV, and more, with support for streaming, limits, and markdown conversion.3MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables file system search and inspection, including directory listing, regex-based file name and content searches, and reading text, PDF, and DOCX files.1MIT
- FlicenseNot gradedqualityBmaintenanceA local MCP server providing read-only access to documents like Word, PDF, Excel, and images, with file listing, reading, and metadata extraction.1-
- AlicenseNot gradedqualityBmaintenanceMCP server for comprehensive PDF processing including text extraction with OCR, keyword search with regex, table extraction, and page preview as Base64 PNG images.1MIT
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/AllenComm/mcp-docsearch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server