LensaOCR
Server Details
Tesseract-compatible OCR over HTTP: send an image, get its text and word boxes in Tesseract's...
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusing it with another tool; its purpose (extract text/word boxes from an image) is unambiguous. No overlapping or competing capabilities exist in the set.
The lone name 'ocr' is a bare noun/acronym rather than a verb_noun pattern like extract_text or read_image, so it doesn't exemplify a predictable convention. However, with only one tool there is no inconsistency to penalize heavily.
A one-tool server is thin even for a narrow OCR utility; agents get no options for batch processing, language selection, or preprocessing. It is coherent as a single-purpose wrapper but borderline minimal.
Reading text and word boxes with multiple output formats (txt, TSV, hOCR, ALTO) covers the core OCR output surface well. However, there are no tools or parameters for language/model control, batch images, or image preprocessing, leaving notable gaps for real OCR workflows.
Available Tools
1 toolocrReads an image's text and word boxes (Tesseract txt, TSV, hOCR and ALTO)BInspect
Reads an image's text and word boxes (Tesseract txt, TSV, hOCR and ALTO). Price: $0.005 a call.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | The answer's format: text (default), tsv, hocr, alto or words | |
| image_base64 | Yes | A PNG image (up to 5 MB), base64-encoded |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add one genuinely useful behavioral fact: the $0.005 per-call cost, which agents cannot infer from structured fields. It nonetheless omits language support, accuracy limits, failure modes, and what the returned formats contain.
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, front-loaded with the core capability and followed by the pricing fact. No filler, no restated boilerplate beyond the title overlap.
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 two-parameter tool with full schema coverage this is minimally adequate, but with no output schema the description should say more about what each format returns and what errors or limits apply. The missing 'words' format leaves the format contract underspecified.
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 both parameters are already documented in the schema, setting the baseline at 3. The description lists four of the five format values but never explains what 'words' returns or how the encodings differ, so it adds little beyond the 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 states a specific verb (reads) and resource (an image's text and word boxes) and enumerates the output encodings, which is far clearer than the bare name 'ocr'. However, the first sentence is essentially verbatim the title, and it omits the 'words' format that the enum exposes.
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?
There is no guidance on when to use this tool, what kinds of images it handles, or any preconditions beyond the schema's 5 MB PNG note. The only added guidance-like content is the price line, which is cost information rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
ocr
Related MCP Connectors
OCR.space MCP — wraps the OCR.space API (ocr.space) for image/PDF → text OCR.
Arabic-first OCR, translation and document extraction. First call mints a free trial key.
OCR for images and Korean ID documents
Render HTML and CSS to PNG images over HTTP. Send HTML and CSS and get a PNG back.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceOCR.space MCP server that enables image and PDF text extraction via the OCR.space API.375 npmMIT
- FlicenseAqualityBmaintenanceDocument-engineering MCP tool server providing tools for PDF, Office, Images, and Archives extraction and conversion. It never mutates source files and requires local tesseract for OCR.12-
- AlicenseAqualityDmaintenanceHigh-performance OCR MCP server supporting multiple input modes (path, base64, URL, upload), batch processing, and output formats like plain, JSON, and Markdown.42MIT
- AlicenseNot gradedqualityDmaintenanceHigh-performance OCR server using native Tesseract (C++) for text extraction from images, integrable with ChatGPT Desktop and other MCP clients.11MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.