Skip to main content
Glama
Sign In

Sickle — every mailbox for your agent

by app.sickle
OverviewDiscussionsAdmin

Save a draft

add_draft

Save an email to the account's Drafts folder without sending it, for the user to review, edit and send from their mail client. Pass in_reply_to to thread a reply under the email it answers, and attachment_ids to attach files: from stage_attachment_from_email for a file already in an email, or prepare_attachment_upload for one on disk.

Input Schema

NameRequiredDescriptionDefault
ccNoCarbon-copy recipients, in the same form as `to`
toYesRecipients, e.g. ["alice@example.com", "Bob Smith <bob@example.com>"]
bccNoBlind-copy recipients, in the same form as `to`
bodyYesPlain-text body
emailYesThe account to write from, as listed by list_accounts. It is also the From address.
subjectYesSubject line. For a reply, the original subject prefixed with "Re: ".
in_reply_toNoThe email this one replies to. Threads the new message under it in every mail client. The original's text is not added: `body` is the whole of what is sent.
attachment_idsNoFiles to attach, each an attachment_id from stage_attachment_from_email (a file already in an email) or prepare_attachment_upload (a file uploaded). At most 10, together within 25 MB once encoded for email. Each can be used once: once the email is saved or sent, its files are deleted.

Output Schema

NameRequiredDescriptionDefault
uidNoThe draft's UID in that folder, when the server reports it.
mailboxYesThe Drafts folder the draft was saved to.
message_idYesThe draft's Message-ID header.
attachmentsYesThe files attached to it, in order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / attachment_ids / description
      Previous value: -"Files to attach, each an attachment_id from a finished upload\n(prepare_attachment_upload). At most 10, together within 25 MB once encoded for\nemail. Each can be used once: after the draft is saved, its files are deleted."New value: +"Files to attach, each an attachment_id from stage_attachment_from_email (a file already in\nan email) or prepare_attachment_upload (a file uploaded). At most 10, together within 25 MB\nonce encoded for email. Each can be used once: once the email is saved or sent, its files\nare deleted."
  2. Changed4 schema fields changed
    • addedInput schema / properties / attachment_ids
      Added value: +{
+  "default": [],
+  "description": "Files to attach, each an attachment_id from a finished upload\n(prepare_attachment_upload). At most 10, together within 25 MB once encoded for\nemail. Each can be used once: after the draft is saved, its files are deleted.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / $defs
      Added value: +{
+  "AttachedFile": {
+    "description": "One file attached to an email.",
+    "properties": {
+      "filename": {
+        "type": "string"
+      },
+      "mime_type": {
+        "type": "string"
+      },
+      "size": {
+        "description": "Size in bytes, before encoding.",
+        "format": "uint64",
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "filename",
+      "size",
+      "mime_type"
+    ],
+    "type": "object"
+  }
+}
    • addedOutput schema / properties / attachments
      Added value: +{
+  "description": "The files attached to it, in order.",
+  "items": {
+    "$ref": "#/$defs/AttachedFile"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "mailbox",
-  "message_id"
-]New value: +[
+  "mailbox",
+  "message_id",
+  "attachments"
+]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-idempotent and non-destructive behavior. The description adds useful behavioral context beyond that: the draft lands in Drafts, is not sent, can be reviewed/edited/sent later, and in_reply_to threads the draft under the original email.

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?

Two tightly written sentences with no filler. The core behavior is front-loaded, followed by the two most relevant parameter relationships.

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?

The definition is complete enough for this mutation tool: annotations cover safety/idempotency traits, the schema richly documents all parameters including attachment limits and lifecycle, and an output schema exists. The description supplies the essential purpose and no-send 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 description coverage is 100%, so the schema already documents parameters thoroughly. The description mentions in_reply_to and attachment_ids with their helper tools, but largely repeats what the schema already says and adds no new syntax, limits or format detail.

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: saving an email to the account's Drafts folder. It immediately distinguishes this from sending by saying 'without sending it' and explains the resulting draft is for review, editing and later sending.

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?

It gives clear usage context: use this to save a draft rather than send immediately, and it routes attachment inputs to stage_attachment_from_email or prepare_attachment_upload. It does not explicitly name email_send as the alternative, but the no-send condition is clear enough.

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

All Sickle — every mailbox for your agent toolsInspect
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