Hebrew and English OCR for PDFs and images: text, key fields and tables, page by page.
Scored across 3 tools
The three tools have clearly distinct purposes: reading documents, checking remaining pages, and purchasing more pages. There is no meaningful overlap in action or resource, so an agent can select the right tool without confusion.
All tool names follow a consistent snake_case verb_noun pattern: buy_pages, check_balance, read_document. The convention is predictable and descriptive across the entire set.
Three tools are well-matched to the narrow OCR-and-billing domain. Each tool covers a necessary workflow step without adding redundant or speculative operations.
The surface covers the full core lifecycle: read documents, check page balance, and buy more pages. No obvious operational gaps or dead ends exist for the stated OCR service purpose.
Return a Stripe Checkout link for a page pack. Give the link to your user: they pay in their browser, and the pages are added to this key's account as soon as the payment completes. This tool never charges anything by itself.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | p100: 100 pages ($9 / ₪29); p500: 500 pages ($29 / ₪99); p2000: 2000 pages ($89 / ₪299) | |
| currency | No | Default: USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by clarifying 'This tool never charges anything by itself,' resolving the obvious ambiguity of a tool named 'buy'. It adds genuine behavioral context — payment happens in the user's browser and pages are credited to this key's account only after payment completes. It omits link expiry or failure handling, keeping it from a 5.
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?
Three short sentences, front-loaded with the return value, then the agent action, then the safety clarification. Nothing is redundant or wasted.
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, no-output-schema tool, the description covers what is returned (a link), who acts on it, and when the side effect lands. Only edge details like link expiry or what to do if the user abandons checkout are missing.
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 coverage is 100% and both parameters are enums with inline pricing detail, so the description adds no param-level meaning beyond the schema. Baseline 3 is appropriate since the schema carries the full burden.
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?
States a specific verb and resource ('Return a Stripe Checkout link for a page pack') and describes the resulting flow, which makes it unmistakable against siblings like check_balance or read_document.
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?
Explicitly instructs the agent what to do with the result ('Give the link to your user: they pay in their browser'), which is the key usage context. It lacks explicit when-not-to-use guidance or naming of alternatives, but the siblings are functionally distant enough that this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many pages the API key's account can still read, and a link where the user can add pages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, closed-world operation, so the safety profile is covered. The description usefully adds that a purchase link is returned alongside the count, but with no output schema it could say more about the response (for example, whether the link is pre-authenticated or time-limited) and says nothing about quota reset behavior.
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?
A single compact sentence that front-loads the primary value (remaining pages) and appends the secondary return element (the add-pages link). Nothing is wasted.
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 zero-argument read tool with no output schema, the definition covers what the agent gets back and the scope (the API key's account). It falls short only on operational details such as how the count refreshes or whether the link requires additional auth.
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?
The tool takes zero parameters, so the baseline is 4; there is no argument semantics to explain and the description correctly spends no words on inputs.
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 concrete resource and result: the number of pages the API key's account can still read, plus a link to add pages. That is specific enough to distinguish it from read_document, though it never names buy_pages as the action path even while alluding to it via the 'link where the user can add pages'.
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?
Usage is only implied: you would call this to check remaining quota before reading or before hitting a limit. There is no explicit when-to-use statement, no threshold guidance, and no instruction to use buy_pages rather than the returned link, leaving the boundary with that sibling fuzzy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a PDF or an image (JPEG, PNG, WebP) and return its text, its key fields (vendor, dates, totals, VAT, ids…) and its tables, page by page. Built for Hebrew and English documents, including mixed right-to-left lines. Costs one page from the key's account per page read; a page that fails is not charged. Up to 20 pages per call: read longer PDFs in ranges with "pages". A call of many pages can take more than a minute. Pages your client stops waiting for may still be charged, so if a call times out, read smaller ranges, for example 5 pages per call.
| Name | Required | Description | Default |
|---|---|---|---|
| hint | No | What the document is, if known. Default: auto. | |
| pages | No | PDF pages to read, for example "1-5,8". Default: from page 1, up to the per-call limit. | |
| file_url | No | A public https URL of the document. Use this or file_base64. | |
| language | No | Language of the field labels and summary in the result. Default: en. | |
| file_base64 | No | The document's bytes, base64-encoded. Use this or file_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing metering (one page from the key's account per page read), that failed pages are not charged, that pages the client abandons may still be charged, a >1-minute latency warning, and the 20-page per-call ceiling. This also explains why readOnlyHint is false for a read-shaped tool: the call consumes credit. No contradiction with the supplied hints.
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?
Front-loaded with capability and return shape, then cost, then limit, then timeout workaround — a sensible order. The final sentence is somewhat redundant with the earlier range advice but carries the non-obvious billing consequence, so the length is largely earned.
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?
With no output schema, the description carries the return contract itself and does so (text, key fields, tables, per page). Combined with the credit model, page ceiling, latency and timeout guidance, an agent has everything needed to call it correctly and to recover from failure.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning for "pages" by tying it to the 20-page per-call cap and recommending 5-page ranges on timeouts, and it frames "language" as controlling field-label and summary language in the result. The "hint" and file-source parameters are left entirely to 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?
States a specific verb and resource (read a document) plus the accepted formats (PDF, JPEG, PNG, WebP) and exactly what comes back: text, key fields such as vendor/dates/totals/VAT/ids, and tables, page by page. Nothing about it overlaps with buy_pages or check_balance, so the agent can route correctly from the description alone.
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?
Gives concrete operating guidance: use "pages" to read long PDFs in ranges, cap at 20 pages per call, and shrink ranges to about 5 pages on timeouts. It does not explicitly say when to prefer buy_pages or check_balance (e.g., on an out-of-credit failure), so it is clear context without stated alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buy_pagescheck_balanceread_documentOCR, editable Word, tables, translation and data extraction for Arabic-script documents
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Arabic-first OCR, translation and document extraction. First call mints a free trial key.
OCR text from images and scanned PDFs; pay-per-event via your Apify account.
Add one secure layer between your agents and this server.
