MCP Agent Mail

hard_delete_agent

Irreversibly delete an agent and all related messages, recipient records, file reservations, links, and archive files. Requires confirmation set to 'I UNDERSTAND'.

Instructions

IRREVERSIBLY delete an agent and ALL associated data: messages sent by the agent, message recipient records, file reservations, agent links, window identities, and on-disk archive files (inbox, outbox, attachments). This is NOT soft-delete — data is permanently destroyed and cannot be recovered. Requires the confirmation parameter to be exactly 'I UNDERSTAND'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_key": "<project_key>",
      "agent_name": "<agent_name>",
      "confirmation": "<confirmation>"
    },
    "name": "hard_delete_agent"
  }
}

Input Schema

Name	Required	Description	Default
`agent_name`	Yes
`project_key`	Yes
`confirmation`	Yes
`registration_token`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.4Sep 30, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so well: irreversibility, permanence ('cannot be recovered'), an exhaustive list of destroyed data classes, and the on-disk artifacts (inbox, outbox, attachments) affected. Only the authorization requirements around registration_token are left unstated.

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

Conciseness5/5

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

Three dense sentences, front-loaded with the destructive action and its scope, followed by the soft-delete disqualifier and the confirmation requirement. No filler or repetition.

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?

An output schema exists, so return values need not be described, and the destruction scope plus confirmation gate cover the highest-risk aspects of this operation. The remaining gap is the undocumented registration_token and any auth/permission prerequisites implicit in its presence.

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

Parameters2/5

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

Schema description coverage is 0% across four parameters, so the description must compensate, yet it only meaningfully explains 'confirmation' (exact literal 'I UNDERSTAND'). Neither project_key, agent_name, nor the optional registration_token is described, and registration_token in particular is not self-explanatory.

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 ('IRREVERSIBLY delete an agent') and then enumerates exactly what is removed: messages, recipient records, file reservations, agent links, window identities, and on-disk archives. The explicit 'This is NOT soft-delete' line distinguishes it from the soft variants (retire_agent, deregister_agent) an agent would otherwise consider.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It conveys the precondition for invocation (confirmation must be exactly 'I UNDERSTAND') and the permanent nature of the operation, which strongly implies when it is appropriate. However, it never names the sibling alternatives (retire_agent, deregister_agent, unretire_agent) or tells the agent to prefer them when reversibility is acceptable, leaving the tool-selection decision to inference.

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