Prubex

Create a draft

mail_create_draft

Saves a draft without sending it: a new message (pass account_id when you can reach several accounts), a reply (reply_to_message_id) or a forward (forward_message_id), never both. Use it when the user wants to review before sending. The result's draft.id is the draft_id for mail_send_draft and mail_update_draft. Example: { "reply_to_message_id": "msg_…", "body": { "content": "Draft reply." } }.

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_create_draft"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Copied recipients.
`to`	No	Recipients (required for a new draft or a forward).
`bcc`	No	Blind-copied recipients.
`body`	Yes	The message body. Markdown is converted to HTML for the recipient.
`subject`	No	For a new message; replies and forwards keep theirs.
`reply_all`	No	For a reply: include every recipient.
`account_id`	No	For a new draft: the account to send from.
`attachments`	No	Files for the draft (new, reply or forward), within the account's limit. On a forward the original's attachments are carried too and count toward it.
`idempotency_key`	No	Any unique string. Retrying with the same key within 24 h never repeats the action.
`forward_message_id`	No	Draft a forward of this message.
`reply_to_message_id`	No	Draft a reply to this message.

Output Schema

Name	Required	Description	Default
`draft`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / attachments / items / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "upload_token": {
-        "description": "From attachments_check_upload_status: a file the user uploaded.",
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "upload_token"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "content_base64": {
-        "description": "Base64 content, at most 3 MB decoded for all inline files together. For anything larger, or a file only the user has, ask the user to upload it with attachments_generate_upload_link and pass the upload_token.",
-        "maxLength": 4194304,
-        "type": "string"
-      },
-      "filename": {
-        "description": "The file name the recipient sees.",
-        "maxLength": 255,
-        "minLength": 1,
-        "type": "string"
-      },
-      "mime_type": {
-        "description": "e.g. \"application/pdf\".",
-        "maxLength": 255,
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "filename",
-      "mime_type",
-      "content_base64"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "upload_token": {
+        "description": "From attachments_check_upload_status: a file the user uploaded.",
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "upload_token"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "content_base64": {
+        "description": "Base64 content, at most 3 MB decoded for all inline files together. For a file on your own disk, if you can make HTTP requests, use an upload_token from attachments_generate_upload_link instead (you PUT the file yourself, no base64); for a file only the user has, give them that link.",
+        "maxLength": 4194304,
+        "type": "string"
+      },
+      "filename": {
+        "description": "The file name the recipient sees.",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      },
+      "mime_type": {
+        "description": "e.g. \"application/pdf\".",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "filename",
+      "mime_type",
+      "content_base64"
+    ],
+    "type": "object"
+  }
+]

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, so the safety profile is covered; the description adds the crucial behavioral fact that nothing is sent and that the result's `draft.id` becomes the `draft_id` for later tools. The `account_id` note about multi-account reachability is also practical context. It does not flag rate limits or attachment-limit failure modes beyond what the schema says, so it stops short of a 5.

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 core effect, then mode selection, then the chaining hint, then a compact example — nothing is wasted. The first sentence is dense and packs the three modes into a long parenthetical, which slightly slows parsing, but there is no filler.

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 11-parameter, nested-schema tool with an output schema, the description covers everything an agent needs to choose it and chain its result: purpose, mode selection, account scoping, and the returned draft identifier. Return-value explanation is rightly left to the output schema.

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 100%, so the baseline is 3, but the description adds relational semantics the schema cannot express: reply and forward selectors are mutually exclusive ("never both") and should be omitted for a new draft. The worked example shows a minimal reply payload. It doesn't explain `reply_all` or `idempotency_key` usage beyond the schema field text.

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?

"Saves a draft without sending it" gives a specific verb and resource and immediately distinguishes this from mail_send / mail_send_draft. It then enumerates the three creation modes (new, reply via `reply_to_message_id`, forward via `forward_message_id`), so the agent can tell exactly which sibling tool handles actual sending.

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?

"Use it when the user wants to review before sending" states the selecting condition, and the mode enumeration plus "never both" tells the agent which parameters select which mode. It also names the downstream siblings (mail_send_draft, mail_update_draft), making the intended workflow explicit.

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

All Prubex 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?