Email MCP Server

Send email

send_email

Send emails with plain text or HTML bodies, CC, BCC, and attachments. Supports multiple accounts and inline images.

Instructions

Send a new email. Supports plain text or HTML body, CC, and BCC.

Input Schema

Name	Required	Description
`cc`	No	CC recipients
`to`	Yes	Recipient email addresses
`bcc`	No	BCC recipients
`body`	Yes	Email body content
`html`	No	Send as HTML (default: plain text)
`account`	Yes	Account name from list_accounts
`subject`	Yes	Email subject
`attachments`	No	Files to attach: plain paths, or {path, cid, contentType, filename} objects for inline images. Sizes are checked before sending; the base64-encoded total must stay under the account's effective limit (global cap 25 MB; known provider or per-account limits may be stricter).

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.6.0Oct 17, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / attachments

Added value: +{
+  "description": "Files to attach: plain paths, or {path, cid, contentType, filename} objects for inline images. Sizes are checked before sending; the base64-encoded total must stay under the account's effective limit (global cap 25 MB; known provider or per-account limits may be stricter).",
+  "items": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "additionalProperties": false,
+        "properties": {
+          "cid": {
+            "description": "Content-ID for inline embedding — reference as <img src=\"cid:....\"> in an HTML body",
+            "type": "string"
+          },
+          "contentType": {
+            "description": "Explicit MIME type when the file extension would misdetect",
+            "type": "string"
+          },
+          "filename": {
+            "description": "Filename shown to the recipient (default: the file basename)",
+            "type": "string"
+          },
+          "path": {
+            "description": "Local file path",
+            "type": "string"
+          }
+        },
+        "required": [
+          "path"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  "type": "array"
+}

changedInput schema / properties / bcc / items / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedInput schema / properties / cc / items / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedInput schema / properties / to / items / pattern

Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

First observedv0.2.3Jul 30, 2026

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutating, outward-facing nature is covered structurally. The description adds nothing behavioral on top: it doesn't say the send is immediate/irreversible, what happens on partial recipient failure, or any rate/auth constraints, and the attachment size limits it could have surfaced live only in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the core action front-loaded and the capability summary following. Nothing redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no output schema, the description is adequate but thin: it omits the required 'account' sourcing, the attachments capability, and any differentiation from the seven-plus other send/dispatch siblings. With annotations covering safety, the gap is not severe, but a caller routing between send_email, send_draft, and schedule_email gets no help here.

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 description coverage is 100%, so every parameter including the nuanced attachments object (cid, contentType, filename, size limits) is already documented. The description's mention of text/HTML, CC, and BCC merely mirrors fields the schema defines, matching the baseline of 3 when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send a new email') and enumerates the supported composition features (plain text/HTML, CC, BCC), so the agent knows exactly what the tool produces. It does not, however, distinguish itself from nearby siblings like send_draft, reply_email, forward_email, or schedule_email, which also dispatch mail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'new' implicitly separates this from reply_email/forward_email/send_draft, and usage is implied for first-time composition. But there is no explicit when-to-use statement, no mention of the draft or scheduled alternatives, and no prerequisites (e.g., that 'account' must come from list_accounts).

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

Deploy Server

Send email

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools