Skip to main content
Glama
Sign In

Busymail

by app.busymail
OverviewDiscussionsAdmin

Cancel a queued send

cancel_queued_send

Withdraw one of YOUR OWN queued sends while it is still awaiting the owner's approval, and take its draft out of the mailbox. Only a send that THIS token queued - check queued_by_this_token on list_queued_sends - and that is still 'pending' can be cancelled. Everything else is refused: an approved send may already have reached the mail server even while sent_at is unset, so an approved send is never cancellable, and a rejected, expired or draft_gone send is already a closed record.

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": {
      "pending_send_id": "<pending_send_id>"
    },
    "name": "cancel_queued_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
pending_send_idYesThe id of the queued send to withdraw, from list_queued_sends. Only one queued by this token can be cancelled.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the destructive side effect (the draft is removed from the mailbox), the ownership precondition, the state precondition, and a non-obvious edge case (an approved send may already have reached the server even while sent_at is unset). It stops short of describing what a refusal looks like (error vs. no-op) or whether the removal is recoverable.

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 action and its scope are front-loaded, followed by the ownership/state gate and then the refusal cases, which is the right order for an agent to read. The sentences are long and dense, but no clause is filler; a small trim of the double explanation of approval would tighten it.

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?

For a one-parameter mutation with no annotations and no output schema, the description covers preconditions, side effects, and all refusal states, which is the important surface. The remaining gap is post-call behavior: what the agent gets back on success versus refusal, and whether retrying is safe.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter is fully documented in the schema, including its source (list_queued_sends) and ownership constraint. The description reinforces the same constraint but adds no new syntax, format, or edge-case meaning for the parameter itself, so the baseline of 3 applies.

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 ('Withdraw ... queued sends', 'take its draft out of the mailbox') plus the exact scope restriction (own sends, still pending). It also names the sibling tool (list_queued_sends) an agent should consult first, so it is distinguishable from every other tool in the sibling list.

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?

Gives explicit when-to-use conditions (queued by this token, status 'pending') and explicit when-not conditions (approved, rejected, expired, draft_gone are all refused). It even names the field to check on the sibling tool, leaving nothing to inference.

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

All Busymail 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