Skip to main content
Glama

purge_expired_plaintext

Bulk-purge your account's plaintext records older than a specified number of days. Preview with dryRun mode first, then get human approval and execute.

Instructions

Bulk-purge your account's plaintext records older than olderThanDays (POST /v1/tier2/plaintext/purge-expired). Consistent with the Terms of Service v2.1 "retainable up to 90 days" (automatic retention); an AI agent can finish "auto-purge plaintext older than 30 days" in one prompt. dryRun=true (the safe default to reach for) returns the count plus 5 sample call_ids; dryRun=false performs the actual UPDATE. Emit-then-UPDATE ordering plus a deterministic idempotencyId (sha1(endpoint+accountId+olderThanDays+cutoff_date)) gives webhook-retry-equivalent semantics. Pro+ plan only (Free gets 403). An actual purge (dryRun=false) requires approvalId — obtain human approval via request_approval (action: 'purge_expired_plaintext') first, because NULLing plaintext is irreversible. Only your own account is purged. Returns (dryRun=true) { dryRun: true, targetCount, cutoffTimestamp, olderThanDays, sampleTargetCallIds }; (dryRun=false) { dryRun: false, purgedCount, cutoffTimestamp, olderThanDays, purgedAt }. Audit: emits tier2.purge_expired_plaintext.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dryRunNotrue = preview only (zero mutation); false = actual UPDATE. Default false (MCP discipline recommends passing dryRun explicitly)
approvalIdNoApproval id granted via request_approval (apr_ + 32 hex; create with action 'purge_expired_plaintext'). When passed, the server verifies approved + within expiry + action match + unconsumed, and atomically consumes it on the actual purge (1 approval = 1 execution). dryRun only verifies without consuming
olderThanDaysNoAge threshold in days for purging (1-365, default 30; consistent with the Terms of Service v2.1)
Behavior5/5

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

The description fully discloses behavioral traits: irreversibility (NULLing plaintext), need for human approval via request_approval, idempotency semantics with hash, dryRun behavior, and audit event emission. This is comprehensive given no annotations are provided.

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 description is front-loaded with the core purpose and then provides supporting detail. It is slightly verbose with technical details (e.g., hashing algorithm) but remains efficient overall without unnecessary repetition.

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?

Given the tool's complexity (3 parameters, no output schema, destructive action) and 45 sibling tools, the description covers all essential aspects: purpose, parameters, behavioral traits, prerequisites, error conditions, return values, and audit. It leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Despite 100% schema description coverage, the description adds significant value: it explains the safe default for dryRun, the pattern and creation of approvalId, the default and range for olderThanDays, and the interplay between parameters. This goes beyond the schema's basic descriptions.

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 clearly states that the tool bulk-purges plaintext records older than a specified number of days, with the specific verb 'purge' and resource 'plaintext records'. It distinguishes from sibling tools by focusing on plaintext retention policies and mentioning account-level operation, which is distinct from other deletion tools like bulk_delete_calls or delete_alert.

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 description provides explicit when-to-use guidance, including the example of auto-purge older than 30 days, and when-not-to-use for Free plan users (403). It also recommends using dryRun=true for preview. However, it does not explicitly contrast with other deletion tools, though the unique approval requirement implicitly differentiates.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/argosvix/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server