Skip to main content
Glama

Recognise a passport or ID document

scan_document
Idempotent

Extract printed fields and MRZ from passports, ID cards, or driver's licences in a photo or scan, returning structured JSON for identity checks.

Instructions

Recognise a passport, national ID card or driver's licence from a photo or scan and return what is printed on it as structured JSON. Inputs: the image as image_base64 (always available), image_path (a local file, and only inside the directory DOC_CHEAP_IMAGE_ROOT names) or image_url (https, on a public address); plus the optional expect_country, return_portrait, retain_hours, reference and idempotency_key. Output: a Scan object – meta (id, status, billed, confidence, timing), document (kind, issuing country, number, series, date of issue, date of expiry, whether it has expired and how many days are left), holder (given names, surname, date of birth, sex, nationality), fields (every field read off the printed page, each with its own confidence), mrz (whether the machine-readable zone checks out, why not when it does not, and its lines exactly as read), images, quality and authenticity – plus a one-line summary of the same result. Calls POST /v1/scans. Cost: it bills one credit ($0.01) only when a document is recognised; an unreadable image, an empty frame or an unsupported type costs nothing, and meta.billed says which happened. Without a key, the public sandbox key is used. It gives 10 free recognised documents per address in all, and at most 10 requests per address an hour, whatever their answer. Registering gives 100 free documents every month. Use it whenever someone hands over an identity document and wants it read, transcribed, or checked against what they claim – a name, a document number, a date of birth or an expiry date.

Input Schema

NameRequiredDescriptionDefault
image_urlNohttps: URL of an image on a public internet address, which the server fetches (25 MB maximum).
referenceNoYour own correlation string, echoed back in the result.
image_pathNoPath to a local image file, inside the directory named by DOC_CHEAP_IMAGE_ROOT. Disabled unless that variable is set; send image_base64 instead.
image_base64NoThe document image as base64 (a data: URL is also accepted).
retain_hoursNoHours the result stays readable via GET /v1/scans/{id} (0 = store nothing). Omit it to use the account's own history-retention setting.
expect_countryNoISO 3166-1 alpha-3 country you expect, or omit for any.
idempotency_keyNoMakes a retried scan return the first result instead of charging again.
return_portraitNoWhether to include the holder photograph crop, images.main_photo (default true).

Output 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. Changed2 schema fields changedv0.3.8
    • changedOutput schema / definitions / ScanField / properties / language / description
      Previous value: -"The language this reading was made in, e.g. `Greek`; null for the neutral, transliterated Latin reading."New value: +"The language this reading was made in, e.g. `Greek`. The default Latin-script reading – the document's own Latin page and the machine-readable zone, `id` suffix `@0` – is `English`. Null only on `days_to_expire`, a number computed from the expiry date rather than text read in any language."
    • changedOutput schema / definitions / ScanField / properties / value / description
      Previous value: -"The value of this reading: the national-script spelling when `language` names one, the transliterated Latin value otherwise. Null when the field is empty."New value: +"The value of this reading: the national-script spelling on a national-script reading, the transliterated Latin value on the default reading (the one whose `id` carries the identifier `0`). Null when the field is empty."
  2. First observedv0.3.7

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations: billing is stated precisely (one credit only on successful recognition, free on unreadable/empty/unsupported), rate limits are disclosed (10 free recognised docs per address total, 10 requests/hour), the sandbox fallback is explained, and idempotency behaviour is described alongside its key. This is exactly the extra context annotations cannot carry.

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

Conciseness3/5

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

Purpose is front-loaded, but the paragraph then enumerates every output field (meta, document, holder, fields, mrz, images, quality, authenticity) even though an output schema exists, which is redundant bulk. The single dense block would be easier to scan if the usage trigger and billing facts were separated.

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 open-world, billed, rate-limited mutation tool, the description covers cost, throttling, auth fallback, idempotency and the trigger condition. With an output schema present it need not detail returns further, so nothing essential 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 description coverage is 100%, so the schema already documents all eight parameters, giving a baseline of 3. The description enumerates the same parameters and reinforces the image_path root constraint, but adds no syntax, format or default detail the schema lacks.

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?

Names a specific verb (recognise) and resource (passport, national ID card, driver's licence) and states the return form (structured JSON). It is trivially distinguishable from the CRUD-style siblings (list_scans, get_scan, delete_scan, check_balance, search_docs).

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?

The final sentence gives a clear situational trigger: 'whenever someone hands over an identity document and wants it read, transcribed, or checked against what they claim.' It does not, however, explicitly route the agent away from search_docs or contrast with other read tools, so it stops short of full alternative-naming.

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