Mailrith Email Marketing

Send a broadcast test email

broadcasts_send_test

Destructive

Sends a test message from an existing Broadcast that has a sender. 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.

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": {
      "broadcast_id": "<broadcast_id>",
      "body": "<body>"
    },
    "name": "broadcasts_send_test"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	The exact JSON request body defined by the Mailrith public API contract.
`broadcast_id`	Yes	The broadcast identifier.
`idempotency_key`	No	Optional idempotency key to retry the request safely. It must not exceed 256 UTF-8 bytes.

Output Schema

Name	Required	Description
`error`	No
`response`	No
`request_id`	Yes	The stable correlation ID for this MCP tool invocation.
`operation_id`	Yes	The stable Mailrith public API operation ID.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 5, 2026

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

Changed4 schema fields changedSep 3, 2026

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
```

Changed4 schema fields changedSep 3, 2026

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
```

Changed2 schema fields changedAug 21, 2026

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
```

Changed2 schema fields changedAug 14, 2026

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

First observedJul 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With annotations already declaring destructiveHint=true and openWorldHint=true, the description adds the external side effect ('Effect: external-email'), the prerequisite that the Broadcast must already exist and have a sender, the three required permissions, and safe-retry guidance via idempotency_key. The idempotency advice is consistent with idempotentHint=false (safety comes from the key, not from the call itself), so there is no contradiction. What it lacks is any statement about partial failure or what a failed send does to state.

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 action and precondition, then usage, effect, retry, and permissions in a compact telegraphic style that is easy to scan. A few fragments ('Effect: external-email.') are terse to the point of opacity, but nothing is redundant.

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 3-parameter nested-body write tool with annotations and an output schema, the description covers preconditions, parameter intent, side effects, retry semantics, and permissions. Only failure handling and any rate or quota limits are absent, which is a modest gap rather than a blocking one.

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 schema alone would justify a 3. The description goes beyond it by constraining broadcast_id to an existing Broadcast with a sender, explaining that subscriber_id exists purely for personalization, and clarifying that recipient is unconstrained relative to the Subscriber — all decision-relevant semantics not stated in 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?

States a specific verb and resource ('Sends a test message from an existing Broadcast') and immediately narrows scope with the 'test' qualifier, which is what separates it from broadcasts_send. The 'has a sender' precondition further pins down the tool's domain.

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 concrete prereq guidance: a saved Subscriber ID is needed for personalization, and subscribers_list is named as the way to obtain one. It also clarifies that the recipient inbox may differ from the saved Subscriber, removing a common misuse. It does not explicitly contrast with broadcasts_send, so an agent must infer the test-vs-live distinction.

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

Send a broadcast test email

Tool call template

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources