PaddleOCR 기반의 MCP OCR 서비스로, 텍스트 인식과 표 인식을 지원합니다.
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_mcpClaude 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: Model Context Protocol 서비스 프레임워크
이 프로젝트는 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.
