Prubex

Check whether a send is allowed

mail_validate_send

Read-onlyIdempotent

A dry run of mail_send: says whether this message would be sent, held for approval, or refused, and why (blocked or unlisted recipients, daily cap, account policy). Nothing is sent. Use it before sending to people outside the user's domain or when unsure of the rules. Example: { "account_id": "acc_…", "to": [{ "email": "ana@contoso.example.com" }], "subject": "Hi", "body": { "content": "…" } }.

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_validate_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.

Output Schema

Name	Required	Description	Default
`outcome`	Yes
`reasons`	Yes
`account_id`	Yes

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.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with "Nothing is sent," then adds real behavioral context: the three possible verdicts and the reasons behind a refusal (blocked or unlisted recipients, daily cap, account policy). It does not mention latency, quota consumption, or whether the dry run must be repeated if anything changes.

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 idea (dry run, nothing sent), then the outcome taxonomy, then the usage rule, then a compact example. Four sentences plus an example is proportionate, though the example is mostly a restatement of the required fields.

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 a 7-parameter nested tool with an output schema, the definition supplies what the schema cannot: what the verdicts mean, why a refusal happens, and when to reach for this instead of sending. Return-value detail is correctly left to 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 coverage is 100%, so the schema already documents every parameter including nested attachment and recipient shapes. The description only adds a sample payload showing that account_id, to, subject and body are the shape used; it does not explain the attachment upload-token versus inline tradeoff or the cc/bcc distinction beyond what the schema says.

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?

States a specific verb and resource: "A dry run of mail_send" that reports whether a message "would be sent, held for approval, or refused, and why." It explicitly positions itself against the sibling mail_send, so an agent can distinguish the two 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 Guidelines4/5

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

Gives an explicit trigger — "Use it before sending to people outside the user's domain or when unsure of the rules" — which is exactly the decision point an agent faces. It does not spell out when not to bother (e.g. routine in-domain sends), but the guidance is concrete enough to act on.

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?