Send Out

Draft email

draft_email

Read-onlyIdempotent

Drafts one email the user sends themselves. Use when the user wants to email someone or needs an .eml file for Apple Mail, Outlook or Thunderbird. Only body is required. Leave to empty for a draft with no recipient. Returns a mailto: link that opens the email app with recipient, subject and body filled in, plus the full .eml draft text. If the link is over 2,000 characters, warning says so: give the user the .eml text instead. Nothing is sent or stored. Do not use for Instagram, LinkedIn, SMS or bulk email: Send Out cannot send those, so tell the user and offer an email draft instead.

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": {
      "body": "<body>"
    },
    "name": "draft_email"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Optional CC email address or comma-separated addresses.
`to`	No	Recipient address, or several separated by commas, such as "alex@example.com, sam@example.com". Leave empty for a draft with no recipient that the user fills in.
`bcc`	No	Optional BCC email address or comma-separated addresses.
`body`	Yes	Email body as plain text with line breaks (at most 50,000 characters), such as "Hi team, phase 1 is done and ready for review."
`subject`	No	Email subject line, such as "Sprint review notes". Optional.
`filename`	No	Optional .eml filename (without or with .eml).

Output Schema

Name	Required	Description
`notes`	Yes	Short notes to pass on to the user, including any warning.
`status`	Yes	Always ok when the draft was made. Bad input returns an error instead.
`warning`	No	Warning if the mailto URL exceeds safe client length limits.
`filename`	Yes	Suggested file name for the .eml file.
`mailto_url`	Yes	RFC 6068 mailto URI for instant client-side draft opening.
`url_length`	Yes	Total length of the mailto URL.
`eml_content`	Yes	RFC 822/5322 .eml MIME draft text ready to save or open.
`character_count`	Yes	Length of the email body in characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

removedInput schema / examples

Removed value: -[
-  {
-    "body": "Phase 1 is complete and ready for review.",
-    "subject": "Project Milestone",
-    "to": "alex@example.com"
-  }
-]

Changed1 schema field changedOct 15, 2026

addedInput schema / examples

Added value: +[
+  {
+    "body": "Phase 1 is complete and ready for review.",
+    "subject": "Project Milestone",
+    "to": "alex@example.com"
+  }
+]

Changed5 schema fields changedOct 11, 2026

changedInput schema / properties / body / description

Previous value: -"Email body text (at most 50,000 characters). Plain text or formatted with line breaks."New value: +"Email body as plain text with line breaks (at most 50,000 characters), such as \"Hi team, phase 1 is done and ready for review.\""

changedInput schema / properties / subject / description

Previous value: -"Email subject line."New value: +"Email subject line, such as \"Sprint review notes\". Optional."

changedInput schema / properties / to / description

Previous value: -"Recipient email address or comma-separated addresses."New value: +"Recipient address, or several separated by commas, such as \"alex@example.com, sam@example.com\". Leave empty for a draft with no recipient that the user fills in."

addedOutput schema / properties / notes / description

Added value: +"Short notes to pass on to the user, including any warning."

addedOutput schema / properties / status / description

Added value: +"Always ok when the draft was made. Bad input returns an error instead."

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds important operational context: it returns a mailto: link and full .eml text, warns when the link exceeds 2,000 characters, and explicitly states 'Nothing is sent or stored.' This adds real behavioral clarity beyond the annotations.

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 front-loaded with the core purpose and then layers usage, return behavior, limits, and exclusions. Every sentence carries actionable information: the 2,000-character warning and the no-send/no-store guarantee are not redundant with annotations or schema, and the length is justified for a tool with notable output and channel limitations.

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 presence of an output schema, the description need not explain every return field, but it still covers the key return form (mailto link plus .eml text), the size warning, and the fact that nothing is sent or stored. It is complete enough for an agent to invoke the tool correctly.

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 all six parameters. The description reinforces that 'Only body is required' and that 'to' can be left empty, but it does not add syntax, format, or constraint details beyond what the schema provides. Baseline 3 is appropriate.

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 states a specific verb and resource: 'Drafts one email the user sends themselves.' It distinguishes this from siblings like create_x_post and create_whatsapp_link by focusing on email and .eml file generation, and it explicitly warns against using it for other channels. An agent can identify the tool's scope without opening the 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 guidance ('Use when the user wants to email someone or needs an .eml file') and when-not-to-use guidance ('Do not use for Instagram, LinkedIn, SMS or bulk email'), plus a fallback instruction ('tell the user and offer an email draft instead'). This is the kind of routing an agent needs.

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

All Send Out 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.