Skip to main content
Glama
fclwtt

anydoc-mcp

by fclwtt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

anydoc-mcp

把 Firecrawl anydoc 封装成 MCP (Model Context Protocol) Server，让任何支持 MCP 的 AI 平台/Agent 都能调用文档转 Markdown 能力。

纯本地运行、无 ML 模型、无需 API key、不联网，中位转换耗时 < 5ms。

功能

  • 提供 MCP 工具 convert_document_to_markdown

  • 输入：文件名 + 文件内容（base64）

  • 输出：干净的 GitHub-Flavored Markdown

  • 自动从文件内容识别格式（CSV 等无签名格式按扩展名识别）

  • 结构化错误返回（needsOcr / unsupported / encrypted / malformed 等）

Related MCP server: md-converter-mcp

支持的格式

类别

扩展名

Word

.doc .docx .docm

PowerPoint

.ppt .pps .pot .pptx .pptm .ppsx .ppsm

Excel

.xls .xlsx .xlsm .xlsb

OpenDocument

.odt .ods .odp

其他

.rtf .epub .csv .pdf（文本型）

限制

  • 单向：只做 文档 → Markdown，没有 Markdown → DOCX

  • 扫描型/图片型 PDF 不支持（anydoc 无 OCR，会返回 needsOcr 错误）

  • 不渲染内嵌图片：只抽取文字，文档中的截图/图表不会进入 Markdown

  • 每次调用只处理一个文档

本地开发

前置条件

  • Node.js >= 18

  • npm（或 pnpm / yarn）

安装依赖

npm install

运行冒烟测试

npm test

验证 anydoc 核心转换能力（CSV → Markdown、错误处理）。

手动启动 MCP Server（STDIO）

npm start

Server 通过 stdin/stdout 与 MCP 客户端通信。日志输出到 stderr。

手动测试 MCP 协议

可以用 MCP Inspector 进行图形化测试：

npx @modelcontextprotocol/inspector node src/server.js

发布到 npm

包名使用 scope @fclwtt/anydoc-mcp，确保全局唯一。如需更换 scope，修改 package.json 中的 name。

# 1. 登录 npm
npm login

# 2. 发布（scope 包首次发布必须加 --access public）
npm publish --access public

# 后续更新版本号后重新发布
npm version patch   # 或 minor / major
npm publish

发布成功后，任何支持 MCP STDIO 的平台都可以通过 npx @fclwtt/anydoc-mcp 一键启动。

接入云平台（以 aikf.wtc.edu.cn 为例）

在平台的「接入 MCP 插件」页面填写：

配置项

值

插件名称

anydoc（或自定义）

插件描述

文档转 Markdown：支持 docx/pptx/xlsx/pdf/odt/rtf/epub/csv，纯本地离线运行

传输方式

STDIO

命令

npx

参数

-y @fclwtt/anydoc-mcp

环境变量

无需配置（纯本地运行，不需要 API key）

-y 参数让 npx 自动确认安装，避免交互式提示阻塞平台启动。

平台调用示例

平台的大模型会自动发现并调用 convert_document_to_markdown 工具，传入：

{
  "filename": "报告.docx",
  "content_base64": "UEsDBBQAAAAIA..."
}

返回 Markdown 文本。

项目结构

anydoc-mcp/
├── src/
│   └── server.js          # MCP Server 主文件
├── test/
│   ├── smoke.mjs          # 冒烟测试
│   └── mcp_protocol_test.mjs  # MCP 协议级测试
├── .github/
│   └── workflows/
│       └── publish.yml    # GitHub Actions 自动发布
├── package.json
├── README.md
├── PUBLISH.md             # 发布指南
└── .gitignore

技术栈

License

MIT

Available Tools

1 tool
convert_document_to_markdownA

用 anydoc 将文档转换为干净的 GitHub-Flavored Markdown。支持 doc/docx/ppt/pptx/xls/xlsx/pdf(文本型)/odt/ods/odp/rtf/epub/csv。纯本地运行，无需 API key，不联网。注意：扫描型/图片型 PDF 不支持（anydoc 无 OCR）；不渲染文档内嵌图片。

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes原始文件名（含扩展名），用于格式识别，例如 report.docx
content_base64Yes文件内容的 base64 编码字符串

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers useful traits: pure local execution, no API key, no network calls, no OCR, and no rendering of embedded images. These are meaningful behavioral facts an agent needs before invoking. It does not describe error behavior or output shape in detail, keeping it short of a 5.

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?

Front-loaded with the core action, then format support, then operating constraints and caveats, all in a compact block. The format enumeration is long but earns its place by defining accepted inputs.

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?

No output schema exists, but the description implies the return format (GFM) and flags key limitations. Combined with 100% schema coverage and full required-parameter documentation, an agent has enough to call it correctly; only error/edge-case handling is left unstated.

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 the schema already documents both parameters (filename for format detection, base64 content). The description adds no per-parameter detail beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb+resource ('convert documents to clean GitHub-Flavored Markdown') and enumerates every supported input format, so an agent immediately knows the operation and its scope. There are no siblings to distinguish from, and the naming of the underlying engine (anydoc) adds specificity.

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 gives clear negative guidance ('scanned/image PDFs not supported', 'no OCR'), which functions as a when-not-to-use rule and steers the agent away from unsupported inputs. It lacks explicit routing to alternatives, but no sibling tools exist, so the context coverage is strong.

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.

  1. 1 tool updatev0.1.0
    • First observedconvert_document_to_markdown
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlapping purpose. An agent can immediately identify the single action available.

Naming Consistency5/5

The sole tool follows a clear verb_noun snake_case convention (convert_document_to_markdown). No inconsistency can arise with one tool.

Tool Count3/5

A single tool is thin for an MCP server, even if it consolidates many document formats. Core conversion is covered, but the surface is borderline minimal.

Completeness4/5

The tool covers a wide range of input formats and a clear output (GFM), but lacks batch conversion, output-path configuration, and OCR support (acknowledged limitation). These are minor gaps for a conversion utility.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Markitdown MCP Server

    RECTOR-LABS
    F
    license
    Not graded
    quality
    D
    maintenance
    Converts documents (PDF, DOCX, images, etc.) to Markdown using Microsoft's Markitdown library, with no local setup required. Integrates with AI agents via MCP for seamless document conversion.
    1
    -
  • groupdocs-markdown-mcp by groupdocs-markdown

    groupdocs-markdown-mcpofficial

    groupdocs-markdown
    A
    license
    Not graded
    quality
    A
    maintenance
    Converts documents (PDF, DOCX, XLSX, EPUB, etc.) to clean, structured Markdown, and retrieves document info, for use with AI agents.
    MIT

  • document-converter

    Zahid-Abbas-Ali-Baig
    A
    license
    Not graded
    quality
    C
    maintenance
    Converts PDFs, Office files, spreadsheets, emails, audio, and more to Markdown locally, enabling AI assistants to read and process them without cloud upload.
    MIT