Skip to main content
Glama
Sign In

Ocrspace

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Extract Text

extract_text
Read-onlyIdempotent

Extract text from an image or PDF via OCR — pass an image/PDF URL, get the recognized text. Useful for reading screenshots, scanned documents, receipts, signs. Engine 2 is best for most cases.

Input Schema

NameRequiredDescriptionDefault
engineNoOCR engine to use: 1, 2, or 3 (default 2). Engine 2 is best for most cases.
_apiKeyNoOptional — your own OCR.space API key for higher limits; omit to use the shared Pipeworx key.
filetypeNoForce the file type instead of letting OCR.space infer it: 'PDF', 'GIF', 'PNG', 'JPG', 'TIF', 'BMP' or 'WEBP'. Inferred from the URL's extension when omitted. Supply it when the URL has no extension (a signed link, a redirect, an API endpoint) — without it OCR.space refuses with E216 rather than guessing.
is_tableNoSet true to improve layout detection for tables/receipts (default false).
languageNoLanguage code for OCR (default 'eng'). Examples: 'eng', 'fre', 'ger', 'spa'.
image_urlYesURL of an image or PDF to run OCR on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "image_url": "https://example.com/receipt.jpg"
-  },
-  {
-    "_apiKey": "your-ocrspace-api-key",
-    "engine": 2,
-    "image_url": "https://example.com/document.pdf",
-    "is_table": true,
-    "language": "fre"
-  }
-]New value: +[
+  {
+    "image_url": "https://example.com/receipt.jpg"
+  },
+  {
+    "engine": 2,
+    "image_url": "https://example.com/document.pdf",
+    "is_table": true,
+    "language": "fre"
+  }
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / filetype
      Added value: +{
+  "description": "Force the file type instead of letting OCR.space infer it: 'PDF', 'GIF', 'PNG', 'JPG', 'TIF', 'BMP' or 'WEBP'. Inferred from the URL's extension when omitted. Supply it when the URL has no extension (a signed link, a redirect, an API endpoint) — without it OCR.space refuses with E216 rather than guessing.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "image_url": "https://example.com/receipt.jpg"
+  },
+  {
+    "_apiKey": "your-ocrspace-api-key",
+    "engine": 2,
+    "image_url": "https://example.com/document.pdf",
+    "is_table": true,
+    "language": "fre"
+  }
+]
  4. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the output is recognized text and suggests engine 2, but it does not describe rate limits, authentication behavior beyond the schema's _apiKey note, or error handling (e.g., E216 for missing filetype, which the schema mentions).

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 short, front-loaded, and easy to scan across three tight sentences. The final sentence repeats the schema's engine recommendation, so not every sentence adds unique value.

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?

For a read-only OCR tool with full input schema coverage and no output schema, the description supplies what is needed: input URL, OCR mechanism, output text, and typical use cases. It could mention output format or error behavior, but those are secondary given the structured fields already provided.

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 fully documents all six parameters, including examples and constraints. The description's only parameter-related remark — 'Engine 2 is best for most cases' — duplicates the schema's engine description and adds no new syntax or format 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 names a specific verb and resource — 'Extract text from an image or PDF via OCR' — and clarifies both input (URL) and output (recognized text). It distinguishes the tool clearly from all listed siblings, none of which perform OCR.

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 gives clear use-case context ('screenshots, scanned documents, receipts, signs'), which helps an agent decide when this tool applies. It does not, however, state when not to use it or name alternatives, but no sibling provides OCR, so the omission is minor.

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

All Ocrspace toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources