de en es ja ko ru zh

MCP Document Reader

Name: MCP Document Reader
Author: crispvibe

by crispvibe

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

功能特性

读写一体：既能读取文档，也能根据结构化参数生成 Word / PowerPoint 文件
广泛格式支持：支持 TXT、CSV、Markdown、DOC、DOCX、PDF、PPT、PPTX、EPUB、XLSX、XLS
结构化写作：支持段落、表格、标题页、要点页和演示表格生成
兼容旧格式导出：在安装 LibreOffice 时，可导出 .doc 和 .ppt
MCP 协议：符合 MCP 标准，可作为 AI 助手（如 Trae IDE）的工具使用
易于集成：简单配置即可立即使用
可靠性能：自动化测试覆盖读取、生成、转换回退和工具接口
文件系统支持：直接从文件系统读取和写入文档

Related MCP server: MCP Documents

📚 文档中心

用户指南 · API 参考 · 贡献指南 · 更新日志 · 许可证

架构

graph TB
    A[AI Assistant / User<br/>AI 助手 / 用户] -->|Call MCP tools<br/>调用 MCP 工具| B[MCP Document Reader<br/>MCP 文档读取器]
    B -->|Read<br/>读取| C[Document Readers<br/>文档读取器]
    B -->|Generate<br/>生成| D[Document Writers<br/>文档生成器]
    C -->|TXT / CSV / MD| E[Text-based Readers<br/>文本类读取器]
    C -->|DOC / DOCX| F[Word Readers<br/>Word 读取器]
    C -->|PPT / PPTX| G[Presentation Readers<br/>演示读取器]
    C -->|PDF / EPUB / Excel| H[Structured Readers<br/>结构化读取器]
    D -->|write_word_document| I[DOCX Builder<br/>DOCX 生成器]
    D -->|write_presentation| J[PPTX Builder<br/>PPTX 生成器]
    I -->|Optional conversion<br/>可选转换| K[LibreOffice -> DOC]
    J -->|Optional conversion<br/>可选转换| L[LibreOffice -> PPT]
    E --> M[Return text / metadata<br/>返回文本 / 元数据]
    F --> M
    G --> M
    H --> M
    K --> M
    L --> M
    M --> 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

支持的格式

能力	格式	扩展名	说明
读取	文本	`.txt`	支持多编码文本提取
读取	CSV	`.csv`	归一化为制表符分隔文本
读取	Markdown	`.md`, `.markdown`	直接提取 Markdown 文本
读取	Word	`.doc`, `.docx`	`.doc` 通过命令 / LibreOffice 回退读取
读取	PDF	`.pdf`	提取文本
读取	PowerPoint	`.ppt`, `.pptx`	`.pptx` 原生解析，`.ppt` 回退读取
读取	EPUB	`.epub`	基于 spine 顺序提取章节
读取	Excel	`.xlsx`, `.xls`	提取工作表和单元格内容
生成	Word	`.docx`	原生生成，支持段落和表格
生成	Word	`.doc`	通过 `docx -> doc` 的 LibreOffice 转换生成
生成	PowerPoint	`.pptx`	原生生成，支持标题、正文、要点、表格
生成	PowerPoint	`.ppt`	通过 `pptx -> ppt` 的 LibreOffice 转换生成

安装

使用 pip (推荐)

pip install mcp-documents-reader

如果需要 PowerPoint 生成功能，请确保运行环境中可用 python-pptx。

如果需要导出旧格式 .doc 或 .ppt，请安装 LibreOffice，并确保 soffice 或 libreoffice 已加入 PATH。

从源码安装

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

MCP 工具

本服务器提供以下工具：

`read_document`

使用统一接口读取任何支持的文档类型。

参数：

filename (string, 必填): 文档文件路径，支持绝对路径或相对路径。

`extract_document_images`

提取 DOCX 文件中的嵌入图片，并返回结构化 JSON 元数据。

参数：

filename (string, 必填): DOCX 文件路径。
output_dir (string, 可选): 导出图片的目录。

`write_word_document`

生成 .docx Word 文档，或通过 LibreOffice 转换导出 .doc。

参数：

filename (string, 必填): 输出路径，后缀必须为 .docx 或 .doc。
title (string, 可选): 文档标题。
paragraphs (string 数组, 可选): 按顺序写入的段落。
tables (object 数组, 可选): 表格定义，支持 title、headers、rows。

`write_presentation`

生成 .pptx 演示文稿，或通过 LibreOffice 转换导出 .ppt。

参数：

