Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ocr-mcp OCR the text from the image at /home/user/scan.png"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP service for OCR tasks powered by PaddleOCR.
Text recognition from images
Table recognition with simple structured output
Handwriting recognition
Formula recognition with LaTeX output
Local file paths and HTTP/HTTPS URLs
MCP stdio server for desktop or agent integrations
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 the MCP server:
ocr-mcpOr:
python -m ocr_mcpAdd this to your Claude Desktop config:
{
"mcpServers": {
"ocr": {
"command": "ocr-mcp",
"args": []
}
}
}ocr_recognizeRecognize text in an image.
source required, local path or URL
language optional, default ch, supports ch, en, japan, korean
use_angle_cls optional, default true
ocr_tableRecognize a table and return a text table.
source required, local path or URL
language optional, default ch
ocr_handwriteRecognize handwriting in an image.
source required, local path or URL
language optional, default ch
ocr_formulaRecognize formulas and return LaTeX.
source required, local path or URL
pip install -e ".[dev]"
pytest tests/ -vsrc/ocr_mcp/
__init__.py
__main__.py
server.py
ocr_engine.py
table_parser.py
formula_engine.py
utils.py
tests/
pyproject.toml
LICENSE
README.mdPaddleOCR
PaddlePaddle
OpenCV
MCP
MIT. See LICENSE.
识别图片中的数学公式，返回 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.
