mcp_ocr

by timaliev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool is uniquely identified by a combination of task (text, layout, table, batch, formula, chart) and backend (vision, paddle, paddleocr_vl). The backend distinctions are clearly described, preventing confusion between same-task tools. The two extra tasks (formula, chart) are only available for the paddleocr_vl backend, adding no ambiguity.
Naming Consistency5/5
All tools follow a strict `ocr_<task>_<backend>` snake_case pattern. Every task and backend uses consistent vocabulary, making the naming scheme highly predictable and easy to navigate.
Tool Count5/5
14 tools is well within the ideal range for a multi-backend OCR server. The count reflects three backends with shared core tasks plus two backend-specific extras, each earning its place without bloat.
Completeness5/5
The tool surface covers the primary OCR workflows: text extraction, layout analysis, table extraction, and batch processing across backends. The paddleocr_vl backend adds specialized formula and chart extraction, filling the expected niches. No obvious dead ends or missing critical operations.
Average 3.7/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the backend, model size, hardware requirement (Apple Silicon), language support, and the prerequisite of the paddleocr-vl Swift CLI. However, it does not mention side effects, error behavior, or limitations beyond the hardware requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with the primary purpose in the first sentence and context in the second. Every sentence adds value, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks critical details about parameters and usage context, and there is no output schema. It provides useful backend/hardware context but leaves the agent without enough information to fully invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the three parameters (path, lang, mode). The parameter names are intuitive but the description does not clarify allowed values, defaults, or behavior, leaving agents to guess semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract mathematical formulas from an image. Returns LaTeX.' This uses a specific verb and resource, and the formula-focused scope distinguishes it from sibling OCR tools like text, layout, table, and chart extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no direct guidance on when to use this tool versus the many siblings. It mentions 'Most accurate' and 'supports tables/formulas/charts' but does not explicitly state when to prefer this backend or how it compares to alternatives, leaving the AI agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses external dependency (Swift CLI), platform requirement, and output format (CSV/JSON), which is useful. However, it does not mention whether the operation is read-only, potential side effects, error conditions, or performance characteristics, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then provides backend context in a second paragraph. It is reasonably concise, though the backend details could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no schema descriptions, no annotations, and no output schema, the description is not complete enough. It leaves lang and mode ambiguous and does not fully clarify prerequisites or behavior, making correct usage uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-specific meaning. The '109 languages' phrase hints at the lang parameter, but mode and path are not explained at all. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Extract tables from an image' clearly states the specific verb (extract) and resource (tables from an image), with output mentioned. The backend name 'paddleocr_vl' distinguishes it from sibling tools like ocr_table_paddle and ocr_table_vision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is the 'Most accurate' backend and supports 109 languages, implying it is the preferred choice for accuracy. It also specifies a prerequisite ('Requires paddleocr-vl Swift CLI') and platform limitation (Apple Silicon M1+). However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it returns structured data and requires the paddleocr-vl Swift CLI, and mentions multilingual support. However, it does not discuss failure modes, permissions, or the exact structure of the returned data, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose in the first sentence. The subsequent backend and requirement details are relevant and add value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having useful context (backend, accuracy, CLI requirement), the description lacks parameter explanations and an output format, and there is no output schema to compensate. For a tool with no annotations and sparse schema, this is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters (path, lang, mode). The only hint is 'from an image' implying path, but lang and mode are entirely unexplained. The description adds no parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract chart data from an image' with a specific verb and resource, and the backend info distinguishes it from sibling OCR tools. The tool name and description align, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: for chart extraction from images, with a note on the backend and accuracy. However, it doesn't explicitly mention alternatives or when-not-to-use, relying on the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It reveals return format (blocks with bounding boxes), backend type (CPU), maturity, and performance relative to Vision. However, it lacks details on error handling, unsupported languages, speed beyond 'slower,' or any side effects. The provided traits are useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states purpose and output, followed by a short paragraph on backend and performance. Every sentence adds value, no redundancy or fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params) and the absence of annotations and output schema, the description is incomplete. It lacks parameter explanations, return format details (e.g., coordinate structure), and does not help differentiate among the 14 sibling tools beyond the backend mention. It covers purpose and basic backend context but leaves significant gaps for effective selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (lang, mode, path) with no descriptions (0% schema coverage), and the tool description does not explain any of them. It does not clarify the meaning of 'lang' or 'mode', or specify acceptable values beyond defaults. The description fails to compensate for the absent schema descriptions, offering no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract text with layout analysis. Returns blocks with bounding boxes.' It specifies the resource (text with layout) and the output format, and further distinguishes it from siblings by naming the backend (PaddleOCR CPU) and comparing to Vision. This is a specific verb+resource statement that differentiates among the OCR family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual usage guidance: 'Wider language support than Vision, but slower' and 'Requires PaddleOCR Python package.' This helps choose between Paddle and Vision backends, and alerts to a prerequisite. However, it does not explicitly state when to use layout vs text vs table, or mention alternatives like paddleocr_vl, though these are implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description supplies meaningful behavioral context: consolidated results, CPU-based cross-platform operation, mature model, dependency requirements, and performance trade-offs. It stops short of detailing error handling or output structure, but adds substantial value beyond a bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs with no redundancy. The first sentence states the core purpose, and subsequent sentences deliver backend, comparison, and prerequisite info efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical information: parameter meanings (especially 'mode'), expected output details beyond 'consolidated results,' and any error or edge-case behavior. Without output schema or annotations, these gaps make the tool inadequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it only implies 'paths' via 'multiple images.' The 'lang' and 'mode' parameters are completely unexplained, leaving agents without knowledge of accepted values or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'OCR multiple images at once' with a specific verb and resource, and it distinguishes itself from siblings by highlighting 'Backend: paddle' and comparing 'Wider language support than Vision, but slower.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful selection guidance by comparing with Vision ('Wider language support... but slower') and noting the prerequisite 'Requires PaddleOCR Python package.' It implies when this tool is preferable (language coverage) and when alternatives might be faster, though it doesn't enumerate explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses backend details, output format (blocks with bounding boxes), language coverage, and a prerequisite CLI. Missing error behavior and performance caveats, but sufficient for a read-only extraction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, starts with the primary purpose, and gives backend specs in a dedicated sentence. No redundant wording; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output format and backend compatibility are covered, the tool has 3 undocumented parameters and no output schema. Significant gaps remain around mode values, lang usage, and detailed return structure, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations. lang and mode are entirely undocumented, and path is only implied as the input. The description fails to compensate for the missing schema metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool extracts text with layout analysis and returns blocks with bounding boxes. It names the backend (paddleocr_vl), which distinguishes it from sibling tools using other backends like paddle or vision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use it: most accurate, supports 109 languages, tables/formulas/charts, and requires paddleocr-vl Swift CLI. It implies preference for maximum accuracy and complex content, though it doesn't explicitly name sibling alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: backend, platform requirement, on-device inference, and output format. It does not mention error handling or side effects, but for a read-only OCR tool these are unlikely to be significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a one-sentence action statement followed by a compact backend/purpose note. Every sentence adds value with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description provides good operational context (backend, platform, language support), it omits explanations for parameters and does not cover usage modes or failure scenarios. Without an output schema or annotations, these gaps make the tool harder to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain any of the parameters (path, lang, mode) at all. The agent must infer their meaning solely from names, which is insufficient given the ambiguous 'mode' and 'lang' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract tables from an image.' It specifies the output format ('Returns structured CSV/JSON') and identifies the backend ('Apple Vision OCR'), which distinguishes it from sibling paddle and other OCR variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: 'Best for CJK + major European languages,' 'macOS 10.15+,' and 'Zero install on macOS,' implying when it is preferred. However, it does not explicitly mention alternatives or state when not to use this tool compared to paddle variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden and does well: it discloses the return structure (per-line confidence, bounding boxes), the backend, cross-platform maturity, and the need for a specific package. It also notes performance characteristics (slower than Vision). Missing details on error handling or side effects, but the disclosed behavioral traits go beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence gives the core function and return values; the second paragraph adds backend context, comparison to Vision, and a requirement. Every sentence provides useful information without redundancy, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and 3 parameters with no schema descriptions. The description provides a clear purpose and some behavioral context, but it omits parameter semantics (lang, mode), accepted values, and return format details. This is insufficient for fully correct invocation, especially given the absence of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters. While 'path' is implied by 'image', the meanings of 'lang' (language) and 'mode' (e.g., 'base') are not described. The description fails to compensate for the absence of schema descriptions, leaving the agent without necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 and resource: 'Extract text from an image.' It also details return values (full text, per-line confidence, bounding boxes) and specifies the backend ('paddle'), distinguishing it from sibling tools like ocr_text_vision or layout/table OCR variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides comparative guidance: 'Wider language support than Vision, but slower' indicates when to prefer this tool over the Vision-based alternative. It also mentions the requirement for the PaddleOCR Python package, which aids in setup. It does not explicitly exclude layout/table tools but the text-extraction focus is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output structure (full text, per-line confidence, bounding boxes), backend/model details (PaddleOCR-VL 0.9B), hardware requirement (Apple Silicon M1+), and external dependency (paddleocr-vl Swift CLI). It stops short of explicitly stating that the tool is read-only or how it handles errors, but the described behavior is transparent for a typical OCR read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loaded with purpose and output, then gives relevant backend context. Each sentence provides useful information without repetition. Slightly verbose in the backend block but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers output, backend, hardware, and dependencies, but lacks parameter semantics and explicit guidance on mode/lang behavior. Without an output schema, it compensates with output structure, but the missing param details leave the context incomplete for full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the parameters (path, lang, mode). It does not mention what lang or mode do, default values, or acceptable values. This is a critical gap for an agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Extract text from an image' and lists specific outputs (full text, per-line confidence, bounding boxes). It also names the backend (paddleocr_vl) and highlights differentiators (most accurate, 109 languages, supports tables/formulas/charts), which distinguishes it from sibling OCR tools like ocr_text_vision and ocr_text_paddle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by citing 'Most accurate, 109 languages, supports tables/formulas/charts' and noting the Apple Silicon requirement. However, it does not explicitly mention when to prefer alternatives or what trade-offs exist (e.g., speed vs accuracy). So clear context but no explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and delivers useful context: on-device GPU/ANE inference, macOS 10.15+ requirement, and supported language coverage. It also transparently states the return format, though it does not discuss failure modes or supported image input formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, leading with the core purpose and output, then adding backend and platform trade-offs. Each sentence provides meaningful information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, output, backend, and platform fit, which is adequate for a simple OCR tool at a high level. However, it omits important context such as what lang and mode control, what image formats are accepted, and any failure behaviors, leaving clear gaps given the absence of output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description itself gives no explanation of the meaning, allowed values, or acceptable formats for path, lang, or mode. The only parameter-related detail is the return format, which does not help an agent construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action, 'Extract text from an image', and clearly names the resource (images) plus the return payload (full text, per-line confidence, bounding boxes). It also distinguishes itself from sibling OCR tools by explicitly identifying the Apple Vision backend and the text vs. layout/table focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it is 'Best for CJK + major European languages' and 'Zero install on macOS', suggesting the intended environment. It does not explicitly name alternative tools like ocr_text_paddle or state when not to use this tool, so the guidelines lack exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and adds useful behavioral traits: requires 'paddleocr-vl Swift CLI', runs on 'Apple Silicon (M1+)', and returns consolidated results. It also notes performance characteristics (most accurate, supports tables/formulas/charts). It does not detail error handling or rate limits, but the disclosed prerequisites and capabilities are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the purpose in the first sentence and providing backend details in a second paragraph. No fluff, though the second paragraph could be slightly tighter. It earns its place and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides moderate context: it names the backend, requirements, and capabilities. However, it leaves out parameter explanations, output format (beyond 'consolidated results'), and practical details like supported file formats or how to configure lang/mode. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter clarity. It fails to explain 'paths', 'lang', or 'mode' explicitly. The phrase 'OCR multiple images at once' implies the role of paths, and '109 languages' hints at lang, but no concrete meaning is added for any parameter. This is a significant gap given the incomplete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'OCR multiple images at once' with 'Returns consolidated results.' It distinguishes from siblings by naming the backend 'paddleocr_vl' and mentioning batch processing, which differentiates it from single-image tools and other batch backends like ocr_batch_vision or ocr_batch_paddle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool: 'Most accurate, 109 languages, supports tables/formulas/charts.' This implies it is the preferred choice for high-accuracy or multi-language batch OCR tasks. It does not explicitly mention when not to use it or list alternative tools, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses backend details (Apple Vision, GPU/ANE inference), platform requirement (macOS 10.15+), language support, and that results are 'consolidated'. This adds meaningful context beyond the basic operation, though it does not detail output structure or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, then adds backend context in a separate section. Each sentence serves a purpose, but the backend details could be integrated more smoothly without affecting clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should reasonably explain return values and parameter usage. It covers the main functionality but leaves out specifics about the 'consolidated results' format and how to use 'lang' and 'mode', making it minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the parameters (paths, lang, mode). While 'paths' is self-explanatory, 'lang' and especially 'mode' remain ambiguous without any semantic detail beyond their default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'OCR multiple images at once' with a specific verb and resource scope. It distinguishes itself from siblings by emphasizing batch processing and the 'vision' backend, which aligns with the sibling names (ocr_batch_vision vs single-image variants and other backends).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when the tool is appropriate: 'Best for CJK + major European languages' and 'Zero install on macOS'. It implies a preference for Apple Vision over other backends, but does not explicitly mention alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses several behavioral traits: CPU-based execution ('PaddleOCR CPU'), cross-platform maturity, language support breadth relative to Vision, speed trade-offs, and a dependency. It doesn't cover error behavior or side effects, but for a read-only OCR extraction tool, these are less critical, and the provided details are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. The second sentence adds targeted context about the backend, performance, and dependency without redundancy. Every piece of information earns its place, and the whole is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear purpose and some backend context, the description leaves major gaps: it does not explain the 'mode' parameter, which is crucial for understanding extraction behavior, and it does not describe potential failure modes or output details beyond saying 'structured CSV/JSON.' With no output schema and no annotations, the overall picture is incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not. The parameters (path, lang, mode) are not explained. The only indirect hint is 'Wider language support,' which implies the lang parameter, but mode remains entirely unexplained. This is a significant gap for a tool with three parameters, especially since mode has a default and may control extraction behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Extract tables from an image.' It clearly states the output format (CSV/JSON) and names the backend ('paddle'), which differentiates it from sibling tools like ocr_table_vision and ocr_table_paddleocr_vl. The added comparison to 'Vision' reinforces its unique position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to prefer this tool: 'Wider language support than Vision, but slower.' This is a clear trade-off, and it also notes a prerequisite ('Requires PaddleOCR Python package'). However, it doesn't explicitly say when not to use it or mention alternatives beyond Vision, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return format, performance traits ('fast on-device GPU/ANE inference'), platform requirements, and language coverage. It does not mention failure modes or permission requirements, but for an OCR extraction tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, front-loading the core purpose and output, then adding backend/platform details. Every sentence contributes meaningful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, return format, backend, platform, and language support, which is strong for an OCR tool. However, it omits any parameter semantics and does not fully specify the block structure, so an agent might not know how to set 'mode' or interpret all returned fields. Given the absent annotations and output schema, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the three parameters (path, lang, mode). While path is self-explanatory and lang implies a language code, 'mode' remains completely ambiguous, leaving a significant gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Extract text with layout analysis.' It also specifies the output format ('Returns blocks with bounding boxes'), which immediately distinguishes it from plain-text OCR tools and other sibling backends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by naming the backend ('Apple Vision OCR'), platform ('macOS 10.15+'), and language support ('Best for CJK + major European languages'), plus 'Zero install on macOS.' This implies when to use this tool over alternatives, though it does not explicitly name Paddle or other alternatives as exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp_ocr MCP server](https://glama.ai/mcp/servers/timaliev/mcp_ocr/badges/card.svg)](https://glama.ai/mcp/servers/timaliev/mcp_ocr)

Score Badge

Copy to your README.md:

[![mcp_ocr MCP server](https://glama.ai/mcp/servers/timaliev/mcp_ocr/badges/score.svg)](https://glama.ai/mcp/servers/timaliev/mcp_ocr)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/timaliev/mcp_ocr'

If you have feedback or need assistance with the MCP directory API, please join our Discord server