Skip to main content
Glama

remove_mailboxes

Destructive

Release your newest live mailboxes now to lower your billed quantity. This action requires acknowledged, irreversible consent; the lower monthly rate applies at the next renewal.

Instructions

Downgrade: release your N NEWEST live mailboxes now and lower the billed quantity. Inputs: count, acknowledged (must be true — this is a quoted, irreversible-this-cycle consent: the release is immediate for provisioning but there is NO mid-cycle credit; the lower price takes effect next renewal, minimum 5 mailboxes / $99). Returns { releasedCount, failedCount, unreleased, billing, deduplicated } where billing is the new projected monthly. releasedCount is what COMPLETED and can be less than the count you asked for; failedCount is how many the provider refused, which are STILL LIVE and still billed, and unreleased names those addresses — read them before concluding a downgrade landed. deduplicated: true means this call did NOT re-perform the downgrade — every count above describes an EARLIER call's already-recorded outcome under the same idempotencyKey, not new work done just now. This can be true even after the 30-day idempotency window itself has expired: the underlying release record persists independently, so a reused key still reports no re-release rather than silently starting a fresh one. count is RELATIVE — it releases that many MORE mailboxes, it does not set your fleet to that size — and release cannot be undone through this API, so ALWAYS pass an idempotencyKey: the FIRST call under a key resolves WHICH mailboxes to release and records that exact set, so every later call carrying the SAME key can only ever finish that same set. A same-key retry re-attempts the stragglers and can never release a mailbox outside them, whatever count you send with it (the recorded set wins over a changed count); a retry WITHOUT a key always releases another count. A genuine SECOND downgrade is therefore a NEW key — reusing an old one can only ever finish what that key already asked for. A call that came back with failedCount above zero did NOT finish, so its key is not frozen: resend the identical request with the same key until failedCount is 0 — from then on that key replays the finished result and releases nothing further. If a call returns 409 a release is already running for this account: wait, then re-read infrastructure_status before deciding whether to retry. To ADD mailboxes use setup_infrastructure / configure_byo_domain (request_managed_mailboxes).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
acknowledgedYes
idempotencyKeyNoOptional idempotency key: resend the SAME key when retrying this call so a dropped-response retry is not applied twice (no duplicate campaign/provision/send).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.2.3
    • addedInput schema / properties / idempotencyKey
      Added value: +{
      +  "description": "Optional idempotency key: resend the SAME key when retrying this call so a dropped-response retry is not applied twice (no duplicate campaign/provision/send).",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Although destructiveHint is already set, the description goes far beyond it: release is irreversible-this-cycle, no mid-cycle credit is granted, failed releases remain live and billed, deduplicated=true means no new work was performed, and idempotency key reuse can replay outcomes even after the 30-day window. This level of behavioral detail is exactly what an agent needs to safely call a destructive tool.

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 action and is dense with uniquely useful content. However, the idempotencyKey and retry sections are somewhat repetitive—'same key... can only ever finish that set' is restated multiple times—so a more structured layout could improve comprehension without adding information. Overall, length is justified by the destructive, irreversible nature, but tightening would be better.

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 no output schema, the description fully documents expected return fields: releasedCount, failedCount, unreleased, billing, and deduplicated, including what each means. It also covers error handling (409), billing timing, minimum quantity, and the relationship to idempotency in a way that allows an agent to call the tool and interpret the response correctly in one flow.

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?

The schema only describes idempotencyKey (33% coverage); count and acknowledged are bare fields. The description compensates fully: count is relative ('releases that many MORE mailboxes, it does not set fleet to that size'), acknowledged must be true and represents quoted irreversible consent, and idempotencyKey semantics are explained in depth including retries, reused keys, and changed counts. It meaningfully adds what the schema lacks.

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 opens with 'Downgrade: release your N NEWEST live mailboxes now and lower the billed quantity', which names a specific verb, resource, and intended effect. It clearly distinguishes this destructive downgrade operation from add-oriented siblings by pointing to setup_infrastructure and configure_byo_domain for adding mailboxes.

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?

The description is explicit about when to use the tool ('To ADD mailboxes use setup_infrastructure / configure_byo_domain') and gives detailed retry guidance: resend identical requests until failedCount is 0, use a NEW key for a genuine second downgrade, and wait/re-read infrastructure_status on a 409. The conditions and alternatives are unambiguous.

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

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/YS-projectcalc/agent-cold-email'

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