Servicio OCR basado en MCP impulsado por PaddleOCR, que admite reconocimiento de texto y reconocimiento de tablas.
Reconocimiento de texto OCR: Reconocer contenido de texto en imágenes, compatible con chino, inglés y otros idiomas
Reconocimiento de tablas: Reconocer tablas en imágenes y devolver datos estructurados
Reconocimiento de escritura a mano: Reconocer texto manuscrito en imágenes
Reconocimiento de fórmulas: Reconocer fórmulas matemáticas en imágenes y devolver formato LaTeX
Soporte multi-formato: Compatible con JPG, PNG, BMP, TIFF, WebP y otros formatos de imagen
Soporte de URL: Compatible con rutas de archivo locales y URLs de red
Protocolo MCP: Servicio MCP estándar, se puede integrar en asistentes de IA compatibles con MCP
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_mcpAñadir al archivo de configuración de Claude Desktop:
{
"mcpServers": {
"ocr": {
"command": "ocr-mcp",
"args": []
}
}
}ocr_recognizeReconocer contenido de texto en imágenes.
Parámetros:
source (obligatorio): Origen de la imagen, ruta de archivo local o URL
language (opcional): Idioma de reconocimiento, por defecto ch (chino), compatible con en, japan, korean, etc.
use_angle_cls (opcional): Si habilitar la clasificación de dirección del texto, por defecto true
Ejemplo de salida:
1. Hello World (confidence: 98.50%)
2. 你好世界 (confidence: 97.20%)ocr_tableReconocer contenido de tablas en imágenes y devolver datos estructurados.
Parámetros:
source (obligatorio): Origen de la imagen, ruta de archivo local o URL
language (opcional): Idioma de reconocimiento, por defecto ch
Ejemplo de salida:
+--------+-----+------+
| Name | Age | City |
+--------+-----+------+
| Alice | 25 | NYC |
+--------+-----+------+
| Bob | 30 | LA |
+--------+-----+------+ocr_handwriteReconocer contenido de texto manuscrito en imágenes.
Parámetros:
source (obligatorio): Origen de la imagen, ruta de archivo local o URL
language (opcional): Idioma de reconocimiento, por defecto ch
Ejemplo de salida:
1. Hello World (confidence: 85.50%)
2. 你好 (confidence: 82.30%)ocr_formulaReconocer fórmulas matemáticas en imágenes y devolver formato LaTeX.
Parámetros:
source (obligatorio): Origen de la imagen, ruta de archivo local o URL
Ejemplo de salida:
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 documentationEste proyecto utiliza una arquitectura paralela de subprogramas, con 4 herramientas de reconocimiento que son independientes y se pueden llamar por separado:
┌─────────────────────────────────────────────────────────┐
│ 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 FormulaEngineCaracterísticas:
Cada subprograma se ejecuta de forma independiente sin dependencias
Admite llamadas paralelas, puede procesar múltiples tareas simultáneamente
Crea instancias independientes para cada llamada para evitar conflictos de estado
Puede extender o reemplazar individualmente cualquier subprograma
PaddleOCR: Motor de reconocimiento OCR principal
PaddlePaddle: Marco de aprendizaje profundo
OpenCV: Procesamiento de imágenes
MCP: Marco de servicio del Protocolo de Contexto de Modelo
Este proyecto es de código abierto bajo la Licencia 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.
