Dove

Send draft

send_draft

Destructive

Sends an existing draft exactly as reviewed only when its revision matches, preventing accidental edits from being mailed; if the outcome is unknown, check Sent before retrying.

Instructions

Send one existing draft this project created, unchanged since expected_revision (from get_draft or the last update_draft); a mismatch fails with draft_conflict. Only listed when the operator enabled sending and granted send on this mailbox; otherwise ask the owner with request_send, which also schedules. Accepts no recipients or content. outcome_unknown means the mail may have gone out: never retry it, check Sent.

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": {
      "account": "<account>",
      "draft_id": "<draft_id>",
      "expected_revision": "<expected_revision>"
    },
    "name": "send_draft"
  }
}

Input Schema

Name	Required	Description
`account`	Yes	Mailbox alias or email address from list_accounts.
`draft_id`	Yes	Draft id from create_draft or list_drafts.
`expected_revision`	Yes	Revision of the draft as the owner reviewed it; a mismatch fails with draft_conflict.

Output Schema

Name	Required	Description	Default
`thread_id`	No
`sent_message_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 14, 2026

addedInput schema / properties / draft_id / description

Added value: +"Draft id from create_draft or list_drafts."

addedInput schema / properties / expected_revision / description

Added value: +"Revision of the draft as the owner reviewed it; a mismatch fails with draft_conflict."

First observedv0.11.0Nov 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses optimistic concurrency on expected_revision, that no recipients or content are accepted, and the critical post-condition that outcome_unknown means the mail may have already gone out so retrying is forbidden. That is exactly the behavioral context an agent needs before an irreversible send, and it is consistent with destructiveHint=true and idempotentHint=false.

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?

Three dense sentences, front-loaded with the core action and constraint, then the availability gate, then the failure handling. Semicolon chaining makes it terse to the point of being run-on, but every clause carries operational weight.

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 an irreversible send with three required params and an output schema, nothing essential is missing: preconditions, conflict behavior, authorization gate, and the ambiguity case are all covered. Return-value detail is rightly left to the output schema.

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 coverage is 100%, so the baseline is 3; the description adds real meaning by framing expected_revision as the revision the owner reviewed and by naming the draft_conflict failure mode. It doesn't restate account or draft_id beyond the schema, which is appropriate.

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 (send) and resource (one existing draft this project created), plus the hard scoping condition that it must be unchanged since expected_revision. This clearly separates it from request_send, which is named as the alternative path.

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 and when-not-to-use: it is only listed when the operator enabled sending and granted send on the mailbox; otherwise the agent is told to use request_send with the owner. The conflict path (mismatched revision fails with draft_conflict) and the outcome_unknown path (never retry, check Sent) are both spelled out.

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