filename (string, 必填): 输出路径，后缀必须为 .pptx 或 .ppt。
title (string, 可选): 标题页标题。
subtitle (string, 可选): 标题页副标题。
slides (object 数组, 可选): 幻灯片定义，支持 title、paragraphs、bullets、table。

配置

在 Trae IDE / Claude Desktop 中使用

将以下内容添加到您的 MCP 配置文件中：

选项 1：使用 PyPI (推荐)

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

选项 2：使用 GitHub 仓库

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

选项 3：使用 Gitee 仓库（国内访问更快）

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

使用方法

作为 MCP 工具使用

配置完成后，AI 助手可以直接调用以下工具：

# 读取 DOCX 文件
read_document(filename="example.docx")

# 读取演示文稿
read_document(filename="example.pptx")

# 生成 DOCX 报告
write_word_document(
    filename="report.docx",
    title="周报",
    paragraphs=["本周总结", "下周计划"],
    tables=[
        {
            "title": "指标表",
            "headers": ["名称", "数值"],
            "rows": [["线索", 42], ["成交", 8]],
        }
    ],
)

# 生成 PPTX 汇报
write_presentation(
    filename="briefing.pptx",
    title="季度汇报",
    subtitle="Q2",
    slides=[
        {
            "title": "亮点",
            "paragraphs": ["概述段落"],
            "bullets": ["重点 A", "重点 B"],
        }
    ],
)

作为 Python 库使用

from mcp_documents_reader import DocumentReaderFactory

# 使用工厂类（推荐）
reader = DocumentReaderFactory.get_reader("document.pdf")
content = reader.read("/path/to/document.pdf")

# 检查格式是否支持
if DocumentReaderFactory.is_supported("file.xlsx"):
    reader = DocumentReaderFactory.get_reader("file.xlsx")
    content = reader.read("/path/to/file.xlsx")

工具接口详情

read_document

读取任何支持的文档类型。

参数	类型	必填	描述
filename	string	✅	文档文件路径，支持绝对路径或相对路径

extract_document_images

提取 DOCX 文件中的嵌入图片。

参数	类型	必填	描述
filename	string	✅	DOCX 文件路径
output_dir	string	❌	可选的图片导出目录

write_word_document

直接生成 DOCX，或通过 LibreOffice 转换导出 DOC。

参数	类型	必填	描述
filename	string	✅	输出路径，后缀必须为 `.docx` 或 `.doc`
title	string	❌	可选文档标题
paragraphs	string[]	❌	按顺序写入的段落
tables	object[]	❌	表格定义，支持 `title`、`headers`、`rows`

write_presentation

直接生成 PPTX，或通过 LibreOffice 转换导出 PPT。

参数	类型	必填	描述
filename	string	✅	输出路径，后缀必须为 `.pptx` 或 `.ppt`
title	string	❌	标题页标题
subtitle	string	❌	标题页副标题
slides	object[]	❌	幻灯片定义，支持 `title`、`paragraphs`、`bullets`、`table`

依赖

核心依赖

mcp >= 1.26.0 - MCP 协议实现
python-docx >= 1.2.0 - DOCX 读取和 Word 文档生成
python-pptx >= 0.6.23 - PowerPoint 文档生成
pypdf >= 6.8.0 - PDF 文件读取（替代 PyPDF2）
openpyxl >= 3.1.5 - Excel 文件读取

可选运行时依赖

LibreOffice - 如果要导出旧格式 .doc 或 .ppt，则必须安装
antiword / catppt - 旧格式 .doc / .ppt 读取时的可选辅助命令

开发依赖

pytest >= 8.0.0 - 测试框架
pytest-asyncio >= 0.24.0 - 异步测试支持
pytest-cov >= 6.0.0 - 覆盖率报告
basedpyright >= 0.28.0 - 类型检查
ruff >= 0.8.0 - 代码检查和格式化

许可证

本项目以 MIT License 协议开源。

本项目基于优秀的开源项目 xt765/mcp_documents_reader 进行二次开发，并在其基础上做了进一步增强。

我们当前主要新增和增强了以下能力：

文档内图片提取能力
Word 与 PowerPoint 文档写作、生成工作流
面向 MCP 场景的更完整文档创作支持

非常感谢原仓库作者提供的基础能力与开源工作。

贡献

欢迎提交 Issue 和 Pull Request！

Available Tools

4 tools

extract_document_imagesB

Extracts embedded images from a DOCX file and returns structured JSON metadata.

