Skip to main content
Glama

List stored scans

list_scans
Read-only

List stored document scans newest first with pagination, helping you find an earlier scan by reference or time before reading or deleting it.

Instructions

List the account's stored scans, most recent first, one page at a time. Inputs: the optional limit (1 to 100 rows, default 20) and cursor (the next_cursor of the previous page; omit it for the first page). Output: scans – one row per scan with id, status (recognized, unreadable, no_document_found, unsupported_document or rejected), billed, duration_ms, reference (your own string from the scan) and created_at – and next_cursor, which is null on the last page. A row holds no extracted data; call get_scan with its id for the full result. Calls GET /v1/scans; it 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. Under the public sandbox key the answer is an empty list, given without calling the API. Errors: a cursor this API did not issue is refused (validation_failed); a key the API does not know is refused (unauthorized). Use it to find a scan made earlier – by its reference or its time – before reading or deleting it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRows per page, 1 to 100 (default 20).
cursorNonext_cursor from the previous page; omit it for the first page.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scansYesThe account's scans, most recent first.
next_cursorYesOpaque cursor for the next page: send it back as `cursor` to continue after the last row of this one. Null on the last page.

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?

Annotations only cover read-only/open-world, but the description discloses what matters here: no credit charged, storage requires a live key under a non-zero retention window, retain_hours 0 means never stored, sandbox keys store nothing (public sandbox returns an empty list without an API call), key isolation per account, and the two error cases (validation_failed, unauthorized). This is far beyond what the annotations provide.

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 core action and organized into clear Inputs/Output/Errors segments, so it scans well. It is long and packs retention and key-mode details into run-on sentences, but nearly every clause carries decision-relevant information.

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?

Despite an output schema existing, the description covers the non-obvious completeness gaps for this tool: retention expiry, key scoping, sandbox behavior, and error semantics. Nothing an agent needs to call it 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% and the description largely restates it (limit 1–100 default 20, cursor as previous next_cursor). It adds only the paging model, not new format or edge-case semantics beyond the schema. Baseline 3 is appropriate.

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 ('List the account's stored scans'), adds ordering and pagination scope, and explicitly distinguishes itself from get_scan for the full result. An agent can tell this apart from its siblings without opening a 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?

Gives explicit when-to-use ('Use it to find a scan made earlier – by its reference or its time – before reading or deleting it') and names the alternative verb (call get_scan with its id). The routing condition is unambiguous.

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