Dove

Ask to send drafts on a schedule

request_send

Ask the mailbox owner to approve and send your project's drafts at set times or spread across a window; nothing sends until approved, and only the exact revision you submitted.

Instructions

Ask the owner to send drafts this project created, at given times. Use it when you lack send rights (send_draft needs them) or want a send scheduled. Nothing is sent until the owner approves; the owner sees each draft as it is then, and only that exact revision is ever sent (changing a draft afterwards makes its item fail with draft_changed). Needs draft rights on the mailbox, not send rights. Give send_at (RFC 3339 with offset, in the future, at most 30 days out) on every item, or one window {from, to} and Dove spreads the items evenly over it in the given order. unless_reply: skip an item if someone else replied in its thread after this request (drafts must be replies; the mailbox must be indexed). A draft can be in one open request only. Follow the outcome with list_requests.

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>",
      "items": "<items>"
    },
    "name": "request_send"
  }
}

Input Schema

Name	Required	Description
`note`	No	Short note for the owner (why, what to check).
`items`	Yes	Drafts to send, in the order they are scheduled.
`window`	No	Spread the items evenly from `from` to `to` (both included) instead of send_at.
`account`	Yes	Mailbox alias or email address from list_accounts.
`unless_reply`	No	Skip an item when its thread got a reply from someone else after this request.

Output Schema

Name	Required	Description	Default
`items`	No
`status`	No
`request_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 14, 2026
- addedInput schema / properties / items / description
```
Added value: +"Drafts to send, in the order they are scheduled."
```
- addedInput schema / properties / items / items / properties / draft_id / description
```
Added value: +"Draft id from create_draft or list_drafts."
```
- addedInput schema / properties / window / properties / from / description
```
Added value: +"RFC 3339 instant with offset: the first send time."
```
- addedInput schema / properties / window / properties / to / description
```
Added value: +"RFC 3339 instant with offset: the last send time."
```
First observedv0.11.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations (which only say this is a non-destructive, non-idempotent mutation), the description discloses that nothing is sent until owner approval, that only the exact pinned revision is ever sent, and that later edits cause a draft_changed failure — important consequence information the annotations do not carry. It also names the permission model (draft rights, not send rights) and the one-open-request constraint, though it does not mention rate limits or approval-latency behavior.

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 dense but front-loaded: purpose first, then prerequisites, then the send_at/window rules, then unless_reply. The sentence covering 'unless_reply' is somewhat compressed, but no line is filler and the ordering matches the schema's decision flow.

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 nested, multi-constraint mutation tool with an output schema, the description covers the approval lifecycle, revision pinning, the two mutually exclusive scheduling modes, the conditional skip rule, and the permission prerequisite. Nothing an agent needs in order to call it correctly is missing.

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 parameter documentation is already strong, but the description adds constraints the schema lacks: send_at must be in the future and at most 30 days out, window spreads items evenly in the given order, and unless_reply requires the draft to be a reply and the mailbox to be indexed. These are genuine additions rather than restatements.

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 opening sentence gives a specific verb and resource (ask the owner to send drafts) plus its scheduling scope, and immediately contrasts with the sibling send_draft. An agent can distinguish this from send_draft or create_draft without opening any schema.

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?

It states the exact condition for choosing this tool over the alternative: 'when you lack send rights (send_draft needs them) or want a send scheduled.' It also closes the loop by directing the agent to list_requests to follow the outcome, which removes ambiguity about next steps.

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