OrgLines

Mail: Save draft

mail_save_draft

Write a reply (or a new letter) into the caller's Drafts and STOP there — nothing is sent. This is the safe half of answering mail: the agent composes, the person reads it in their mail client and presses send. Pass reply_to_message_id to answer a message: the recipient, the subject and the threading headers are taken from the stored message, so the reply goes back to whoever wrote, not to an address quoted inside the letter. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": "mail_save_draft"
  }
}

Input Schema

Name	Required	Description
`to`	No	Recipients. Required for a NEW letter; overrides the sender when replying.
`body`	Yes
`mailbox`	No	Which of the caller's mailboxes to write from (label). Required only for a new letter when the caller has more than one.
`subject`	No
`attachments`	No	Files to attach, at most 10 and 25 MB in total. Each item is EITHER {from_message_id, part} — an attachment of a message (id from mail_list_messages, part from mail_get_message) — OR {document_id} — one of the caller's own Documents. To attach a file you generated, store it with upload_document_base64 and pass the document_id it returns; raw file content is not accepted here.
`reply_to_message_id`	No	Answer this message (id from mail_list_messages). Answering a company-mailbox message replies FROM that mailbox.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the critical two-phase confirmation protocol: status='confirmation_required', action_id, plan_token, and that the write occurs only after confirm_action. It also explains that nothing is sent and that reply threading and recipients come from the stored message rather than quoted addresses. This is exactly the behavioral context an agent needs for a write-like tool.

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 safety boundary, then adds reply behavior and the confirmation protocol. Every sentence carries operational information, and the explicit CONFIRMATION section is easy to scan.

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 six-parameter drafting tool with no output schema, the description covers the critical workflow, confirmation response, and reply semantics well. It omits prose explanation of attachments and new-letter parameter requirements, but those are covered by the input schema, leaving only a minor completeness gap.

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

Parameters4/5

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

Schema coverage is 67%, and the description adds meaningful semantics for reply_to_message_id: the recipient, subject, and threading headers are taken from the stored message, so the reply goes to the original writer rather than a quoted address. It does not add prose meaning for attachments, mailbox, or the new-letter requirements, but those are documented in the schema.

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: writing a reply or new letter into the caller's Drafts. It immediately distinguishes the tool from sending mail by saying it stops at the draft and that the person presses send. An agent can tell exactly what this tool does 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 Guidelines4/5

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

The description gives clear usage context: use this for composing replies or new letters without sending, and expect a confirmation flow before any write. It does not explicitly route to sibling tools such as mail_update_draft for editing an existing draft, but the when-to-use guidance is clear and actionable.

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

All OrgLines 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.

Resources

Need Help?