Keeploop

Save reply draft

save_reply_draft

Draft a REPLY that threads under an existing message. Use this, not save_draft, whenever you are answering mail: it sets In-Reply-To and References from the parent, so Gmail and Outlook file the reply in the original conversation instead of starting a new one. This tool never sends it (send_reply sends, if the user's permissions allow). Identify the parent by mail_id (from search_mail) or by its RFC Message-ID. Recipients, sending account and the Re: subject all come from the parent: reply_all=false answers the sender alone, reply_all=true copies everyone except your own addresses. The original is quoted beneath your body. The returned in_reply_to is read back off the saved draft's own file on disk, so it is proof the reply threads rather than a claim; the call fails rather than returning an unthreaded draft as a success. Mail stays in the background. body_method says how the body went in: 'signature' keeps Mail's own formatted quote; 'plain_quote' quotes the original as plain > lines (replies with attachments, or when Mail would put the text below the quote) and note says why. category (e.g. 'Personal') refuses a parent outside accounts with that label. By default the saved draft (new or reply) stays open in a Mail window so the user can review, edit and send it there; the user can turn that off in Keeploop. Pass leave_open=false to save quietly or true to force the window. Omit it to follow the user's setting. left_open says what happened. Accounts are labelled (Personal, Work, ...). For a personal task use the Personal accounts; call list_categories if unsure. attachments takes files already in the user's mail as {mail_id, attachment_id} (from get_email or find_attachments; Mail downloads one it has not stored yet), and absolute paths of files in the user's home folder (not hidden ones or ~/Library; from web and phone apps only as the user's Attach files from this Mac permission allows). Up to 18 MB in total. The user sees every file's name and size in the confirmation. Requires Keeploop Pro.

Input Schema

Name	Required	Description	Default
`body`	Yes
`mail_id`	No
`category`	No
`reply_all`	No
`leave_open`	No
`message_id`	No
`attachments`	No

Output Schema

Name	Required	Description	Default
`cc`	Yes
`to`	Yes
`note`	No
`sender`	No
`account`	Yes
`subject`	Yes
`draft_id`	No
`left_open`	No
`references`	No
`rich_quote`	No
`attachments`	No
`body_method`	No
`in_reply_to`	No
`threads_under`	Yes
`saved_to_drafts`	Yes
`threading_verified`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedInput schema / $defs

Added value: +{
+  "AttachmentRef": {
+    "description": "An attachment already in the user's mail: get_email / find_attachments ids.",
+    "properties": {
+      "attachment_id": {
+        "title": "Attachment Id",
+        "type": "string"
+      },
+      "mail_id": {
+        "title": "Mail Id",
+        "type": "integer"
+      }
+    },
+    "required": [
+      "mail_id",
+      "attachment_id"
+    ],
+    "title": "AttachmentRef",
+    "type": "object"
+  }
+}

changedInput schema / properties / attachments / anyOf

Previous value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "$ref": "#/$defs/AttachmentRef"
+        }
+      ]
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

First observedOct 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only supply a generic safety profile (readOnly=false, destructive=false, idempotent=false); the description goes far beyond that with threading semantics (In-Reply-To/References derived from parent), the guarantee that it fails rather than returning an unthreaded draft, the disk-verified in_reply_to, quote behavior for replies with attachments, the 18 MB attachment cap, the leave_open tri-state default inherited from user settings, and the Keeploop Pro requirement.

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?

Dense and front-loaded with the differentiator first, and every sentence carries information. It is, however, one long run-on block that interleaves inputs, outputs and policy, which slightly taxes scanning.

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?

Complete for a mutation tool with an output schema: it explains returned signals (in_reply_to, left_open, body_method plus the 'note' reason), permission constraints, attachment sourcing, and the Pro gate. Nothing an agent needs to call it correctly 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?

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and does: mail_id vs message_id identification, reply_all true/false recipient semantics, category as an account-label gate with an example, attachments as {mail_id, attachment_id} or absolute home-folder paths with exclusions and size limit, and the omit/true/false meaning of leave_open.

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?

States a specific verb+resource ('Draft a REPLY that threads under an existing message') and immediately distinguishes itself from both save_draft and send_reply by name and by behavior. An agent can select the right tool without opening any 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?

Explicit routing: 'Use this, not save_draft, whenever you are answering mail', plus 'This tool never sends it (send_reply sends, if the user's permissions allow)'. It also gives the alternative parent-identifier sources (mail_id from search_mail, or RFC Message-ID) and points to list_categories when unsure.

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

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