Skip to main content
Glama

Delete a stored scan

delete_scan
DestructiveIdempotent

Permanently remove a stored scan's result, history and thumbnail before its retention window ends. Verify the id with list_scans or get_scan first, since deletion is final and credits are not refunded.

Instructions

Permanently delete one stored scan now, before its retention window would end. This cannot be undone: the stored result, its history row and its thumbnail are removed, and the scan can no longer be listed, fetched or replayed through its idempotency_key. The credit it drew is not refunded, and this period's usage counters still count it. Input: scan_id – meta.id of a scan_document result, or id of a list_scans row. Output: { id, deleted: true }. Calls DELETE /v1/scans/{id}. 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, has passed its window or was already deleted is refused as not_found, and nothing is deleted. Use it when someone asks for a document's data to be removed; confirm the id with list_scans or get_scan first, because the deletion is final.

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
idYes
deletedYesAlways true: the stored result is gone and cannot be read back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.8

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by disclosing exact side effects (result, history row, thumbnail removed), non-refund of credit, continued usage-counter counting, and the not_found error semantics for refused ids. Retention-window and key-scoping rules add operational context the annotations cannot express.

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?

The irreversible consequence is front-loaded in the first sentence, and every clause carries operational value. It is long, but the retention and sandbox rules are genuinely non-obvious rather than filler, so trimming would lose meaning.

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?

With an output schema present, the description still usefully states the return shape ({ id, deleted: true }), and covers side effects, error conditions, retention/sandbox scoping, and pre-call confirmation. 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds provenance beyond the schema by mapping scan_id to 'meta.id of a scan_document result, or id of a list_scans row' and noting the id can no longer be replayed via its idempotency_key. The UUID format itself is left to the schema pattern.

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 precise verb+resource ('Permanently delete one stored scan') and immediately frames it against siblings by describing the removal of the stored result, history row, and thumbnail. An agent can distinguish this from get_scan/list_scans/scan_document without opening another 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?

Explicitly states the triggering condition ('Use it when someone asks for a document's data to be removed') and names the confirmation alternatives ('confirm the id with list_scans or get_scan first'). It also gives the when-not boundary: unknown, other-account, expired, or already-deleted ids are refused.

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