Skip to main content
Glama
epinethrone

icloud-mcp

by epinethrone
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mail_send_message

Compose and send a new email from scratch, or save it to Drafts for review by setting draft=true.

Instructions

Compose a new email from scratch and send it, or save it to Drafts with draft=true.

Use when: the owner asks you to write to someone and has agreed the recipients and text. Not for answering a message (use mail_reply_to_message, which keeps the thread), passing one on with its attachments (use mail_forward_message), or sending an existing draft (use mail_send_draft). Parameters:

  • to, cc and bcc take 'anna@example.org' or 'Anna anna@example.org'; a bare name is refused.

  • body is plain text; body_html, if given, goes alongside it as multipart/alternative. The owner's signature (EMAIL_SIGNATURE) is appended to both.

  • Each attachment may be at most MAX_ATTACHMENT_BYTES (default 5 MB).

  • Omitted cc, bcc, body_html and attachments are simply left out.

  • draft=true only saves to Drafts: no approval, no recipient checks, nothing leaves. Behavior:

  • With SEND_REQUIRES_APPROVAL=true (the default) the message is NOT sent: it is queued on the owner's approval page (expires after 24 h by default) or, on a local server, saved to Drafts for the owner to send. With it off, it goes out at once and a copy is saved to Sent.

  • Recipients are checked first: at most MAX_RECIPIENTS (default 25) across to, cc and bcc, and only SEND_ALLOWLIST addresses if that list is set.

  • Every call is a new message, so never repeat one to be sure. Returns: {status, recipients, message_id, subject, to, cc}; layout_warnings flags Windows line endings, HTML tags in body, or one long paragraph. status is one of:

  • sent: saved_to names the Sent folder; refused lists addresses the server rejected.

  • queued_for_owner_approval: sent=false, outbox_id, approve_at, expires_in_seconds and a notice to tell the owner.

  • saved_to_drafts_for_owner_approval or draft_saved: folder, but no uid; find it with mail_search_messages(folder='Drafts'). Errors:

  • an unusable, disallowed or excess recipient, or an oversized attachment.

  • a full approval queue: do not retry; tell the owner.

  • an SMTP failure: check Sent before retrying, it may have gone out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCc addresses (visible to all recipients).
toYesAddresses: 'anna@example.org' or 'Anna <anna@example.org>'. Only a name? contacts_search_contacts, then mail_find_correspondent.
bccNoBcc addresses (hidden from other recipients).
bodyYesPlain-text message body. The server appends the owner's signature.
draftNotrue = save to Drafts for the user to review instead of sending.
subjectYesSubject line.
body_htmlNoOptional HTML version of the body; the plain-text 'body' is always required.
attachmentsNoFiles to attach (from mail_get_attachment as is; from drive_get_file, name and data_base64 go in filename and content_base64).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mail_send_messageDictOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.12.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic write profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false); the description goes far beyond, disclosing the SEND_REQUIRES_APPROVAL queue, 24-hour expiry, recipient/allowlist caps, signature appending, attachment size limits, and the non-idempotent 'never repeat a call' warning. This is exactly the behavioral context annotations cannot carry.

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?

Well front-loaded and organized into Purpose, Parameters, Behavior, Returns, and Errors blocks, so an agent can locate the relevant section quickly. It is long and a couple of lines (address format, draft flag) restate schema descriptions, but the density is justified by the tool's complexity.

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?

With no output schema, the description compensates fully by spelling out the return shape (status, recipients, message_id, folder) for each status value and enumerating the error modes with recovery advice. Given the approval/allowlist/SMTP complexity, nothing an agent needs to call this 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 coverage is 100%, so the baseline is 3, but the description genuinely adds semantics: bare-name addresses are refused, body_html is sent as multipart/alternative alongside body, EMAIL_SIGNATURE is appended to both, MAX_ATTACHMENT_BYTES, and the fact that omitted optional fields are simply left out. The address-format line overlaps the schema slightly, keeping it from a 5.

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 first sentence states a specific verb and resource ('compose a new email from scratch and send it, or save it to Drafts'), and it immediately names the scope (new message vs. existing draft). It is distinguishable from mail_reply_to_message, mail_forward_message, and mail_send_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 gives an explicit 'Use when' condition (owner asks you to write and has agreed recipients/text) plus three named exclusions, each paired with the correct sibling tool. Nothing about tool selection is left to inference.

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

Deploy Server

Other Tools