Prubex

Reply to an email

mail_reply

Replies to a message from the account that received it, keeping the conversation and quoting the original; reply_all includes everyone; cc and bcc add people. Use it to answer mail in its thread. Returns sent. It can return pending_approval: tell the user a person must approve it in Prubex, and do not retry. Example: { "message_id": "msg_…", "body": { "content": "Thanks, confirmed." } }.

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": {
      "message_id": "<message_id>",
      "body": "<body>"
    },
    "name": "mail_reply"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Extra people to copy, as `{ email, name? }`, on top of whom the reply already goes to (the sender, or everyone with `reply_all`). Nobody is listed twice.
`bcc`	No	Extra people to blind-copy, as `{ email, name? }`. Someone the reply already reaches stays visible where they are.
`body`	Yes	The message body. Markdown is converted to HTML for the recipient.
`reply_all`	No	Reply to every recipient, not just the sender.
`message_id`	Yes	A message id (`msg_…`) from a list or search.
`attachments`	No	Files to attach to the reply, within the account's limit.
`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.

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"
+  }
+]

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / bcc

Added value: +{
+  "description": "Extra people to blind-copy, as `{ email, name? }`. Someone the reply already reaches stays visible where they are.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "email": {
+        "description": "The email address.",
+        "format": "email",
+        "type": "string"
+      },
+      "name": {
+        "description": "Display name.",
+        "maxLength": 200,
+        "type": "string"
+      }
+    },
+    "required": [
+      "email"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "type": "array"
+}

addedInput schema / properties / cc

Added value: +{
+  "description": "Extra people to copy, as `{ email, name? }`, on top of whom the reply already goes to (the sender, or everyone with `reply_all`). Nobody is listed twice.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "email": {
+        "description": "The email address.",
+        "format": "email",
+        "type": "string"
+      },
+      "name": {
+        "description": "Display name.",
+        "maxLength": 200,
+        "type": "string"
+      }
+    },
+    "required": [
+      "email"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "type": "array"
+}

First observedNov 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, destructiveHint=false, idempotentHint=false, so the bar is lower, yet the description still adds real context: the reply is threaded and quotes the original, returns `sent`, and may return `pending_approval` — in which case the agent must inform the user and not retry. That approval-path instruction is genuinely useful behavior not derivable from annotations.

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?

The core behavior is front-loaded in the first clause, followed by the key flags, the return values, and one example. Slight redundancy between "Replies to a message" and "Use it to answer mail in its thread" keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, nested-object mutation with an output schema, the description covers the essential behavior, the threading/quoting semantics, and the approval exception. Attachments and idempotency handling are only covered in the schema, which is acceptable given 100% schema coverage and the output schema.

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 every parameter thoroughly. The description restates the meaning of `reply_all`, `cc` and `bcc` in slightly plainer terms and provides an example call, but adds no format or constraint detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Replies to a message") plus scope ("from the account that received it"), and adds the distinctive behaviors: keeps the conversation and quotes the original. It does not name a sibling such as mail_send or mail_forward to draw the boundary, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it to answer mail in its thread" gives a positive usage cue, and the pending_approval instruction tells the agent what to do on that outcome. There is no explicit when-not guidance or named alternative (e.g., mail_forward for redirecting, mail_create_draft for composing without sending), so selection between siblings is left to inference.

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?