Fluxmail

send_email

Destructive

Deliver email from a connected account: compose directly, send an existing draft, reply with correct threading, or schedule delivery for later.

Instructions

Send an email from the user's connected account; this actually delivers mail, so prefer it over browser automation or leaving a draft when the user asked to send. Three modes: direct (to + subject + body), sending an existing draft (draftId), or replying (replyToMessageId, optionally replyAll) where recipients, subject, and threading are derived from the original. Confirm with the user when intent is ambiguous. Add sendAt to any mode to schedule instead of sending now.

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Recipients, each "Name <a@x.com>" or "a@x.com"
`to`	No	Recipients, each "Name <a@x.com>" or "a@x.com"
`bcc`	No	Recipients, each "Name <a@x.com>" or "a@x.com"
`from`	No	Connected address or an available send-as address
`sendAt`	No	Schedule delivery instead of sending now: ISO 8601 with timezone offset or Z (e.g. 2026-07-11T09:00:00-07:00). Fluxmail saves the message as a real draft in the mailbox and sends it at this time; the server must be running then (anything missed while it was down goes out at the next startup). Returns a scheduleId for list/cancel.
`draftId`	No	Send this existing draft
`subject`	No	Defaults to "Re: ..." when replying
`bodyHtml`	No	HTML body
`bodyText`	No	Plain-text body. Line breaks appear in the sent email. Keep each prose paragraph on one continuous line and separate paragraphs with blank lines.
`replyAll`	No	With replyToMessageId: reply to all original recipients
`accountId`	No	Account to operate on. Optional when exactly one account is connected.
`attachments`	No
`idempotencyKey`	Yes	Reuse this key when retrying the same delivery
`replyToMessageId`	No	Message being replied to; threads correctly and computes recipients if "to" is omitted

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.11.1Oct 1, 2026
- removedOutput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```

Changed4 schema fields changedv0.11.0Sep 26, 2026

changedInput schema / properties / bodyText / description

Previous value: -"Plain-text body"New value: +"Plain-text body. Line breaks appear in the sent email. Keep each prose paragraph on one continuous line and separate paragraphs with blank lines."

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Reuse this key when retrying the same delivery",
+  "pattern": "^[\\x21-\\x7e]{1,255}$",
+  "type": "string"
+}

addedInput schema / required
```
Added value: +[
+  "idempotencyKey"
+]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "accountId": {
+          "type": "string"
+        },
+        "error": {
+          "additionalProperties": false,
+          "properties": {
+            "code": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "code"
+          ],
+          "type": "object"
+        },
+        "kind": {
+          "type": "string"
+        },
+        "operationId": {
+          "type": "string"
+        },
+        "result": {
+          "additionalProperties": true,
+          "properties": {
+            "id": {
+              "type": "string"
+            },
+            "threadId": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "id",
+            "threadId"
+          ],
+          "type": "object"
+        },
+        "scheduleId": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "operationId",
+        "accountId",
+        "kind",
+        "status"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.9.0Sep 16, 2026

addedInput schema / properties / from

Added value: +{
+  "description": "Connected address or an available send-as address",
+  "format": "email",
+  "type": "string"
+}

First observedv0.1.0Jul 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare destructiveHint=true; the description goes further by warning delivery is real, that scheduled sends are persisted as real drafts and depend on the server running (missed ones fire at next startup), and that sendAt returns a scheduleId. It doesn't cover auth/permission scope or idempotency semantics beyond what the schema says, so it stops short of a 5.

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 purpose before modes and caveats, with no filler. Slightly packed with mode/caveat clauses, but every clause carries operational meaning.

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 14-parameter tool with an output schema and a single annotation, the description covers modes, scheduling caveats, and the confirmation rule. Gaps are minor: attachments and the required idempotencyKey are left entirely to the schema, and account selection (accountId) is only hinted at via 'the user's connected account'.

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 already 93% (baseline 3), and the description adds genuine cross-parameter structure the schema lacks: which parameter set defines each mode, that reply derives recipients/subject/threading from the original, and that sendAt composes with any mode rather than being its own mode.

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+resource ('Send an email from the user's connected account') and immediately distinguishes the three operating modes (direct, existing draft, reply), which lets an agent separate this from create_draft, update_draft, forward_email and preview_send.

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 routes against alternatives: 'prefer it over browser automation or leaving a draft when the user asked to send', and adds a decision rule for ambiguity ('Confirm with the user when intent is ambiguous'). Mode selection conditions (direct vs draftId vs replyToMessageId) are spelled out.

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