local-mcp

Create Draft

create_draft

Saves an email to the Mail.app Drafts folder for the user to review and send manually — never sends. Composes a new draft (pass to/subject/body), or a reply draft (pass reply_to_message_id plus body). A reply draft's response includes threaded: true means the saved draft was read back and its headers reference the source message (it will appear inside the conversation); false means it saved WITHOUT threading headers (relay the warning to the user); "unconfirmed" means it could not be read back in time (e.g. Exchange sync lag). On a multi-account Mac, pass account (an account name from list_email_accounts) or from (a sender address) to place the draft in that account's Drafts; otherwise it lands in the default account. Attach files by passing attachments (comma-separated absolute file paths, e.g. a PDF quote) — they are attached to the saved draft. Use this for the cautious user who wants AI-composed mail but insists on sending it themselves. Requires confirm=true to actually save it — without it, returns a preview of the resolved recipient/sender, subject, and that the body will be saved, without touching Mail.app.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cc`	No	CC address(es), comma-separated.
`to`	No	Recipient address(es) for a new draft, comma-separated. Omit for a reply draft (uses reply_to_message_id).
`bcc`	No	BCC address(es), comma-separated.
`body`	No	Plain-text body of the draft.
`from`	No	Sender address — on a multi-account Mac, selects which account's Drafts to use. Alternative to `account`.
`account`	No	Account name (from list_email_accounts) whose Drafts folder receives the draft. Alternative to `from`.
`confirm`	No	Must be true to actually save the draft. Without it, returns a preview of the recipient/sender, subject, and that the body will be saved.	false
`subject`	No	Subject line for a new draft. Ignored for reply drafts (they inherit the original subject).
`html_body`	No	HTML body of the draft. Takes precedence over `body` when both are given.
`reply_all`	No	For a reply draft, include all original recipients (reply-all) instead of just the sender.	false
`attachments`	No	Files to attach, as comma-separated absolute paths (e.g. a PDF).
`reply_to_message_id`	No	Message id (from list_emails/search_emails) to draft a reply to, instead of a new message.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No
`from`	No
`kind`	No
`account`	No
`subject`	No
`attachments`	No
`saved_draft`	No
`attachments_failed`	No
`reply_to_message_id`	No

TDQS

A4.8/5.0

Behavior5/5

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

The description goes far beyond the annotations: it discloses that the tool never actually sends mail, requires confirm=true to save, returns a preview without touching Mail.app when confirm is false, and explains the reply-threading status values (true/false/unconfirmed). This rich behavioral disclosure is exactly what an agent needs for safe invocation, especially since annotations only indicate readOnlyHint=false and destructiveHint=false.

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 long but every clause carries necessary operational information: sending semantics, draft vs reply modes, reply confirmation semantics, account selection, attachments, target user, and the confirm flag. The most important differentiator — 'never sends' — is front-loaded, and the structure moves logically from core behavior to variants to invocation requirements.

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?

Given the tool's complexity — 12 parameters, no required parameters, and two distinct modes — the description covers all the decisions an agent must make: which mode to use, which account to target, whether to include attachments, how to handle reply threading results, and the necessity of confirm=true. The presence of an output schema also means return-value details do not need to be fully restated, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents all 12 parameters (100% coverage), the description adds meaningful compositional guidance: how reply_to_message_id pairs with body, how account/from select the destination Drafts folder, how attachments expect comma-separated absolute paths, and the semantic meaning of the threaded reply response. This adds real value beyond the raw schema descriptions.

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 tool saves an email to Mail.app's Drafts folder and explicitly notes 'never sends' — a strong verb+resource statement that differentiates it from send_email and reply_email. It also distinguishes two modes (new draft vs reply draft), so an agent can select it without ambiguity.

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

Usage Guidelines4/5

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

The description gives an explicit use case: 'Use this for the cautious user who wants AI-composed mail but insists on sending it themselves.' It also explains the confirm=true requirement and preview behavior. It does not explicitly name send_email as the alternative when automatic sending is desired, so the guidance is clear but not exhaustive about alternatives.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0

Disambiguation3/5

Many tools are clearly distinct per app (e.g., chrome_*, safari_*, m365_*), but there is notable overlap between generic file tools like `file_list` and `finder_list`, both listing files; `search_contacts` and `list_contacts` serve similar purposes; `report_friction` and `report_problem` both send feedback to the team. The large number of tools with similar purposes in different domains creates moderate ambiguity for an agent.

Naming Consistency4/5

The naming convention is very consistent overall: most tools follow a `{app}_action` or `verb_noun` pattern (e.g., `chrome_click`, `create_calendar_event`, `list_reminders`). There are minor deviations like `lmcp_install_upgrade` (two verbs) and `complete_omnifocus_task` vs. `complete_reminder` (inconsistent verb placement). Still, the pattern is predictable and readable across the full set.

Tool Count2/5

With 225 tools, the surface is extremely large and heavy. While it covers many distinct domains (browsers, mail, calendar, files, notes, reminders, video editing, web automation, etc.), the sheer number makes it hard to navigate and likely includes many rarely-used tools. This is far beyond the well-scoped range of 3-15 tools and feels excessive even for a 'local everything' MCP server.

Completeness3/5

For many app integrations, the tool set provides solid CRUD coverage (e.g., Calendar has create, read, update, delete; Apple Notes has create, read, update, list, search; OmniFocus has create, list, search, complete). However, some areas are incomplete: for example, there is no tool to create a new Mail folder or delete notes. The 'web' tools lack a clear update/delete for saved sessions. The suite is broad but has notable gaps within individual domains.

Create Draft

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources