Prubex

Send an email

mail_send

Sends a new email from one account. Use it when the user asks to email someone; to answer an existing email use mail_reply (it keeps the thread), and to let the user review first use mail_create_draft. Returns sent. It can return pending_approval: tell the user a person must approve it in Prubex, and do not retry. Pass account_id when you can reach more than one account that can send; check the rules first with mail_validate_send if unsure. Example: { "account_id": "acc_…", "to": [{ "email": "ana@contoso.example.com" }], "subject": "Lunch", "body": { "content": "Friday at 1?" } }.

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": {
      "to": "<to>",
      "subject": "<subject>",
      "body": "<body>"
    },
    "name": "mail_send"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Copied recipients.
`to`	Yes	Recipients, as `{ email, name? }`.
`bcc`	No	Blind-copied recipients.
`body`	Yes	The message body. Markdown is converted to HTML for the recipient.
`subject`	Yes	The subject line.
`account_id`	No	The account to act on (`acc_…` from accounts_list). Required when more than one account could do this; otherwise the error lists the candidates.
`attachments`	No	Files to attach: each an `upload_token`, or `filename` + `mime_type` + `content_base64` (inline, at most 3 MB in all). For a file on your own disk, use an upload token from attachments_generate_upload_link, which you can fill yourself over HTTP. All files together must fit the account's own limit, e.g. 25 MB for Gmail, 35 MB by default for Microsoft 365.
`idempotency_key`	No	Any unique string. Retrying with the same key within 24 h never repeats the action.

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes	What happened, in words for the user.
`thread_id`	No
`account_id`	Yes
`expires_at`	No	When held: when the request expires.
`message_id`	No	The sent message, when the provider reports it.
`review_url`	No	When held: where a person approves it in Prubex.
`approval_id`	No	When held: pass it to approvals_get later.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

changedInput schema / properties / attachments / description

Previous value: -"Files to attach: each an `upload_token`, or `filename` + `mime_type` + `content_base64` (inline, at most 3 MB in all). All files together must fit the account's own limit, e.g. 25 MB for Gmail, 35 MB by default for Microsoft 365."New value: +"Files to attach: each an `upload_token`, or `filename` + `mime_type` + `content_base64` (inline, at most 3 MB in all). For a file on your own disk, use an upload token from attachments_generate_upload_link, which you can fill yourself over HTTP. All files together must fit the account's own limit, e.g. 25 MB for Gmail, 35 MB by default for Microsoft 365."

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 readOnlyHint=false, openWorldHint=true and destructiveHint=false, so the description's added value is the outcome disclosure: it returns `sent`, or `pending_approval` in which case the user must approve in Prubex and the call must not be retried. That approval-path warning is genuinely useful context beyond the annotations, though it doesn't discuss rate limits, quota errors, or what happens to attachments on failure.

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 purpose, then routing, then return states, then parameter guidance, then an example — a sensible order with no filler sentences. The inline JSON example is long but demonstrates the nested body/recipient structure, which is the main shape an agent could get wrong.

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, deeply nested, open-world send tool, the description covers purpose, alternatives, approval outcome, account selection and a sample payload, while the schema and output schema carry the field-level detail. Nothing essential to calling it correctly appears missing.

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 real decision guidance: pass `account_id` when more than one account can send, and a concrete example payload showing the nested `to`/`body.content` shape. It stops short of explaining idempotency_key or attachment trade-offs in prose, leaving those to 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?

"Sends a new email from one account" gives a specific verb plus resource and scope, and the description immediately distinguishes it from mail_reply (keeps thread) and mail_create_draft (review first). An agent can pick this tool over its siblings 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 is provided: use this when the user asks to email someone, use mail_reply to answer an existing email, use mail_create_draft when the user wants to review first, and consult mail_validate_send if unsure about rules. That covers when-to-use, when-to-use-something-else, and the pre-check option.

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?