Skip to main content
Glama
Sign In
mcp_ocr

mcp_ocr

by timaliev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ocr_text_xiaomi

Extract text from images with Xiaomi-OCR-0, returning text, confidence, and bounding boxes. Parses documents into Markdown, tables, and formulas.

Instructions

Extract text from an image. Returns full text, per-line confidence, and bounding boxes.

Backend: xiaomi. Xiaomi-OCR-0 — local 0.8B document-parsing VLM (transformers; Apple Silicon MPS, CUDA or CPU). Best structure fidelity: Markdown output, HTML tables, LaTeX formulas, key-information extraction. Strong on Cyrillic, English, German and Japanese; Arabic/Korean are weak.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "ocr_text_xiaomi"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.2

TDQS

B3.4/5.0
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 and does add real behavioral context: it is a local 0.8B transformers VLM, runs on Apple Silicon MPS/CUDA/CPU, and returns confidence plus bounding boxes. It omits operational traits an agent would care about, such as latency expectations, image format/size limits, and whether the model must be downloaded first.

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 behavioral summary is front-loaded in the first sentence, with backend details correctly relegated to a second paragraph. The model/language notes are dense but each clause aids model selection; slightly tighter phrasing would earn a 5.

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?

There is no output schema, and the description partly compensates by enumerating the return fields, which is a genuine plus. However, for a tool whose only input is an undocumented `path`, the definition leaves the single most important call detail unspecified, so it is only adequate.

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?

The single parameter `path` has 0% schema description coverage, so the description must compensate — but it never mentions the parameter at all. Nothing clarifies whether the path is a local filesystem path, a URL, or a relative reference, which is the one ambiguity that could cause a failed call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ("Extract text from an image") and states the return shape (full text, per-line confidence, bounding boxes). The backend paragraph adds model identity and quality positioning ("Best structure fidelity"), which hints at how it differs from ocr_text_paddle and ocr_text_vision, but it never explicitly names or contrasts those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this is the structure-fidelity/Markdown-leaning text extractor, and that Cyrillic/English/German/Japanese are preferred over Arabic/Korean. There is no explicit "use this instead of ocr_text_paddle when..." routing and no statement of exclusions, so the guidance requires inference across a 15-tool sibling set.

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

Deploy Server

Other Tools