Skip to main content
Glama

ocr

by com.auto-reader

ocr_image

Extract text from an image with GPU OCR. Best-in-class Arabic (plus Persian/Urdu) accuracy, manga-aware vertical Japanese, and strong English, French, Spanish, German, Chinese, Korean, Russian, Italian and Portuguese — 13+ languages. Automatic language and script detection with lang="auto". Returns reading-order layout text (right-to-left aware, paragraph-gapped) that is ready to feed an LLM or show a human, plus the detected language, the engine used, and the number of text blocks found. Provide the image as base64. Use the mode hint (document | receipt | manga | scene) to tune detection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoLanguage/script hint. Default "auto" detects it. Codes: ar, fa, ur, en, fr, es, de, ja, zh, ko, ru, it, pt.auto
modeNoContent hint that tunes detection and prompts. Default "document".document
api_keyNoOptional Auto-Reader OCR key (nsk_live_...). If omitted, a free trial key is auto-provisioned and returned to you in the result.
qualityNo"standard" (default) lets a confidence gate decide whether the vision model re-reads the page. "high" always re-reads it — use when accuracy matters more than cost or latency (costs 2 extra credits and adds a few seconds). You are charged the extra ONLY when it actually applies: check quality_applied in the result, and notice tells you why if it is false (receipt mode, a manga-engine page, an out-of-scope language, or the vision read failing its quality guards).standard
image_base64YesThe image encoded as base64 (a data: URI prefix is accepted and stripped).

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and delivers it: it reveals the reading-order output format, right-to-left awareness, paragraph gapping, detected language, engine, and text-block count. It also discloses that input must be base64 and that mode tunes detection, though it omits details like rate limits or data retention.

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 purpose and then moves through languages, detection, outputs, and input requirements without repetition. It is slightly long due to the language enumeration and marketing terms like 'Best-in-class', but every sentence contributes information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description's return-value explanation (text plus detected language, engine, block count) is essential and present. Combined with a fully described parameter schema, the agent has enough to invoke the tool correctly, though error behavior and cost implications of quality are left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including lang, mode, quality, api_key, and image_base64. The description adds only light reconfirmation ('Provide the image as base64', 'Use the mode hint') without materially extending the schema's 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 opening verb phrase 'Extract text from an image with GPU OCR' is specific about action and resource, and the language and layout details make it distinct from sibling tools like read_manga or ocr_and_translate. The description also clarifies the return object (text plus detected language, engine, block count), leaving no ambiguity about the tool's core function.

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 clear context: it handles 13+ languages, auto-detects script, and returns LLM-ready layout text, which implies use when OCR text from an image is needed. It does not explicitly name alternatives or exclusion criteria, so it stops one step short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ocr toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: key provisioning, structured extraction, usage checking, combined OCR+translation, plain OCR, and translation. No overlap that would confuse an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., create_api_key, ocr_image, translate_text). Even the compound name 'ocr_and_translate' fits the pattern.

Tool Count5/5

With 6 tools, the server is well-scoped for an OCR service, covering key management, usage monitoring, multiple OCR modes, structured extraction, and translation without being over-fragmented.

Completeness4/5

The tool set covers core OCR workflows well, but lacks a tool for revoking API keys or listing existing keys, which is a minor gap for full lifecycle management.

Resources