医生摄入mcp
doc-ingest-mcp 将凌乱的本地文档转化为代理可以信任的稳定捆绑包。这个想法很简单:给它一个PDF、DOCX或图像,每次都会得到相同的五个工件,无论你是从CLI、批处理模式、监视模式还是MCP调用它。
为什么存在
- 代理需要可预测的文档输入,而不是每种文件类型都需要不同的解析器形状。
- 团队需要在确定性烟雾路径和真实解析器路径之间进行明确划分。
- 当每个文件都进入自己的输出包时,批处理工作流会更优雅地失败。
后端模式
| 模式 | 它做什么 | 最适合 |
|---|---|---|
fake | 对PDF/DOCX使用轻量级本地提取,对其他所有内容使用确定性回退文本。 | 测试、演示、离线开发 |
auto | 尝试真正的Docling管道。 | 正常运行时 docling 已安装 |
docling | 显式实数解析器模式。 | 与 auto,但在自动化中有详细说明 |
这 fake 后端不是玩具。它是仓库的稳定烟雾路径,现在它从捆绑的PDF和DOCX夹具中提取有意义的文本,因此下面的示例保持可读性。
管道
doc-ingest-mcp pipeline doc-ingest-mcp bundle overview
同样的管道为一切提供动力:
ingest对于一个文件batch对于目录watch用于收件箱export用于下游切换serve-mcp用于通过stdio进行代理访问
输出合同
每次摄取都会写入相同的包:
manifest.jsondocument.mdchunks.jsonlassets/tables/
manifest.json 总是携带:
sourcemime_typepage_countocr_usedchunk_counttable_countduration_msstatuserror
真实案例
存储库包括以下生成的示例 docs/examples.
PDF示例:
{
"source": "tests/fixtures/sample.pdf",
"mime_type": "application/pdf",
"page_count": 1,
"ocr_used": false,
"chunk_count": 3,
"table_count": 1,
"duration_ms": 184,
"status": "ok",
"error": null
}Document title
Alpha paragraph.
Beta paragraph.DOCX示例:
Contract header
Clause one.
Clause two.匹配的捆绑包文件已签入,因此示例不仅仅是README散文:
命令行界面
doc-ingest ingest ./sample.pdf --out ./out/sample --backend fake
doc-ingest batch ./incoming --out ./out --backend fake
doc-ingest watch ./incoming --out ./out --backend fake --once
doc-ingest export ./out/sample --format markdown
doc-ingest serve-mcp重要标志包括:
--out:输出包写入的位置--backend:fake,auto,或docling--format:markdown,chunks,或json--once:处理当前收件箱并退出
MCP表面
MCP服务器在stdio上公开了相同的行为:
ingest_documentbatch_ingestget_manifestread_chunksexport_markdown
运行它:
doc-ingest serve-mcp此命令需要 mcp 额外:
pip install -e ".[mcp]"安装
python -m venv .venv
.venv\\Scripts\\activate
pip install -e ".[dev]"要启用真正的解析器路径,请执行以下操作:
pip install -e ".[docling]"测试
pytest现场直播的固定音符 tests/fixtures/README.mdsmoke语料库有意保持较小,因此repo可以快速克隆、易于阅读,并且足够稳定,可以进行回归测试。
