Skip to main content
Glama

retention

Find active records exceeding a maximum age and, when apply is enabled, hard-delete them to enforce storage limitations, with dry-run review and auditable tombstones.

Instructions

STORAGE-LIMITATION enforcement (GDPR Art. 5(1)(e); read-only unless apply=True): find ACTIVE records older than max_age_days and, with apply=True, hard-delete them — each erasure leaving a tombstone, signed when this server holds the store's receipt key (see where_am_i), so the enforcement is itself auditable. DRY-RUN by default: returns {eligible, ids, applied, erased} so you review before enforcing. pii_only (default True) restricts to PII-tagged records.

basis and request_id are recorded with each erasure (Art.30). Neither was on this surface, so a retention sweep run over MCP produced tombstones with no stated ground and no ticket to trace them to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applyNo
basisNo
pii_onlyNo
request_idNo
max_age_daysYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.20.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it flags read-only unless apply=True, admits hard-deletion, states that each erasure leaves a signed tombstone when applicable, and warns that omitting basis/request_id degrades auditability.

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 main behavior is front-loaded and the additional paragraphs earn their place by explaining destructive side effects, audit trail behavior, and why basis/request_id are important. It is dense but not redundant; a little trimming of the historical rationale would make it tighter.

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?

For a destructive tool with no output schema and no annotations, the description is strong: it names the return object, the side effect, and the audit implications. It could define 'ACTIVE' more precisely and state any limits/error behavior, but nothing essential to a first safe call 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 description coverage is 0%, so the description must explain the parameters; it covers max_age_days, apply, pii_only, basis, and request_id. It gives the purpose of each and explains why basis/request_id matter, though it does not specify expected value formats.

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?

The description states the operation with a specific verb and resource: find ACTIVE records older than max_age_days and, with apply=True, hard-delete them. It also frames this as storage-limitation enforcement (GDPR Art. 5(1)(e)), distinguishing it from reporting tools like erasure_report or per-record forget tools.

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?

It gives clear operational guidance: dry-run by default, review {eligible, ids, applied, erased} before enforcing, and pii_only defaults to restricting to PII-tagged records. It does not explicitly name sibling alternatives or exclusion conditions, but the when/how context is clear.

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

Deploy Server

Other Tools