Skip to main content
Glama

Fetch a stored scan

get_scan
Read-only

Fetch a stored scan result by its ID to read back recognised document fields and MRZ without re-running recognition.

Instructions

Fetch the full result of one stored scan by its id, as it was returned when the document was recognised. Input: scan_id – meta.id of a scan_document result, or id of a list_scans row. Output: the same Scan object scan_document returns (meta, document, holder, fields, mrz and the rest) plus a one-line summary, with two differences: the image crops are never stored, so every images slot is null, and quality reads not_checked. Calls GET /v1/scans/{id}; it never re-runs recognition and never charges a credit. Only scans made with a live key under a non-zero retention window are stored, and only until that window ends (retain_hours on the scan, or the account's history-retention setting, one year by default); a scan made with retain_hours 0 was never stored. A key reaches its own account's scans and no other account's. Under a sandbox key – the public one or an account's own sk_sandbox_ key – nothing is stored. Errors: an id that is unknown, belongs to another account, was made with retain_hours 0 or has passed its window is refused as not_found – the cases are not told apart. Use it to read back a document recognised earlier instead of scanning the image again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scan_idYesThe scan's id: meta.id of the scan_document result, or id of a list_scans row (a lower-case UUID).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
mrzYes
metaYes
fieldsYesEvery field the engine extracted off the printed document, re-keyed to our vocabulary – the open set. Always present; empty when nothing was extracted. A field read in more than one language appears once per language, so `name` repeats and only `id` is unique.
holderYes
imagesYes
qualityYes
documentYes
authenticityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.8

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: no re-recognition, no credit charge, per-account isolation, sandbox non-storage, retention-window semantics with a one-year default, and the deliberate not_found collapsing of four distinct error cases. It even discloses two output deviations (images slots null, quality not_checked) that an agent would otherwise misread as data errors.

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-loads purpose, input, and output before the retention and error caveats, and nearly every sentence carries load-bearing information. It is somewhat dense and run-on, with mild redundancy between 'as it was returned when the document was recognised' and 'never re-runs recognition,' which keeps it from a 5.

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?

Covers the full lifecycle an agent needs: id provenance, output shape and its deviations, storage/retention preconditions, key-scoping rules, and error semantics. Since an output schema exists, the description is not obligated to enumerate return fields, and it still flags the two fields that differ.

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 UUID pattern and meaning of scan_id are already fully documented in the schema, and the description largely repeats the same sourcing (meta.id of scan_document, id of list_scans row). Baseline 3 is appropriate since the description adds no format or edge-case detail beyond the schema.

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 with scope: 'Fetch the full result of one stored scan by its id, as it was returned when the document was recognised.' It implicitly distinguishes itself from scan_document (no re-recognition) and list_scans (single row vs. list), and names the exact id source for each.

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?

Explicitly routes the agent: 'Use it to read back a document recognised earlier instead of scanning the image again,' which names the alternative (scan_document) and the condition selecting this tool. It also states when the tool is NOT applicable – scans made with retain_hours 0, sandbox keys, or past the retention window – so the agent can predict failures before calling.

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