Local MCP

Send Email

send_email

Use this when the user wants to send an email from an account configured in the Mac's Apple Mail. Composes and sends via Mail.app; supports plain text or HTML body. For sending from a Microsoft 365 account NOT added to Mail.app, use m365_send_email. Pass from to send from a specific configured Mail.app account instead of the default sender. Pass attachments as a comma-separated list of absolute file paths to attach files.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cc`	No	CC address(es), comma-separated.
`to`	Yes	Recipient address(es), comma-separated for multiple.
`bcc`	No	BCC address(es), comma-separated.
`body`	No	Plain-text body. Use this OR html_body; if both are given, html_body wins.
`from`	No	Sender address — on a multi-account Mac, selects which configured Mail.app account sends. Omit to use Mail's default account.
`confirm`	No	Safety gate: the call only PREVIEWS (nothing is sent) unless confirm:true. Set true to actually send.	false
`subject`	Yes	Subject line.
`html_body`	No	HTML body. Takes precedence over `body` when both are set.
`attachments`	No	Files to attach, as comma-separated absolute paths (e.g. a PDF).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No
`from`	No
`sent`	No
`subject`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedAug 5, 2026

addedInput schema / properties / attachments / description

Added value: +"Files to attach, as comma-separated absolute paths (e.g. a PDF)."

addedInput schema / properties / bcc / description

Added value: +"BCC address(es), comma-separated."

addedInput schema / properties / body / description

Added value: +"Plain-text body. Use this OR html_body; if both are given, html_body wins."

addedInput schema / properties / cc / description

Added value: +"CC address(es), comma-separated."

addedInput schema / properties / confirm / description

Added value: +"Safety gate: the call only PREVIEWS (nothing is sent) unless confirm:true. Set true to actually send."

addedInput schema / properties / from / description

Added value: +"Sender address — on a multi-account Mac, selects which configured Mail.app account sends. Omit to use Mail's default account."

addedInput schema / properties / html_body / description

Added value: +"HTML body. Takes precedence over `body` when both are set."

addedInput schema / properties / subject / description
```
Added value: +"Subject line."
```

addedInput schema / properties / to / description

Added value: +"Recipient address(es), comma-separated for multiple."

First observedJun 30, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description states it sends email, which matches the mutation intent. However, it omits a critical behavioral detail: the confirm parameter that forces a preview unless set to true. This safety gate is only in the schema, not the description, and for a mutating tool this is a significant omission.

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?

The description is three sentences, front-loaded with the primary use case, then the alternative, then parameter hints. It is efficient with no filler and covers the key points without verbosity.

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?

Given 9 parameters and an existing output schema, the description covers the main use case and alternative, but misses the confirm preview behavior which is essential for a mutating tool. It also does not mention the body/html_body precedence, though that is in the schema. Overall, it is not fully complete for an agent to call safely without reading the schema.

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 all parameters are already documented. The description adds marginal value by reiterating the `from` account selection and attachment path format, but these are also in the schema. It does not explain the `body` vs `html_body` precedence or the confirm behavior beyond what schema states, so it adds little beyond the baseline.

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 description clearly states the action (send an email), the resource (Mail.app account on the Mac), and the supported formats (plain text or HTML). It explicitly names the sibling m365_send_email as the alternative for Microsoft 365 accounts not in Mail.app, distinguishing this tool from others.

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?

The description gives explicit when-to-use guidance ('Use this when...') and names the exact alternative tool (m365_send_email) for a different scenario. It also explains the optional from and attachments parameters, giving concrete usage context.

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

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.