himalaya-mcp

Overview Schema Source Related Servers Discussions Admin

compose_email

Compose and send new emails with a preview-first confirmation step, or save messages and attachments to drafts instead.

Instructions

Compose and send a new email (not a reply). SAFETY: requires confirm=true to actually send. Without confirm, returns a preview for user review. With save_draft=true, saves the message (attachments included) to the drafts mailbox instead of sending: no confirm needed, nothing is sent (requires himalaya v2).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "to": "<to>",
      "subject": "<subject>",
      "body": "<body>"
    },
    "name": "compose_email"
  }
}

Input Schema

Name	Required	Description
`cc`	No	CC recipient(s)
`to`	Yes	Recipient email address
`bcc`	No	BCC recipient(s)
`body`	Yes	Email body text
`account`	No	Account name (uses default if omitted)
`confirm`	No	Set to true to actually send. Without this, only shows a preview.
`subject`	Yes	Email subject line
`save_draft`	No	Save to the drafts mailbox instead of sending. Takes precedence over confirm: nothing is sent. Requires himalaya v2.
`attachments`	No	Local file paths to attach (e.g. ["/tmp/report.pdf"])
`drafts_folder`	No	Mailbox (or alias) for save_draft (default: the account's drafts alias)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.2.2Nov 7, 2026

addedInput schema / properties / drafts_folder

Added value: +{
+  "description": "Mailbox (or alias) for save_draft (default: the account's drafts alias)",
+  "type": "string"
+}

addedInput schema / properties / save_draft

Added value: +{
+  "description": "Save to the drafts mailbox instead of sending. Takes precedence over confirm: nothing is sent. Requires himalaya v2.",
+  "type": "boolean"
+}

First observedv1.7.0Jun 21, 2026

TDQS

A3.9/5.0

Behavior4/5

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

No annotations exist, so the description carries the whole burden and does a good job: it discloses the confirm gate, the preview fallback, that save_draft takes precedence over confirm and sends nothing, that attachments are preserved, and a version prerequisite (himalaya v2). It stops short of describing auth/account requirements, failure modes, or what the preview actually contains.

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?

Two tight sentences with the core action front-loaded and the safety semantics immediately after. The "SAFETY:" label earns its place by flagging the destructive-send gate, and there is no filler.

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 10-parameter send mutation with no annotations and no output schema, the description covers the highest-risk behavioral facts an agent needs (send gate, preview, draft mode, precedence, version requirement). Remaining gaps are secondary: account selection, preview payload shape, and error 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 coverage is 100% and each parameter already has its own description, so the structured data does the heavy lifting. The prose reinforces the confirm vs. save_draft precedence relationship, which is a small value-add, but no parameter meaning is added beyond what the schema already states.

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?

The description opens with a specific verb+resource ("Compose and send a new email") and explicitly excludes replies, which separates it from draft_reply. It does not, however, distinguish itself from the sibling send_email, so an agent still has to infer which of the two to call.

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?

Clear conditional guidance: use confirm=true to actually send, omit it for a preview, and use save_draft=true to file it in drafts with no send. The main gap is that it never routes the agent away from the send_email sibling or states when a draft is preferred over a straight send.

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