Agent Tools UK

by app.railway.up.agent-tools-production-e6aa

Document to JSON (text + tables in one call)

document_to_json

Read-onlyIdempotent

Read a whole document in one call: all the text (OCR for scans and photos, exact text for digital PDFs) plus every table as rows of cells. Use when processing invoices, receipts, bank statements, contracts or reports and you need both the wording and the numbers. Send {url} or {base64}, optional lang. PDF or image, max 20 MB, 20 pages of text, 50 of tables. Returns {type, pages, method, text, tables:[{page, rows}]}. Errors: 400 bad input. Price: $0.02 USDC per call (x402).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "document_to_json"
  }
}

Input Schema

Name	Required	Description
`url`	No	Public URL of the file. Provide url OR base64.
`lang`	No	OCR language code(s), e.g. eng or eng+fra
`base64`	No	File contents, base64-encoded (max 20 MB). Provide url OR base64.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses the OCR-vs-digital-PDF method distinction, hard limits (20 MB, 20 pages text, 50 pages tables), the x402 payment model at $0.02 USDC per call, and the 400 error case. Those are exactly the operational facts an agent needs before committing a paid call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core capability, then usage, inputs, limits, return shape, errors, and price in a tight sequence with no filler. Every sentence carries distinct information despite the density.

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

Completeness5/5

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

With no output schema, the description compensates by naming the return shape ({type, pages, method, text, tables:[{page, rows}]}). Combined with limits, cost, and error behavior, nothing an agent needs to call this paid OCR/table tool correctly is missing.

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 coverage is 100%, so url/base64/lang are already documented, including the 'provide url OR base64' rule and the 20 MB cap. The description adds only the acceptable file types (PDF or image) and the fact that lang is optional; it does not clarify the url-vs-base64 precedence or lang defaults beyond what the schema states, so the baseline 3 is right.

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 opens with a specific verb and resource — 'Read a whole document in one call' — and immediately scopes it as 'all the text ... plus every table as rows of cells'. That scope distinguishes it from the narrower siblings ocr_read_text and pdf_tables_to_json without the agent needing to open either schema.

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 a concrete selection criterion — 'Use when processing invoices, receipts, bank statements, contracts or reports and you need both the wording and the numbers' — which effectively routes the agent away from text-only or table-only siblings. It stops short of naming those alternatives or stating when-not to use it (e.g. very large docs beyond page limits).

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

All Agent Tools UK tools Inspect

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

Need Help?