MCP cannot permanently delete an agent, so domain re-registration is impossible over MCP alone

[jiashuoz]

Summary

The MCP server exposes delete_agent (soft delete → 30-day trash) and restore_agent, but no way to permanently delete / purge a trashed agent. Because a trashed agent continues to hold its address, an MCP-only user cannot free an address — and therefore cannot re-register a domain — without dropping to REST.

Reproduction

All over MCP, on a domain with one agent:

delete_agent(agent@inbox.mnexa.ai, confirm: true)
  → { deleted: true }            # soft delete, agent → trash

delete_domain(inbox.mnexa.ai, confirm: true)
  → domain_has_agents: "cannot delete domain while agents exist —
     delete its agents first (including any in the trash: they hold
     the address until restored or permanently deleted)"

create_agent(agent@inbox.mnexa.ai)
  → address_in_trash: "this address belongs to an inbox in your trash —
     restore it, or delete it permanently from the trash, to reuse the address"

get_agent(agent@inbox.mnexa.ai)
  → not_found                    # trash is hidden from reads

Both error messages tell the user to delete permanently. MCP offers no tool that does that.

Cause

mcp/src/tools/agents.ts — delete_agent's input schema is exactly two fields, and it's a strictInputSchema, so a permanent key is rejected outright:

inputSchema: strictInputSchema({
  email:   z.string().email().optional(),
  confirm: z.literal(true),
}),
...
return client.deleteAgent(args.email);

The capability exists server-side — DELETE /v1/agents/{email}?confirm=DELETE&permanent=true — and is used internally by the prober, which permanently deletes its ephemeral agents specifically so repeated runs don't accumulate trash. It simply isn't surfaced over MCP.

Impact

The only MCP escape from a soft-deleted agent is restore_agent, which undoes the user's intent. Otherwise they wait out the 30-day auto-purge.

This makes domain re-registration impossible over MCP, which matters because re-registration is currently the only remedy for domains registered before per-customer SES sender identities landed (server v1.0.4) — those have no DKIM key material and permanently fail sending-identity provisioning with "no DKIM key material for domain; re-register the domain". So the documented fix for that condition is unreachable from MCP.

Hit this on all three legacy domains during a real re-registration; every one required a REST call to proceed.

Suggested fix

Add an optional permanent: true to delete_agent, gated exactly as REST gates it (explicit confirmation + account scope). MCP already exposes plenty of destructive operations behind confirm: true, so this is consistent with the existing safety model.

Worth noting the SDK operation-coverage gate added in #625 would not catch this — it checks that every OpenAPI operation is reachable from the SDKs, not from MCP. An equivalent MCP-coverage check might be worth considering, since this gap is exactly the class it would find.