FixMyScan

Fix a scanned book

fix_scan

Idempotent

Turn a scanned book (PDF or DjVu, up to 1,000 pages) into a clean, searchable PDF for e-readers: pages cropped to the text, straightened, sharp black and white, two-page spreads split, and searchable text added. Use it when the user wants to fix, clean up, OCR or convert a scan for a Kindle, Kobo, reMarkable or tablet. Give exactly one source: file (a file the user attached here), source_url (a public https link to the file) or upload_id (from create_upload_link, after the user uploaded). It returns a scan_id at once and the book converts in the background; then call get_scan_status until it is ready and give the user the download link.

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": "fix_scan"
  }
}

Input Schema

Name	Required	Description	Default
`file`	No	A PDF or DjVu file the user attached in this chat.
`output`	No	bw: sharp black and white, best on e-ink. grey: gentle greyscale.	bw
`language`	No	The book's language for searchable text, as a Tesseract code; auto detects it.	auto
`upload_id`	No	The upload_id from create_upload_link, once the user has uploaded the file.
`source_url`	No	A public https link to the PDF or DjVu file.
`trim_margins`	No	Crop each page to its text block. Covers and picture pages stay whole.
`split_spreads`	No	Split scans of two facing pages into single pages.
`idempotency_key`	No	Optional. Repeat it on a retry so the same book is not started twice.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare openWorldHint, idempotentHint and destructiveHint=false, so safety is covered; the description still adds genuinely new behavior: a 1,000-page cap, the exact page transformations (crop, straighten, B/W, split spreads, OCR), and the asynchronous job model where a scan_id returns immediately and work continues in the background. It does not mention rate limits or what happens to the source file, so it stops short of 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.

Conciseness4/5

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

Front-loaded with the outcome and the transformation list, then the usage trigger, then the required input pattern, then the async follow-up. Every sentence carries operational information, though the device list ('Kindle, Kobo, reMarkable or tablet') slightly duplicates the e-reader framing.

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?

For an 8-parameter asynchronous mutation with no output schema, the description covers the input one-of rule, the size limit, the conversion behavior, and the mandatory hand-off to get_scan_status for the download link. An agent has everything needed to invoke it correctly and continue the workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds a constraint the schema does not encode: 'Give exactly one source' among file, source_url and upload_id, which the schema lists as zero-required, non-exclusive properties. It also clarifies that upload_id comes only after the user has uploaded via create_upload_link, and when to use each source, exceeding what the field descriptions alone convey.

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?

States a specific verb and resource ('Turn a scanned book ... into a clean, searchable PDF') plus the exact transformations applied, and the PDF/DjVu input formats. It is clearly distinguishable from siblings like preview_scan and get_scan_status, which a reader can route away from without opening 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 Guidelines5/5

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

'Use it when the user wants to fix, clean up, OCR or convert a scan for a Kindle, Kobo, reMarkable or tablet' gives an explicit trigger, and the description names create_upload_link as the prerequisite for upload_id and get_scan_status as the follow-up step. The only missing piece is an explicit when-not-to-use statement, but the workflow routing effectively supplies it.

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

All FixMyScan 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?