Inbox Triage

Send a pending draft after the person approves

send_draft

Destructive

Sends a draft once the person approves it. The model saying they approved in chat does not send anything.

Sends a previously created draft. Requires pendingSendId + approvalCode from create_draft. Show the human the full To/Subject/body first. Not available for demo drafts. In apps that can prompt the person directly (MCP elicitation; create_draft then returns confirmInApp:true), the person sees To, Subject, and body in a prompt and picks Send, Edit, or Cancel there; nothing is sent unless they pick Send. If they pick Edit, the result has their requested changes: make a new draft with create_draft and call send_draft for it. Otherwise, or if the prompt is declined or cannot be shown, the result has approvalUrl: give it to the person, who checks the email (and can change recipients or wording) and clicks Send there. Never say it was sent until the result says sent:true. If the result has scheduled:true, it goes out at sendAt under the person's send rules; say it is scheduled, not sent, and give them approvalUrl to cancel or edit. The Send button on the show_draft card also works.

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": {
      "pendingSendId": "<pendingSendId>",
      "approvalCode": "<approvalCode>"
    },
    "name": "send_draft"
  }
}

Input Schema

Name	Required	Description
`confirmTo`	No	If provided, must match the pending send To
`waitSeconds`	No	When the person approves on the approval page, wait up to this many seconds (default 0) for their click and return sent:true as soon as it lands.
`approvalCode`	Yes	approvalCode returned by create_draft for this pending send
`pendingSendId`	Yes	pendingSendId returned by create_draft when sendAvailable is true
`confirmSubject`	No	If provided, must match the pending send subject
`confirmVersion`	No	Only after a result said the draft changed in the mailbox: the version value that result gave, passed once the person has seen that version and said yes.
`humanApprovedInChat`	No	Ignored. Approval happens in the in-app prompt or on the approval page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite destructiveHint=true already indicating mutation, the description adds substantial behavioral context: nothing is sent without human approval, sent:true is the only confirmation, scheduled:true means not yet sent, approvalUrl enables cancellation/editing, and demo drafts are unavailable. This is rich operational guidance beyond annotations.

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 approval gate and then walks through the two approval paths in a logical order. It is somewhat long and includes minor repetition such as restating that it sends a previously created draft, but the complexity justifies most of the length.

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?

For a destructive, non-idempotent send operation with no output schema, the description covers the necessary approval flow, success signals, scheduled behavior, edit path, and failure/decline path. An agent has enough information to call it safely and interpret the result.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already defines each parameter well. The description still adds useful meaning by stating that pendingSendId and approvalCode come from create_draft and by explaining the approval result fields that affect subsequent calls.

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: sends a previously created draft only after approval. It distinguishes the operation from create_draft by requiring pendingSendId and approvalCode, and it references the show_draft card path as an alternative send surface.

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?

Explicitly says what does not work (model chat approval alone), what is required (pendingSendId + approvalCode from create_draft), and what must happen first (show the human To/Subject/body). It also gives branch-specific guidance for in-app approval, approvalUrl, edit requests, and scheduled sends.

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

All Inbox Triage tools Inspect

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

Need Help?