Skip to main content
Glama
Sign In

Sickle — every mailbox for your agent

by app.sickle
OverviewDiscussionsAdmin

Send an email

email_send
Destructive

Send an email immediately from one of the user's accounts (that account is the From address). Sent email can't be recalled. For an email the user wants to review before it goes, add_draft saves it to Drafts instead. 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. The result lists every file that went, and says where the copy in Sent is: the account's server keeps one or Sickle stores one, so there is no need to save it anywhere yourself.

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
ccYes
toYes
bccYes
fromYesThe account it was sent from.
subjectYes
sent_copyYesWhat became of its copy in the account's Sent folder.
message_idYesThe sent message's Message-ID header.
attachmentsYesThe files attached to it, in order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / $defs / SentCopy
      Added value: +{
+  "description": "A sent message's copy in Sent. Some servers keep one of everything they send; for the\nothers Sickle stores one, so either way there is one.",
+  "properties": {
+    "folder": {
+      "description": "The Sent folder's name, when known.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "kept_by": {
+      "description": "\"server\" when the account's server kept its own copy, \"sickle\" when Sickle stored one\nbecause the server keeps none, null when there is none (see `problem`).",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "problem": {
+      "description": "Why there is no copy, or why it isn't known whether there is one. The message went\nregardless: never a reason to send it again.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
    • addedOutput schema / properties / sent_copy
      Added value: +{
+  "$ref": "#/$defs/SentCopy",
+  "description": "What became of its copy in the account's Sent folder."
+}
    • changedOutput schema / required
      Previous value: -[
-  "from",
-  "to",
-  "cc",
-  "bcc",
-  "subject",
-  "message_id",
-  "attachments"
-]New value: +[
+  "from",
+  "to",
+  "cc",
+  "bcc",
+  "subject",
+  "message_id",
+  "attachments",
+  "sent_copy"
+]
  2. Changed5 schema fields changed
    • addedInput schema / properties / attachment_ids
      Added value: +{
+  "default": [],
+  "description": "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.",
+  "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"
+}
    • removedOutput schema / properties / sent_folder
      Removed value: -{
-  "description": "The folder a copy was filed in. Absent when the provider files its own copy\n(Gmail, Outlook) or when filing one failed.",
-  "type": [
-    "string",
-    "null"
-  ]
-}
    • changedOutput schema / required
      Previous value: -[
-  "from",
-  "to",
-  "cc",
-  "bcc",
-  "subject",
-  "message_id"
-]New value: +[
+  "from",
+  "to",
+  "cc",
+  "bcc",
+  "subject",
+  "message_id",
+  "attachments"
+]
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds real context beyond the annotations: irrevocability, that Sent handling differs by account backend (server vs Sickle) so no manual save is needed, and that attachment_ids are consumed on send. It stops short of noting permission/rate/size failure modes at the description level (the 10-file/25 MB cap lives in the schema).

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?

Front-loaded with the imperative action and the destructive warning, then alternatives, then parameters. Dense but well ordered; the closing sentence about where the Sent copy lives is the one piece that could be trimmed.

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?

For an 8-parameter destructive send tool, the description covers the action, the alternative, the two tricky parameters, and the mutation lifecycle. An output schema exists, yet the description still tells the agent what the result reports, which is a bonus rather than a gap.

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%, so every parameter including in_reply_to and attachment_ids is already documented in the schema, often more precisely (reply-to subfields, MB limits, one-time use). The description restates the attachment sourcing and threading rather than adding new syntax or constraints, so baseline 3 applies.

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?

Specific verb + resource + scope: "Send an email immediately from one of the user's accounts (that account is the From address)". It also draws the boundary against the sibling add_draft, so an agent can pick between them without opening either 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 when-to-use/when-not guidance: "For an email the user wants to review before it goes, add_draft saves it to Drafts instead." It also routes the agent to the correct attachment-staging siblings by source (already in an email vs on disk).

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