:param filename: Path to the DOCX document :param output_dir: Optional directory to save extracted images :return: JSON payload containing extracted image metadata and saved file paths

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`output_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the tool extracts images and returns JSON metadata, but lacks critical behavioral details: whether it modifies the original file, handles errors (e.g., invalid paths), requires specific permissions, or has performance constraints. For a file operation tool with zero annotation coverage, this is a significant gap.

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 appropriately sized with three sentences: purpose, parameters, and return value. It's front-loaded with the core functionality. The parameter and return explanations are necessary given the lack of schema descriptions, though the structure could be slightly more polished (e.g., avoiding markdown-like syntax).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (file processing with two parameters), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers purpose and parameters but lacks behavioral context like error handling or side effects. With output schema reducing the need to explain returns, a score of 3 reflects this partial completeness.

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 description coverage is 0%, so the description must compensate. It explicitly documents both parameters: 'filename' as the path to the DOCX document and 'output_dir' as an optional directory for saving images. This adds clear meaning beyond the schema's generic titles. However, it doesn't detail parameter formats (e.g., absolute vs. relative paths) or constraints.

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 specific action ('Extracts embedded images'), target resource ('from a DOCX file'), and output format ('returns structured JSON metadata'). It distinguishes itself from sibling tools like read_document, write_presentation, and write_word_document by focusing on image extraction rather than document reading or writing operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist, DOCX format required), compare with similar tools, or indicate scenarios where extraction might fail. The agent must infer usage from the purpose alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_documentB

Reads and extracts text from a specified document file. Supports TXT, CSV, Markdown, DOC, DOCX, PDF, PPT, PPTX, EPUB, and Excel (XLSX, XLS) files.

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

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions supported file formats and the return type ('Extracted text'), but lacks details on error handling (e.g., unsupported formats, file not found), performance (e.g., large file handling), or permissions required. For a read operation with zero annotation coverage, this is a significant gap.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a concise list of supported formats and parameter details. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 moderate complexity (single parameter, read-only operation) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, supported formats, and parameter semantics, but could improve by adding behavioral details like error handling or limitations, especially since no annotations are provided.

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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that the 'filename' parameter is a 'Path to the document file to read (supports absolute or relative paths)', clarifying usage and format. With only one parameter, this compensates well 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.

Purpose4/5

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

The description clearly states the tool's purpose: 'Reads and extracts text from a specified document file.' It specifies the verb ('Reads and extracts'), resource ('document file'), and scope ('text'), but does not explicitly differentiate from sibling tools like 'extract_document_images' beyond the focus on text versus images.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It lists supported file formats but does not mention when to choose this over 'extract_document_images' for image extraction or other siblings for writing operations. Usage context is implied by the tool's name but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_presentationC

Generates a PowerPoint presentation in PPTX format, or PPT via LibreOffice conversion.

:param filename: Target output path ending with .pptx or .ppt :param title: Optional title slide title :param subtitle: Optional title slide subtitle :param slides: Optional slide definitions containing title, paragraphs, bullets, and table :return: JSON payload describing the generated file path and format

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`title`	No
`subtitle`	No
`slides`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool generates a presentation and describes the return value, but lacks critical details such as permissions required, file system impacts, error handling, or rate limits. For a write operation with zero annotation coverage, this is a significant gap in transparency.

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 appropriately sized and front-loaded, starting with the core functionality. Each sentence adds value, such as format details and parameter explanations, with no wasted text. The structure is clear, though it could be slightly more streamlined by integrating parameter details more cohesively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a presentation generation tool with 4 parameters, 0% schema coverage, and no annotations, the description is moderately complete. It covers the basic operation and parameters but lacks depth in behavioral aspects and usage context. The presence of an output schema helps by documenting the return value, but overall completeness is adequate with clear 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 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose (e.g., 'Target output path ending with .pptx or .ppt' for filename, 'Optional title slide title' for title). However, it does not fully detail the structure of 'slides' (e.g., what 'slide definitions' entail) or provide examples, leaving some ambiguity. This partial compensation justifies a baseline score.

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 'Generates a PowerPoint presentation in PPTX format, or PPT via LibreOffice conversion,' which specifies the verb (generates) and resource (PowerPoint presentation). It distinguishes from siblings like write_word_document by specifying the output format, though it could be more explicit about the distinction. It's not tautological and provides a clear purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like write_word_document or other siblings. It mentions the output formats but does not specify scenarios, prerequisites, or exclusions for usage. This leaves the agent without contextual direction for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_word_documentB

Generates a Word document in DOCX format, or DOC via LibreOffice conversion.

:param filename: Target output path ending with .docx or .doc :param title: Optional document title :param paragraphs: Optional paragraph list written in order :param tables: Optional table definitions using title, headers, and rows :return: JSON payload describing the generated file path and format

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`title`	No
`paragraphs`	No
`tables`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool generates documents and returns a JSON payload, but lacks details on permissions, error handling, rate limits, or side effects. For a write operation with zero annotation coverage, this is a significant gap in transparency.

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 appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: format details, parameter explanations, and return information. There's minimal waste, though the parameter list could be more integrated into the narrative flow.

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 complexity (4 parameters, write operation) and no annotations, the description covers purpose, parameters, and return value. With an output schema present, it doesn't need to explain return values in detail. It's mostly complete but could improve on behavioral context and usage guidelines.

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 0%, so the description must compensate. It lists all four parameters with brief explanations (e.g., 'Target output path ending with .docx or .doc'), adding meaning beyond the schema. However, it doesn't fully detail parameter constraints or formats, leaving gaps like table structure specifics.

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's purpose: 'Generates a Word document in DOCX format, or DOC via LibreOffice conversion.' It specifies the verb ('Generates'), resource ('Word document'), and format details, distinguishing it from sibling tools like extract_document_images (extraction), read_document (reading), and write_presentation (different document type).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like write_presentation for presentations or read_document for reading documents, nor does it specify prerequisites or contexts for choosing this tool. Usage is implied but not explicitly stated.

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.

4 tool updatesv1.4.0Apr 15, 2026
- First observedextract_document_images
- First observedread_document
- First observedwrite_presentation
- First observedwrite_word_document

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: extract_document_images extracts images from DOCX, read_document reads text from various file types, write_presentation creates PowerPoint files, and write_word_document creates Word documents. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., extract_document_images, read_document, write_presentation, write_word_document). The naming is uniform and predictable, with no deviations or mixed conventions.

Tool Count4/5

With 4 tools, the count is reasonable for a document reader server, covering reading, extraction, and writing for common document types. It is slightly lean but well-scoped, as each tool serves a distinct and useful function without redundancy.

Completeness3/5

The tool set covers reading and writing for key document formats (Word, PowerPoint, PDF, etc.) and image extraction, but there are notable gaps. For example, it lacks tools for updating or editing existing documents, converting between formats, or handling other common operations like document merging or metadata manipulation, which could limit agent workflows.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
Needle
com.needle-ai.mcp
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.
RAG Systems Search File Systems
2
docbaseOAuth
io.github.krayinc
DocBase MCP server for AI agents
Documentation Access Search Developer Tools
2

Related MCP Servers

office-mcp-server
Workplace & Productivity App Automation File Systems
chunleiding
F
license
B
quality
D
maintenance
MCP server for Office document automation, enabling AI assistants to create, read, and clone Word/Excel/PPT templates while preserving formatting.
Updated 3 months ago (2026-06-05 17:25 UTC)
4
1
-
MCP Documents
Developer Tools Workplace & Productivity
rofiqcp
A
license
C
quality
D
maintenance
A unified MCP server for document processing that enables creating, editing, and converting Word documents (DOCX), PDFs, Markdown, and images, with support for templates, formatting, and batch operations.
Updated 8 months ago (2026-01-23 02:38 UTC)
100
MIT
mcp-doc-analyzer
File Systems Text Summarization Research & Data
wzx11223344
A
license
Not graded
quality
B
maintenance
An MCP server for document analysis that provides 21 tools for reading, text analysis, summarization, and data statistics, enabling AI clients to process and understand documents efficiently.
Updated 2 months ago (2026-07-18 11:10 UTC)
MIT
Document Tools MCP Server
Workplace & Productivity
Deepak993
F
license
Not graded
quality
C
maintenance
MCP server that provides document conversion and processing tools, enabling AI assistants to handle document formats through natural language.
Updated a month ago (2026-08-10 17:40 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/crispvibe/mcp-document-studio'

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

功能特性

📚 文档中心

架构

支持的格式

安装

使用 pip (推荐)

从源码安装

MCP 工具

read_document

extract_document_images

write_word_document

write_presentation

配置

在 Trae IDE / Claude Desktop 中使用

使用方法

作为 MCP 工具使用

作为 Python 库使用

工具接口详情

read_document

extract_document_images

write_word_document

write_presentation

依赖

核心依赖

可选运行时依赖

开发依赖

许可证

贡献

相关项目

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`read_document`

`extract_document_images`

`write_word_document`

`write_presentation`