FixMyScan

Preview a scan

preview_scan

Idempotent

Show what FixMyScan will do before converting: before-and-after images of 3 pages of the user's own book. Use it when the user wants to see the result first. Give the same source as fix_scan, or the scan_id of a book not yet converted. The first call returns at once; call again with the scan_id after about ten seconds for the images. To convert after the preview, call fix_scan with upload_id set to the scan_id.

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": "preview_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
`scan_id`	No	The scan_id fix_scan or list_my_scans gave.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations say readOnlyHint=false and idempotentHint=true but give no clue why; the description supplies the crucial two-phase behavior: "The first call returns at once; call again with the scan_id after about ten seconds for the images." That polling pattern and the ~10 second wait cannot be inferred from any structured field and are essential to avoid an agent treating an empty first response as failure. It does not state that the preview creates a short-lived job (the reason readOnlyHint is false) or whether previews expire.

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?

Four sentences, each load-bearing: purpose and scope first, then the when-to-use, then the source argument, then the async pattern, then the follow-up conversion. Nothing is repeated from the schema and there is no filler.

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?

With no output schema, the description correctly takes on the return-value burden by promising before-and-after images of 3 pages, and it covers the two-call lifecycle for a 7-parameter nested-schema tool. What is missing is lifecycle detail an agent would want: whether the scan_id from the preview persists, and whether a preview costs processing time or quota.

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 all seven parameters are already documented, which sets the baseline at 3. The description does add real routing meaning the schema cannot express — the source may be "the same source as fix_scan" on the first call, and scan_id identifies "a book not yet converted" on the second call — but it does not clarify how the several mutually exclusive source parameters (file, source_url, upload_id, scan_id) interact or which wins if combined.

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?

"Show what FixMyScan will do before converting: before-and-after images of 3 pages of the user's own book" names a concrete verb (show/preview), the exact resource (before-and-after page images), and the scope (3 pages), which immediately separates it from the sibling fix_scan that actually converts. An agent can pick this tool without opening any 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?

"Use it when the user wants to see the result first" gives an explicit positive trigger and names the alternative (fix_scan) plus the exact parameter handoff ("upload_id set to the scan_id"). It stops short of an explicit negative case — nothing says to skip the preview and call fix_scan directly when the user already knows what they want — so it is clear but not fully exhaustive.

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?