Skip to main content
Glama

Mailrith Email Marketing

by com.mailrith

Send a broadcast test email

broadcasts_send_test
Destructive

Sends a test message from an existing Broadcast that has an email delivery connection. Provide a saved Subscriber ID for personalization; use subscribers_list to find one when needed. The recipient may be any test inbox and does not have to match the saved Subscriber. Effect: external-email. Retry with the same idempotency_key. Permissions: live_actions:write, subscribers:read, broadcasts:write. API reference: https://mailrith.com/developers/api-reference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesThe exact JSON request body defined by the Mailrith public API contract.
broadcast_idYesThe broadcast identifier.
idempotency_keyNoOptional idempotency key to retry the request safely. It must not exceed 256 UTF-8 bytes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
responseNo
request_idYesThe stable correlation ID for this MCP tool invocation.
operation_idYesThe stable Mailrith public API operation ID.

Schema Changelog

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

  1. Changed1 schema field changed
    • addedOutput schema / $defs / BroadcastTestResult / properties / provider_message_ids
      Added value: +{
+  "description": "Provider acceptance IDs in sent-message order; null when unavailable. These are not delivery or inbox receipts.",
+  "items": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "maxItems": 5,
+  "minItems": 1,
+  "type": "array"
+}
  2. Changed4 schema fields changed
    • addedInput schema / $defs / BroadcastTestRequest / properties / recipient / description
      Added value: +"The inbox that receives the test message. It may differ from the saved Subscriber used for personalization."
    • changedInput schema / $defs / BroadcastTestRequest / properties / subscriber_id / description
      Previous value: -"The saved Subscriber whose personalization should be rendered in the test message."New value: +"Required saved Subscriber ID whose profile supplies personalization. Use subscribers_list to find one before sending the test when needed."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional idempotency key to make retries safe."New value: +"Optional idempotency key to retry the request safely. It must not exceed 256 UTF-8 bytes."
    • addedInput schema / properties / idempotency_key / maxLength
      Added value: +256
  3. Changed4 schema fields changed
    • removedInput schema / $defs / BroadcastTestRequest / properties / recipient / description
      Removed value: -"The inbox that receives the test message. It may differ from the saved Subscriber used for personalization."
    • changedInput schema / $defs / BroadcastTestRequest / properties / subscriber_id / description
      Previous value: -"Required saved Subscriber ID whose profile supplies personalization. Use subscribers_list to find one before sending the test when needed."New value: +"The saved Subscriber whose personalization should be rendered in the test message."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional idempotency key to retry the request safely. It must not exceed 256 UTF-8 bytes."New value: +"Optional idempotency key to make retries safe."
    • removedInput schema / properties / idempotency_key / maxLength
      Removed value: -256
  4. Changed2 schema fields changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional idempotency key to make retries safe."New value: +"Optional idempotency key to retry the request safely. It must not exceed 256 UTF-8 bytes."
    • addedInput schema / properties / idempotency_key / maxLength
      Added value: +256
  5. Changed2 schema fields changed
    • addedInput schema / $defs / BroadcastTestRequest / properties / recipient / description
      Added value: +"The inbox that receives the test message. It may differ from the saved Subscriber used for personalization."
    • changedInput schema / $defs / BroadcastTestRequest / properties / subscriber_id / description
      Previous value: -"The saved Subscriber whose personalization should be rendered in the test message."New value: +"Required saved Subscriber ID whose profile supplies personalization. Use subscribers_list to find one before sending the test when needed."
  6. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already carry the basic safety profile, but the description adds meaningful behavioral disclosures: 'Effect: external-email', guidance to retry with the same idempotency_key, and required permissions. These go beyond the structured annotations and help an agent understand side effects, retry behavior, and authorization needs. No contradiction with annotations is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: core action first, then param guidance, then side-effect/permission/reference details. Each sentence contributes either a required precondition, a usage instruction, or retrieval guidance. There is no redundant restatement of the schema or title.

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 tool with three parameters, one nested object, an output schema, and a sibling set, the description covers the essential operational details: target Broadcast requirement, recipient flexibility, subscriber_id sourcing, idempotency retry behavior, external-email side effect, and required permissions. The API reference supplies further depth. Nothing critical is missing for an agent to invoke it correctly.

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 100%, putting the baseline at 3. The description adds value by explaining the relationship between recipient and subscriber_id ('does not have to match'), how to source subscriber_id via subscribers_list, and the meaning of idempotency_key for safe retries. Only broadcast_id and the body wrapper receive no extra semantic enrichment, so 4 is appropriate.

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 opens with a specific verb and resource: 'Sends a test message from an existing Broadcast that has an email delivery connection.' This differentiates it from the broader broadcasts_send and from automations_send_test/sequences_send_test by scoping to Broadcasts and test-only delivery. The 'existing Broadcast' and 'email delivery connection' qualifiers make the tool's purpose unmistakable.

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?

The description gives clear operational context: this is for testing an existing Broadcast with an email delivery connection, and it explains how to find a Subscriber ID (subscribers_list). It also clarifies recipient flexibility. It does not explicitly state when to avoid this tool in favor of broadcasts_send or other send-test siblings, so it falls just short of a 5.

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

All Mailrith Email Marketing 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

A3.8/5.0
Disambiguation5/5

Every tool is prefixed by its resource and targets a unique action, so there is no real overlap between tools. Even similar operations like preflight, preview_journey, and send_test are clearly separated by resource and described with distinct effects.

Naming Consistency5/5

All tools follow a consistent `resource_action` snake_case pattern, e.g., broadcasts_create, subscribers_upsert, sequences_update_status. Custom verbs like cancel, unschedule, and preview_journey still fit the same predictable convention.

Tool Count1/5

55 tools is an extreme count for a single MCP server, making it difficult for an agent to efficiently discover and choose among the surface. While each tool appears justified, the size suggests the API should be split into focused servers by resource domain.

Completeness3/5

The broadcast, automation, sequence, and subscriber workflows are well covered with lifecycle operations. However, custom fields and segments only have read/list/preview operations with no create, update, or delete, and several resources lack delete endpoints, leaving notable gaps for full lifecycle management.

Resources