Skip to main content
Glama
cybersmurf

Stalwart Mail MCP

by cybersmurf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send an e-mail

mail_send_email

Sends a new email or reply immediately, saving a copy in Sent. Use only after explicit user confirmation, as sending cannot be undone.

Instructions

Sends an e-mail from the mailbox — a new one, or a reply (in_reply_to_id). A copy is stored in Sent. It sends IMMEDIATELY and cannot be undone. Send only when the user explicitly said the message should go out; otherwise create a draft (mail_create_draft). Verify the recipient before sending — never guess an unknown address, look it up with mail_search_contacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCc — a list of addresses as “name@domain” or “First Last <name@domain>”.
toNoRecipients — a list of addresses as “name@domain” or “First Last <name@domain>”.
bccNoBcc — a list of addresses as “name@domain” or “First Last <name@domain>”.
fromNoSender address; default is the address of the signed-in mailbox. Must be one of the account's allowed senders.
htmlNoBody as HTML (optional; when text is missing it is derived from the HTML).
textNoMessage body as plain text (preferred). Write the signature yourself, the server adds none.
accountNoWhich account: leave empty for the signed-in mailbox, or name a shared mailbox / group you have access to (the part before @ is enough; a full address works too). mail_list_mailboxes shows what exists.
subjectNoSubject. A reply gets “Re: …” automatically when it is missing.
reply_toNoReply-To (where replies should go) — a list of addresses as “name@domain” or “First Last <name@domain>”.
reply_allNoFor a reply: also copy the other original recipients.
attachmentsNoFull paths of files on this computer to attach (max. 25 MB each).
in_reply_to_idNoid of the message you are replying to — sets the thread (In-Reply-To/References), fills in the recipient and subject, marks the original as answered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, so safety is partly covered; the description still adds high-value behavior: it sends IMMEDIATELY, cannot be undone, and leaves a copy in Sent. It does not cover failure behavior or how the send is confirmed, which keeps it 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.

Conciseness5/5

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

Three sentences, front-loaded with the core action and the irreversibility warning before the routing rules. Every clause carries actionable information; nothing is redundant with the title.

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 12-parameter, zero-required, no-output-schema tool, the description covers the essentials an agent needs: immediacy, irreversibility, Sent archival, and which sibling to use instead. It leaves only minor gaps such as post-send confirmation or partial-failure behavior.

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 the schema already documents recipient formats, account selection, attachment paths, and the in_reply_to_id thread behavior. The description only nods at in_reply_to_id in passing, adding essentially no semantics beyond the schema. Baseline 3 applies.

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 gives a precise verb+resource ('Sends an e-mail from the mailbox') and immediately disambiguates the reply case via 'in_reply_to_id'. Combined with the named siblings (mail_create_draft, mail_send_draft), an agent can tell this apart from the drafting tools without opening a 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 explicit when-to-use ('only when the user explicitly said the message should go out'), an explicit when-not with the alternative ('otherwise create a draft (mail_create_draft)'), and a prerequisite ('never guess an unknown address, look it up with mail_search_contacts'). This is textbook routing guidance.

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