Skip to main content
Glama

agent-cold-email

by io.github.YS-projectcalc
OverviewDiscussionsAdmin

remove_mailboxes

Destructive

Downgrade: release your N NEWEST live mailboxes, lowering the billed quantity. Inputs: count, acknowledged (must be true — release is immediate but irreversible; no mid-cycle credit, lower price starts next renewal, minimum 5 mailboxes/$99). Returns { releasedCount, failedCount, unreleased, billing, deduplicated }. count is RELATIVE (that many MORE, not a fleet target). ALWAYS pass an idempotencyKey: the FIRST call under a key fixes WHICH mailboxes to release; a later call with the SAME key can only finish that set. releasedCount can be less than count — failedCount names how many the vendor refused (still live, billed; unreleased lists them). Resend with the same key until failedCount is 0. deduplicated: true = NO new work — an earlier recorded outcome under that key was replayed. A genuinely NEW downgrade needs a NEW key. 409 = a release already running; re-check infrastructure_status before retrying. To ADD mailboxes use setup_infrastructure or configure_byo_domain.

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.

  1. Changed1 schema field changed
    • 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. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description adds substantial context the agent could not otherwise know: release is immediate and irreversible, no mid-cycle credit, lower price starts at next renewal, a 5-mailbox/$99 minimum, and the tricky idempotency semantics where the first call under a key fixes which mailboxes are released.

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?

Front-loaded with the action and scope, and nearly every sentence carries non-obvious operational detail. It is dense and long for a three-parameter tool, but the length is justified by idempotency and partial-failure semantics rather than padding.

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?

No output schema exists, yet the description enumerates the return shape (releasedCount, failedCount, unreleased, billing, deduplicated) and explains how to interpret the partial-failure and dedup cases, leaving nothing essential unstated for a destructive billing operation.

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?

Schema description coverage is only 33% (count and acknowledged are undocumented in the schema), but the description compensates fully: count is RELATIVE not a fleet target, acknowledged must be true, and an idempotencyKey should always be passed with the replay/dedup semantics explained.

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 ('release your N NEWEST live mailboxes, lowering the billed quantity') and immediately frames it as a downgrade, which cleanly separates it from the add-side siblings setup_infrastructure and configure_byo_domain named at the end.

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?

Explicit when-to-use (downgrade billing), when-not (to ADD mailboxes use setup_infrastructure or configure_byo_domain), plus retry protocol (resend with the same key until failedCount is 0) and error handling (409 = release already running, re-check infrastructure_status).

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

All agent-cold-email toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources