Skip to main content
Glama
xt765

mcp-documents-reader

by xt765
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Features

  • Multi-format Support: Supports 4 mainstream document formats: Excel (XLSX/XLS), DOCX, PDF, and TXT

  • MCP Protocol: Compliant with MCP standards, can be used as a tool for AI assistants like Trae IDE

  • Easy Integration: Simple configuration for immediate use

  • Reliable Performance: Successfully tested and running in Trae IDE

  • File System Support: Reads documents directly from the file system

Related MCP server: MinerU Document Explorer

📚 Documentation

User Guide · API Reference · Contributing · Changelog · License

Architecture

graph TB
    A[AI Assistant / User] -->|Call read_document| B[MCP Document Reader]
    B -->|Detect file type| C{File Type?}
    C -->|.docx| D[DOCX Reader]
    C -->|.pdf| E[PDF Reader]
    C -->|.xlsx/.xls| F[Excel Reader]
    C -->|.txt| G[Text Reader]
    D -->|Extract text| H[Return Content]
    E -->|Extract text| H
    F -->|Extract text| H
    G -->|Extract text| H
    H -->|Text content| A
    
    style A fill:#e1f5ff
    style B fill:#fff4e1
    style C fill:#f0f0f0
    style D fill:#e8f5e9
    style E fill:#e8f5e9
    style F fill:#e8f5e9
    style G fill:#e8f5e9
    style H fill:#fff9c4

Supported Formats

Format

Extensions

MIME Type

Features

Excel

.xlsx, .xls

application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

Sheet and cell data extraction

DOCX

.docx

application/vnd.openxmlformats-officedocument.wordprocessingml.document

Text and structure extraction

PDF

.pdf

application/pdf

Text extraction

Text

.txt

text/plain

Plain text reading

Installation

Using pip (Recommended)

pip install mcp-documents-reader

From Source

git clone https://github.com/xt765/mcp_documents_reader.git
cd mcp_documents_reader
pip install -e .

MCP Tools

This server provides the following tool:

read_document

Read any supported document type with a unified interface.

Arguments:

  • filename (string, required): Document file path, supports absolute or relative paths.

Configuration

Using in Trae IDE / Claude Desktop

Add the following to your MCP configuration file:

Option 1: Using PyPI (Recommended)

{
  "mcpServers": {
    "mcp-document-reader": {
      "command": "uvx",
      "args": [
        "mcp-documents-reader"
      ]
    }
  }
}

Option 2: Using GitHub repository

{
  "mcpServers": {
    "mcp-document-reader": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/xt765/mcp_documents_reader",
        "mcp_documents_reader"
      ]
    }
  }
}

Option 3: Using Gitee repository (Faster access in China)

{
  "mcpServers": {
    "mcp-document-reader": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://gitee.com/xt765/mcp_documents_reader",
        "mcp_documents_reader"
      ]
    }
  }
}

Usage

As an MCP Tool

After configuration, AI assistants can directly call the following tool:

# Read a DOCX file
read_document(filename="example.docx")

# Read a PDF file
read_document(filename="example.pdf")

# Read an Excel file
read_document(filename="example.xlsx")

# Read a text file
read_document(filename="example.txt")

As a Python Library

from mcp_documents_reader import DocumentReaderFactory

# Using factory (recommended)
reader = DocumentReaderFactory.get_reader("document.pdf")
content = reader.read("/path/to/document.pdf")

# Check if format is supported
if DocumentReaderFactory.is_supported("file.xlsx"):
    reader = DocumentReaderFactory.get_reader("file.xlsx")
    content = reader.read("/path/to/file.xlsx")

Tool Interface Details

read_document

Read any supported document type.

Parameters:

Parameter

Type

Required

Description

filename

string

✅

Document file path, supports absolute or relative paths

Dependencies

Core Dependencies

  • mcp >= 1.26.0 - MCP protocol implementation

  • python-docx >= 1.2.0 - DOCX file reading

  • pypdf >= 6.8.0 - PDF file reading (replaces PyPDF2)

  • openpyxl >= 3.1.5 - Excel file reading

Development Dependencies

  • pytest >= 8.0.0 - Testing framework

  • pytest-asyncio >= 0.24.0 - Async testing support

  • pytest-cov >= 6.0.0 - Coverage reporting

  • basedpyright >= 0.28.0 - Type checking

  • ruff >= 0.8.0 - Linting and formatting

License

MIT License

Contributing

Issues and Pull Requests are welcome!

Related Projects

Available Tools

1 tool
read_documentA

Reads and extracts text from a specified document file. Supports multiple document types: TXT, DOCX, PDF, Excel (XLSX, XLS).

:param filename: Path to the document file to read (supports absolute or relative paths) :return: Extracted text from the document

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the read-only nature through 'Reads' and lists supported document types, implying it handles those formats. However, it does not mention error behavior, permission requirements, or limitations for unsupported files, leaving some ambiguity.

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 well-structured: it starts with the primary purpose, lists supported formats, then documents the parameter and return. It is not overly verbose and every part adds value, though the param/return formatting is slightly repetitive for a simple tool.

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 (one parameter, no siblings), the description covers purpose, parameter meaning, and return type. It also mentions supported formats. While it omits error handling, the output schema exists, so the need to detail return values is reduced. Overall it is sufficiently 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?

The schema only defines a string 'filename' with no description, so the parameter documentation in the description is essential. It clarifies that the path can be absolute or relative, adding practical meaning beyond the schema. This compensates for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads and extracts text from a document file, listing supported types (TXT, DOCX, PDF, Excel). It uses a specific verb and resource, but since no sibling tools are provided, it cannot explicitly distinguish itself from alternatives.

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 implies when to use this tool: whenever a document's text needs to be extracted. It provides clear context (supported formats) but does not mention exclusions or alternatives because no siblings exist. This is strong but not fully explicit in terms of when not to use.

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. 1 tool updatev1.3.1
    • First observedread_document
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap between tools. The sole tool's purpose is clear and unambiguous.

Naming Consistency5/5

The single tool follows a clean verb_noun naming convention (read + document), which is consistent and predictable. With only one tool, there are no style inconsistencies.

Tool Count2/5

A single tool is too few for a document reader server. Even though the tool handles multiple formats, the surface is extremely minimal, and agents may need additional operations such as listing files or retrieving metadata.

Completeness4/5

The tool fully covers the core purpose of extracting text from various document types. However, it lacks auxiliary functions like listing available documents or fetching metadata, which are common in document management workflows.

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

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/xt765/mcp_documents_reader'

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