Skip to main content
Glama

email

by dev.primitive

Preview a send (simulated, nothing is delivered)

sendEmailDemo
Read-onlyIdempotent

SIMULATION ONLY: nothing is delivered. NEVER call this when the user actually wants an email to arrive, and never describe its result as a sent email: no message is sent, queued, or stored, and the recipient receives nothing. To really send with no account, call createEmailAddress (instant, no signup form and no verification) and then sendEmail with the api_key it returns; that is the correct path for any genuine send request. This tool exists only to preview the response shape: it validates the body against the exact same schema as sendEmail (including cc/bcc, reply_to, tags, attachments, and scheduled_at) and returns a synthetic success envelope marked demo: true. Demo requests are capped at 16KB total body, so large attachments are rejected even though the schema allows them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestBodyYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
toolYes
statusYes
statusTextNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / from / description
      Previous value: -"RFC 5322 From header. The sender domain must be a verified outbound domain for your organization."New value: +"RFC 5322 From header: YOUR OWN complete mailbox address, never the recipient's. createEmailAddress.address and getAccount.managed_inbox_address are domains, not mailbox addresses. When present, use the sender_address added to those MCP results, such as agent@pink-ram.primitive.email. Putting the recipient's address here mails them as themselves, which they will ignore. The sender domain must be a verified outbound domain for your organization."
  2. Changed18 schema fields changed
    • addedInput schema / properties / requestBody / properties / attachments
      Added value: +{
+  "description": "Optional file attachments. Not allowed on scheduled sends (scheduled_at).",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "content_base64": {
+        "description": "Base64-encoded attachment content.",
+        "maxLength": 44040192,
+        "minLength": 1,
+        "type": "string"
+      },
+      "content_id": {
+        "description": "Content-ID for an inline (cid) attachment: 1-128 printable ASCII characters, no whitespace or angle brackets. When set, the part renders inline and body_html can reference it (e.g. src=\"cid:logo-1\"). Omit for a regular downloadable attachment.",
+        "maxLength": 128,
+        "minLength": 1,
+        "pattern": "^[\\x21-\\x3B\\x3D\\x3F-\\x7E]+$",
+        "type": "string"
+      },
+      "content_type": {
+        "description": "MIME type of the attachment (e.g. \"application/pdf\"). Inferred from the filename when omitted.",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      },
+      "filename": {
+        "description": "Attachment filename including extension.",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "filename",
+      "content_base64"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "type": "array"
+}
    • addedInput schema / properties / requestBody / properties / bcc
      Added value: +{
+  "description": "Optional BCC recipients: a single address or an array of single-address strings (each entry exactly one address). Counts toward the combined to+cc+bcc max of 100.",
+  "oneOf": [
+    {
+      "maxLength": 998,
+      "minLength": 3,
+      "type": "string"
+    },
+    {
+      "items": {
+        "maxLength": 998,
+        "minLength": 3,
+        "type": "string"
+      },
+      "maxItems": 100,
+      "minItems": 1,
+      "type": "array"
+    }
+  ]
+}
    • changedInput schema / properties / requestBody / properties / body_html / description
      Previous value: -"HTML message body."New value: +"HTML message body. Provide at least one of body_text or body_html. Reference inline attachments via cid: URLs matching their content_id."
    • changedInput schema / properties / requestBody / properties / body_text / description
      Previous value: -"Plain-text message body."New value: +"Plain-text message body. Provide at least one of body_text or body_html."
    • addedInput schema / properties / requestBody / properties / cc
      Added value: +{
+  "description": "Optional CC recipients: a single address or an array of single-address strings (each entry exactly one address). Counts toward the combined to+cc+bcc max of 100.",
+  "oneOf": [
+    {
+      "maxLength": 998,
+      "minLength": 3,
+      "type": "string"
+    },
+    {
+      "items": {
+        "maxLength": 998,
+        "minLength": 3,
+        "type": "string"
+      },
+      "maxItems": 100,
+      "minItems": 1,
+      "type": "array"
+    }
+  ]
+}
    • changedInput schema / properties / requestBody / properties / from / description
      Previous value: -"RFC 5322 From header. For the demo any well-formed sender is accepted; nothing is sent."New value: +"RFC 5322 From header. The sender domain must be a verified outbound domain for your organization."
    • addedInput schema / properties / requestBody / properties / in_reply_to
      Added value: +{
+  "description": "Message-ID of the email being replied to, for threading (e.g. \"<abc@example.com>\").",
+  "maxLength": 998,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / requestBody / properties / references
      Added value: +{
+  "description": "List of Message-IDs for the References header, oldest-first.",
+  "items": {
+    "maxLength": 998,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "type": "array"
+}
    • addedInput schema / properties / requestBody / properties / reply_to
      Added value: +{
+  "description": "Optional Reply-To header: a single address or an array of up to 10 single-address entries. A pure header: adds no recipients and does not count toward the recipient cap.",
+  "oneOf": [
+    {
+      "maxLength": 998,
+      "minLength": 3,
+      "type": "string"
+    },
+    {
+      "items": {
+        "maxLength": 998,
+        "minLength": 3,
+        "type": "string"
+      },
+      "maxItems": 10,
+      "minItems": 1,
+      "type": "array"
+    }
+  ]
+}
    • addedInput schema / properties / requestBody / properties / scheduled_at
      Added value: +{
+  "description": "Schedule the send for a future time (ISO 8601 UTC, e.g. \"2026-08-01T09:00:00Z\"). Must be strictly in the future and at most 30 days out. Cannot be combined with wait or with attachments. Cancel before dispatch with cancelScheduledSend.",
+  "format": "date-time",
+  "type": "string"
+}
    • addedInput schema / properties / requestBody / properties / tags
      Added value: +{
+  "description": "Optional metadata tags (max 10, unique names) stored on the send record for correlation and filtering via listSentEmails. Never rendered into headers and never delivered.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "description": "Tag name: ASCII letters, digits, underscores, dashes only.",
+        "maxLength": 64,
+        "minLength": 1,
+        "pattern": "^[A-Za-z0-9_-]+$",
+        "type": "string"
+      },
+      "value": {
+        "description": "Tag value: same charset as the name. Use \"true\" for a bare marker tag.",
+        "maxLength": 256,
+        "minLength": 1,
+        "pattern": "^[A-Za-z0-9_-]+$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "value"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "type": "array"
+}
    • changedInput schema / properties / requestBody / properties / to / description
      Previous value: -"Recipient email address. Nothing is delivered in demo mode."New value: +"Recipient email address (RFC 5321 mailbox, display-name form allowed), or an array of single-address strings to address multiple recipients with one message. Each array entry must be exactly one address. Combined to+cc+bcc count max 100."
    • removedInput schema / properties / requestBody / properties / to / maxLength
      Removed value: -320
    • removedInput schema / properties / requestBody / properties / to / minLength
      Removed value: -3
    • addedInput schema / properties / requestBody / properties / to / oneOf
      Added value: +[
+  {
+    "maxLength": 998,
+    "minLength": 3,
+    "type": "string"
+  },
+  {
+    "items": {
+      "maxLength": 998,
+      "minLength": 3,
+      "type": "string"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  }
+]
    • removedInput schema / properties / requestBody / properties / to / type
      Removed value: -"string"
    • addedInput schema / properties / requestBody / properties / wait
      Added value: +{
+  "description": "When true, wait for the first SMTP delivery outcome before returning. Respects wait_timeout_ms. Cannot be combined with scheduled_at.",
+  "type": "boolean"
+}
    • addedInput schema / properties / requestBody / properties / wait_timeout_ms
      Added value: +{
+  "description": "How long to wait for delivery confirmation when wait is true (1000-30000 ms, default 10000).",
+  "maximum": 30000,
+  "minimum": 1000,
+  "type": "number"
+}
  3. Changed4 schema fields changed
    • addedInput schema / properties / requestBody / properties / body_html / description
      Added value: +"HTML message body."
    • addedInput schema / properties / requestBody / properties / body_text / description
      Added value: +"Plain-text message body."
    • addedInput schema / properties / requestBody / properties / subject / description
      Added value: +"Email subject line."
    • addedInput schema / properties / requestBody / properties / to / description
      Added value: +"Recipient email address. Nothing is delivered in demo mode."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint and idempotentHint and destructiveHint=false, but the description adds significant behavioral details: no message is sent, queued, or stored; recipient receives nothing; validates against the exact sendEmail schema; returns an envelope with demo:true; and enforces a 16KB total body cap. All this context is beyond what annotations provide and is consistent with them.

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 description is moderately lengthy but every sentence adds value: simulation warning, when-not-to-use, alternative tool path, validation coverage, size limit. It is front-loaded with the critical simulation warning and well-structured. Could trim slightly but is effectively composed.

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?

Given the tool's complexity (nested object parameter, many fields, output schema exists), the description covers purpose, usage constraints, behavioral details, and size limits. It refers to the output schema implicitly by describing the synthetic envelope. The presence of an output schema reduces the need to describe return values in detail, so the description is complete for an agent to correctly select and invoke this tool.

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 description coverage is 0%, but the description provides meaningful context about the requestBody parameter: it validates against the sendEmail schema (including cc/bcc, reply_to, tags, attachments, scheduled_at) and has a 16KB total body limit that can reject large attachments. This adds practical constraints not captured in the schema alone, earning a score above the baseline of 3.

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?

The description clearly states the tool is a simulation that previews a send by validating the request body against the same schema as sendEmail and returning a synthetic envelope with demo:true. It explicitly distinguishes from the actual sendEmail tool and provides the correct alternative using createEmailAddress and sendEmail. Scope and resource are unambiguous.

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?

The description explicitly warns when NOT to use this tool (when the user wants an email delivered) and provides the correct alternative path (createEmailAddress then sendEmail). It also clarifies that the tool exists only to preview the response shape, giving clear context for appropriate invocation.

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

All email toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: domain management (addDomain, verifyDomain), sending (sendEmail, replyToEmail), receiving (getEmail, listEmails), webhooks (createEndpoint, listWebhookDeliveries), status (getAccount, getInboxStatus), etc. There is no overlap in purpose, and descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case, such as listDomains, createFilter, downloadEmailAttachments, and getSentEmail. The verbs (get, list, create, delete, send, reply, etc.) are used predictably, with no mixing of conventions.

Tool Count4/5

29 tools is slightly on the high side but still reasonable for an email server covering domains, sending, receiving, webhooks, filters, and status. Each tool serves a specific purpose and earns its place, though some consolidation might be possible.

Completeness4/5

The tool set covers core email workflows: domain setup (add, verify, list), sending/receiving, threading, webhook lifecycle, and filtering. Minor gaps exist, such as missing deleteDomain or updateEndpoint, but the surface is largely complete for the intended domain.

Resources