Provides tools for optical character recognition (OCR) on JPEG images, allowing for the extraction of text in multiple languages with associated confidence scores.
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 Server extract the text from /Users/taowenxin/Desktop/screenshot.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.
一个基于 Tesseract.js 的 MCP（Model Context Protocol）服务器，让 Cursor 具备 OCR 图片文字识别能力。
支持识别图片中的中文（简体/繁体）、英文等多种语言
支持常见图片格式：PNG、JPG、JPEG、BMP、GIF、WebP
纯 JavaScript 实现，无需额外安装 OCR 软件
返回识别置信度，帮助判断识别质量
Related MCP server: mcp-vision
cd /Users/taowenxin/Desktop/mcpTest
npm install打开 Cursor 设置：File > Preferences > Cursor Settings
找到 Features > MCP
点击 Edit in settings.json 或手动添加配置
在 ~/.cursor/mcp.json 或 Cursor 设置中添加：
{
"mcpServers": {
"ocr-tool": {
"command": "node",
"args": ["/Users/taowenxin/Desktop/mcpTest/index.js"]
}
}
}配置完成后，重启 Cursor 或刷新 MCP 连接。
在 Cursor 的 Chat 面板（Agent 模式）中使用：
请识别这张图片中的文字：/Users/taowenxin/Desktop/screenshot.png或者指定语言：
请用英文识别这张图片：/path/to/image.jpg请列出 OCR 支持的语言语言代码 | 语言名称 |
chi_sim | 简体中文 |
chi_tra | 繁体中文 |
eng | 英文 |
jpn | 日文 |
kor | 韩文 |
fra | 法文 |
deu | 德文 |
spa | 西班牙文 |
rus | 俄文 |
ara | 阿拉伯文 |
识别图片中的文字内容。
参数：
image_path (必填): 图片文件的本地绝对路径
languages (可选): 识别语言代码数组，默认 ["chi_sim", "eng"]
列出所有支持的 OCR 语言及其代码。
首次运行：Tesseract.js 会自动下载语言包（约 10-20MB），需要网络连接
识别质量：识别准确率取决于图片清晰度、字体大小和图片质量
使用模式：建议在 Cursor 的 Agent 模式下使用，以便自动触发工具调用
路径格式：请使用绝对路径，确保路径正确且文件存在
# 直接运行服务器（用于调试）
node index.jsModel Context Protocol SDK - MCP 官方 SDK
Tesseract.js - 纯 JavaScript OCR 引擎
MIT
列出 OCR 支持的语言及其代码
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('list languages and codes') without revealing any behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, or what format the output takes. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence in Chinese that directly states the tool's function with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the core purpose immediately.
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?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is minimally complete for what it does. However, it lacks context about the output format (e.g., list structure, code format) and doesn't connect to the sibling tool 'recognize_text'. For a tool with no structured output documentation, the description should ideally provide more about what information is returned.
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 tool has zero parameters, and schema description coverage is 100% (empty schema is fully described as having no parameters). With no parameters to document, the description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate for zero-parameter tools.
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 clearly states the tool's purpose with a specific verb ('列出' meaning 'list') and resource ('OCR支持的语言及其代码' meaning 'OCR supported languages and their codes'). It distinguishes itself from the sibling 'recognize_text' by focusing on listing languages rather than performing text recognition. However, it doesn't explicitly differentiate from potential other language-related tools beyond the single sibling.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'recognize_text' or explain that this tool is for discovering available languages before performing OCR operations. There's no context about prerequisites, timing, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
识别图片中的文字内容（OCR）。支持中文、英文等多种语言。支持 PNG、JPG、JPEG、BMP、GIF、WebP 格式。
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的本地绝对路径，例如：/Users/xxx/Desktop/image.png | |
| languages | No | 识别语言代码数组，可选。默认 ["chi_sim", "eng"]（简体中文+英文）。可用语言：chi_sim(简中)、chi_tra(繁中)、eng(英文)、jpn(日文)、kor(韩文)等 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions support for languages and formats but does not describe what the tool returns (e.g., text output format, error handling), performance characteristics (e.g., speed, accuracy), or operational constraints (e.g., file size limits, authentication needs). This leaves significant gaps for a tool with no annotations.
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 concise and front-loaded, with two sentences that efficiently cover the core functionality, language support, and format support without any wasted words. Each sentence adds value, making it well-structured and easy to parse.
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?
Given the complexity of an OCR tool with no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., structured text, confidence scores), error cases, or behavioral traits like rate limits or dependencies. This makes it inadequate for guiding an agent in practical use beyond basic invocation.
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%, so the schema already fully documents both parameters. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when the schema handles all parameter documentation.
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 clearly states the tool's purpose with specific verbs ('识别图片中的文字内容') and resources ('图片'), and distinguishes it from its sibling 'list_ocr_languages' by focusing on text recognition rather than language listing. It specifies support for multiple languages and image formats, making the purpose explicit and differentiated.
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 implies usage by mentioning supported languages and image formats, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. It lacks guidance on prerequisites or specific contexts for optimal use, relying on implicit understanding from the purpose statement.
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.
v1.0.0list_ocr_languagesrecognize_textScored across 2 tools
The two tools have completely distinct purposes: one lists supported languages, while the other performs OCR text recognition. There is no overlap in functionality, making it impossible to confuse them.
Both tools follow a consistent verb_noun pattern (list_ocr_languages, recognize_text) with clear, descriptive names that align well with their functions. No deviations or mixed conventions are present.
With only 2 tools, the server feels thin for an OCR domain, as it lacks operations like batch processing, format conversion, or configuration management. While the core OCR function is covered, the scope is minimal and may limit agent workflows.
The server covers basic OCR functionality (list languages and recognize text), but there are notable gaps such as no tools for image preprocessing, batch OCR, or error handling. It provides a starting point but lacks comprehensive coverage for advanced OCR tasks.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for Qwen Image 3 AI image generation
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.