基于 MCP 的 OCR 服务，由 PaddleOCR 驱动，支持文本识别和表格识别。
OCR 文本识别：识别图像中的文本内容，支持中文、英文等多种语言
表格识别：识别图像中的表格并返回结构化数据
手写识别：识别图像中的手写文本
公式识别：识别图像中的数学公式并返回 LaTeX 格式
多格式支持：支持 JPG、PNG、BMP、TIFF、WebP 等图像格式
URL 支持：支持本地文件路径和网络 URL
MCP 协议：标准 MCP 服务，可集成到兼容 MCP 的 AI 助手中
Related MCP server: openai-vision-mcp-server
pip install ocr-mcpgit clone https://github.com/LinuxLinking/OCR_MCP.git
cd OCR_MCP
pip install -e .# Run directly
ocr-mcp
# Or run via Python module
python -m ocr_mcp添加到 Claude Desktop 配置文件：
{
"mcpServers": {
"ocr": {
"command": "ocr-mcp",
"args": []
}
}
}ocr_recognize识别图像中的文本内容。
参数：
source（必填）：图像来源，本地文件路径或 URL
language（可选）：识别语言，默认为 ch（中文），支持 en、japan、korean 等
use_angle_cls（可选）：是否启用文本方向分类，默认为 true
示例输出：
1. Hello World (confidence: 98.50%)
2. 你好世界 (confidence: 97.20%)ocr_table识别图像中的表格内容并返回结构化数据。
参数：
source（必填）：图像来源，本地文件路径或 URL
language（可选）：识别语言，默认为 ch
示例输出：
+--------+-----+------+
| Name | Age | City |
+--------+-----+------+
| Alice | 25 | NYC |
+--------+-----+------+
| Bob | 30 | LA |
+--------+-----+------+ocr_handwrite识别图像中的手写文本内容。
参数：
source（必填）：图像来源，本地文件路径或 URL
language（可选）：识别语言，默认为 ch
示例输出：
1. Hello World (confidence: 85.50%)
2. 你好 (confidence: 82.30%)ocr_formula识别图像中的数学公式并返回 LaTeX 格式。
参数：
source（必填）：图像来源，本地文件路径或 URL
示例输出：
Formula 1:
LaTeX: E = mc^2
Formula 2:
LaTeX: \int_{0}^{\infty} e^{-x^2} dx = \frac{\sqrt{\pi}}{2}pip install -e ".[dev]"pytest tests/ -vOCR_MCP/
├── src/ocr_mcp/
│ ├── __init__.py # Package initialization
│ ├── __main__.py # Module entry point
│ ├── server.py # MCP service main entry (dispatch layer)
│ ├── ocr_engine.py # Subprogram 1: Text recognition engine
│ ├── table_parser.py # Subprogram 2: Table recognition engine
│ ├── formula_engine.py # Subprogram 3: Formula recognition engine
│ └── utils.py # Utility functions
├── tests/
│ └── test_ocr.py # Test files
├── pyproject.toml # Project configuration
├── LICENSE # MIT License
└── README.md # Project documentation本项目采用子程序并行架构，包含 4 个独立的识别工具，可单独调用：
┌─────────────────────────────────────────────────────────┐
│ MCP Server (Dispatch Layer) │
├──────────────┬──────────────┬─────────────┬─────────────┤
│ Subprogram 1 │ Subprogram 2 │ Subprogram 3│ Subprogram 4│
│ocr_recognize │ ocr_table │ocr_handwrite│ ocr_formula │
│Text Recognition│Table Recognition│Handwriting Recognition│Formula Recognition│
└──────────────┴──────────────┴─────────────┴─────────────┘
↓ ↓ ↓ ↓
OCREngine TableParser OCREngine FormulaEngine特性：
每个子程序独立运行，无依赖
支持并行调用，可同时处理多个任务
每次调用创建独立实例，避免状态冲突
可单独扩展或替换任何子程序
PaddleOCR：核心 OCR 识别引擎
PaddlePaddle：深度学习框架
OpenCV：图像处理
MCP：模型上下文协议服务框架
本项目基于 MIT 许可证 开源。
识别图片中的数学公式，返回 LaTeX 格式。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 图片来源：本地文件路径或 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. Specifying that it 'returns LaTeX format' is a crucial piece of information about the output structure that is not covered in the schema, making it highly valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly focused sentence that immediately communicates the tool's function and expected output format efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition successfully covers both the necessary input (source) and the specific nature of the output (LaTeX). This is highly complete for a specialized OCR tool given the absence of complex output schemas or metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, establishing a baseline score. The description does not add semantic value or additional constraints to the 'source' parameter beyond what is already detailed in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is highly specific, stating that the tool identifies mathematical formulas and differentiates its function clearly from the generic sibling tools (recognize, table, handwriting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly targets formula identification, which provides implied usage guidance. However, it does not explicitly advise the agent when to choose this tool over `ocr_recognize` or `ocr_table`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
识别图片中的手写文字内容。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 图片来源：本地文件路径或 URL | |
| language | No | 识别语言，默认 'ch'（中文） | ch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about accuracy expectations for messy handwriting, supported image formats, or what is returned. For a read-only OCR call the risk is low, but the behavior is essentially undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. It is efficient, though its brevity borders on under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are fully covered by the schema and there is no output schema to explain, but with no annotations and no mention of return format or limitations, the description leaves meaningful gaps for an OCR tool with four siblings to distinguish among.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'source' (local path or URL) and 'language' (default 'ch') fully documented in the schema. The description adds nothing beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: recognizing handwritten text in images. The word '手写' (handwritten) implicitly distinguishes it from the general-purpose sibling ocr_recognize, but it does not name that sibling or explicitly clarify the boundary against ocr_table/ocr_formula.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent can infer this is the tool for handwritten (as opposed to printed) content, but the description gives no explicit when-to-use/when-not or any mention of the sibling alternatives ocr_recognize/ocr_table/ocr_formula.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
识别图片中的文字内容。支持本地文件路径或 URL。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 图片来源：本地文件路径或 URL | |
| language | No | 识别语言，默认 'ch'（中文）。可选：ch/en/japan/korean 等 | ch |
| use_angle_cls | No | 是否启用文字方向分类，默认 true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about what is returned (raw text? lines? confidence?), supported image formats, size limits, or failure behavior for non-image inputs. The input-source sentence mostly restates the schema's 'source' field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core capability front-loaded and zero filler. It is efficient, though the second sentence largely duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only place an agent could learn what the call returns and how it behaves. It does not mention the return value (recognized text) or any operational constraints, leaving a real gap for a tool whose whole purpose is producing output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents source, language (with example values), and use_angle_cls with defaults, so the baseline is 3. The description adds no meaning beyond the schema, only restating that local paths and URLs are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: recognize text in an image, with supported input sources. It is clear this is the general OCR tool, but it never explicitly names the sibling variants (ocr_table, ocr_handwrite, ocr_formula) it is the default alternative to, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and no exclusions, despite three specialized siblings existing. An agent has to infer on its own that tables, handwriting, and formulas should route to the other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
识别图片中的表格内容，返回结构化的表格数据。
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 图片来源：本地文件路径或 URL | |
| language | No | 识别语言，默认 'ch'（中文） | ch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It helpfully discloses that output is structured table data (partially compensating for the missing output schema), but says nothing about input formats beyond the schema, size limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the recognition action first and the return type second. No wasted text, though it is short enough that more could have been said without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description never clarifies what 'structured table data' means, what image types are accepted, or how errors surface; the core return contract is left undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, documenting both 'source' and 'language', so the schema does the heavy lifting and a baseline 3 applies. The description adds no parameter-level detail such as supported URL schemes or language codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: recognize tables in images and return structured table data. The focus on 表格 implicitly distinguishes it from siblings ocr_recognize, ocr_handwrite, and ocr_formula, though it never names them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance, no exclusions, and no mention of the sibling OCR tools. Selection between ocr_table and ocr_recognize is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ocr_formulaocr_handwriteocr_recognizeocr_tableScored across 4 tools
The tools are mostly clearly separated by content type: general text, tables, handwriting, and formulas. There is minor overlap because ocr_recognize could plausibly also handle handwritten text or tables, but the specialized tools make their intended use clear.
All tools share the consistent ocr_ prefix, which makes the server easy to scan. The suffixes mix verbs and nouns (recognize/handwrite vs table/formula), but the pattern remains predictable and readable.
Four tools is well-scoped for an OCR server: one general recognition tool plus three specialized modes. Each tool has a clear reason to exist without overwhelming the agent.
The surface covers the main OCR use cases: plain text, tables, handwriting, and formulas. Minor gaps such as batch processing, PDF input, or language options exist, but they are not essential for the apparent core purpose.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
OCR.space MCP — wraps the OCR.space API (ocr.space) for image/PDF → text OCR.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Convert files, URLs, and documents to clean, AI-ready Markdown via MCP.
