Skip to main content
Glama
AllenComm
by AllenComm

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 docsearch

Project-scope (available only in the current project):

claude mcp add docsearch -- uvx --from git+https://github.com/AllenComm/mcp-docsearch docsearch

Or 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

PDF

.pdf

Page-by-page text

Word

.docx

Paragraphs + tables

PowerPoint

.pptx

Slide-by-slide text frames + tables

Excel

.xlsx

Sheet-by-sheet, tab-separated rows

OpenDocument Text

.odt

Paragraphs

OpenDocument Spreadsheet

.ods

Sheet-by-sheet, tab-separated rows

OpenDocument Presentation

.odp

Slide-by-slide text

Rich Text Format

.rtf

Full text

EPUB

.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 recursively

  • pattern (required) — regex pattern to match

  • case_sensitive — default false

  • file_types — filter to specific extensions, e.g. ["pdf", "docx"]

  • max_results — default 100

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 document

  • range — 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 tools
docgrepA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
patternYesPython regex pattern to match against line content.
directoryYesPath to the directory to search. Searched recursively, skipping hidden directories.
file_typesNoLimit to specific file types, with or without dots (e.g. ['pdf', 'docx']). Defaults to all supported types.
max_resultsNoMaximum number of matching lines to return.
case_sensitiveNoUse case-sensitive matching. Default is case-insensitive.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
rangeNoFilter 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')
filepathYesPath to the document file.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv0.1.0
    • First observeddocgrep
    • First observeddocread

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: docgrep searches for regex patterns across documents, while docread extracts full text. No overlap in functionality.

Naming Consistency5/5

Both tools follow a consistent 'doc' prefix + action verb pattern (docgrep, docread), making their purpose immediately clear.

Tool Count4/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

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
    Not graded
    quality
    C
    maintenance
    An 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.
    1
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    A local MCP server providing read-only access to documents like Word, PDF, Excel, and images, with file listing, reading, and metadata extraction.
    1
    -

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/AllenComm/mcp-docsearch'

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