Mailrith Email Marketing

Update a sequence

sequences_update

DestructiveIdempotent

Updates an existing paused Sequence. Before changing a running Sequence, read it by ID, retain its status in the current task only, pause it, apply the update, and use bounded direct item reads until is_updating is false. Run preflight, return it to running only if it was running before and preflight passes, and verify the final status. If the update fails before changing the Sequence, restore its prior running status when preflight passes. If readiness or the prior status cannot be restored, leave it paused and immediately report the failure; never activate a Sequence that was not already running. Effect: workspace-change. Retry after reading the current resource state. Permission: sequences:write. API reference: https://mailrith.com/developers/api-reference.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes	The exact JSON request body defined by the Mailrith public API contract.
`sequence_id`	Yes	The sequence identifier.

Output Schema

TableJSON 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. Dates show when Glama detected each change.

Changed10 schema fields changedSep 3, 2026

changedInput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedInput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello from Mailrith.",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedInput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello from Mailrith.",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

addedInput schema / $defs / SequenceEmail / properties / subject / description

Added value: +"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedOutput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedOutput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello from Mailrith.",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedOutput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello from Mailrith.",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

addedOutput schema / $defs / BroadcastSendProgress / properties / sent
```
Added value: +{
+  "type": "integer"
+}
```

changedOutput schema / $defs / BroadcastSendProgress / required

Previous value: -[
-  "run_id",
-  "phase",
-  "selected",
-  "materialized",
-  "accepted",
-  "skipped",
-  "retrying",
-  "permanent_failed",
-  "unknown",
-  "canceled",
-  "percent_complete",
-  "effective_rate",
-  "provider_limited_rate",
-  "provider",
-  "estimated_completion",
-  "estimated_completion_basis",
-  "last_progress_at",
-  "pause_reason",
-  "next_retry_at",
-  "next_retry_action",
-  "pause_message",
-  "terminal"
-]New value: +[
+  "run_id",
+  "phase",
+  "selected",
+  "materialized",
+  "sent",
+  "accepted",
+  "skipped",
+  "retrying",
+  "permanent_failed",
+  "unknown",
+  "canceled",
+  "percent_complete",
+  "effective_rate",
+  "provider_limited_rate",
+  "provider",
+  "estimated_completion",
+  "estimated_completion_basis",
+  "last_progress_at",
+  "pause_reason",
+  "next_retry_at",
+  "next_retry_action",
+  "pause_message",
+  "terminal"
+]

addedOutput schema / $defs / SequenceEmail / properties / subject / description

Added value: +"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

Changed10 schema fields changedSep 3, 2026

changedInput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes."

changedInput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello from Mailrith.",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedInput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello from Mailrith.",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

removedInput schema / $defs / SequenceEmail / properties / subject / description

Removed value: -"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedOutput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes."

changedOutput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello from Mailrith.",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedOutput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello from Mailrith.",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

removedOutput schema / $defs / BroadcastSendProgress / properties / sent
```
Removed value: -{
-  "type": "integer"
-}
```

changedOutput schema / $defs / BroadcastSendProgress / required

Previous value: -[
-  "run_id",
-  "phase",
-  "selected",
-  "materialized",
-  "sent",
-  "accepted",
-  "skipped",
-  "retrying",
-  "permanent_failed",
-  "unknown",
-  "canceled",
-  "percent_complete",
-  "effective_rate",
-  "provider_limited_rate",
-  "provider",
-  "estimated_completion",
-  "estimated_completion_basis",
-  "last_progress_at",
-  "pause_reason",
-  "next_retry_at",
-  "next_retry_action",
-  "pause_message",
-  "terminal"
-]New value: +[
+  "run_id",
+  "phase",
+  "selected",
+  "materialized",
+  "accepted",
+  "skipped",
+  "retrying",
+  "permanent_failed",
+  "unknown",
+  "canceled",
+  "percent_complete",
+  "effective_rate",
+  "provider_limited_rate",
+  "provider",
+  "estimated_completion",
+  "estimated_completion_basis",
+  "last_progress_at",
+  "pause_reason",
+  "next_retry_at",
+  "next_retry_action",
+  "pause_message",
+  "terminal"
+]

removedOutput schema / $defs / SequenceEmail / properties / subject / description

Removed value: -"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

Changed8 schema fields changedAug 17, 2026

changedInput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedInput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello from Mailrith.",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedInput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello from Mailrith.",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

addedInput schema / $defs / SequenceEmail / properties / subject / description

Added value: +"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedOutput schema / $defs / BroadcastEmailDocument / description

Previous value: -"A structured email document. The root node must use type `doc` and contain supported block nodes."New value: +"A structured email document. The root node must use type `doc` and contain supported block nodes. For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

changedOutput schema / $defs / BroadcastEmailDocument / example / content

Previous value: -[
-  {
-    "content": [
-      {
-        "text": "Hello from Mailrith.",
-        "type": "text"
-      }
-    ],
-    "type": "paragraph"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+        "type": "text"
+      }
+    ],
+    "type": "paragraph"
+  }
+]

changedOutput schema / $defs / BroadcastEmailDocument / examples

Previous value: -[
-  {
-    "content": [
-      {
-        "content": [
-          {
-            "text": "Hello from Mailrith.",
-            "type": "text"
-          }
-        ],
-        "type": "paragraph"
-      }
-    ],
-    "type": "doc"
-  }
-]New value: +[
+  {
+    "content": [
+      {
+        "content": [
+          {
+            "text": "Hello [Subscriber_Name, fallback=\"friend\"].",
+            "type": "text"
+          }
+        ],
+        "type": "paragraph"
+      }
+    ],
+    "type": "doc"
+  }
+]

addedOutput schema / $defs / SequenceEmail / properties / subject / description

Added value: +"For Subscriber personalization in email subjects and body text nodes, use Mailrith bracket tokens such as [Subscriber_Name, fallback=\"friend\"] or [Subscriber_Email, fallback=\"\"]. Before using a custom field, call custom_fields_list or custom_fields_get and copy its personalization_token exactly. Do not use Handlebars-style variables such as {{ subscriber.name }}; Mailrith sends them as literal text."

Changed2 schema fields changedAug 7, 2026

addedOutput schema / $defs / BroadcastSendProgress / properties / sent
```
Added value: +{
+  "type": "integer"
+}
```

changedOutput schema / $defs / BroadcastSendProgress / required

Previous value: -[
-  "run_id",
-  "phase",
-  "selected",
-  "materialized",
-  "accepted",
-  "skipped",
-  "retrying",
-  "permanent_failed",
-  "unknown",
-  "canceled",
-  "percent_complete",
-  "effective_rate",
-  "provider_limited_rate",
-  "provider",
-  "estimated_completion",
-  "estimated_completion_basis",
-  "last_progress_at",
-  "pause_reason",
-  "next_retry_at",
-  "next_retry_action",
-  "pause_message",
-  "terminal"
-]New value: +[
+  "run_id",
+  "phase",
+  "selected",
+  "materialized",
+  "sent",
+  "accepted",
+  "skipped",
+  "retrying",
+  "permanent_failed",
+  "unknown",
+  "canceled",
+  "percent_complete",
+  "effective_rate",
+  "provider_limited_rate",
+  "provider",
+  "estimated_completion",
+  "estimated_completion_basis",
+  "last_progress_at",
+  "pause_reason",
+  "next_retry_at",
+  "next_retry_action",
+  "pause_message",
+  "terminal"
+]

First observedJul 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations provide readOnlyHint, destructiveHint, and idempotentHint, but the description goes far beyond by disclosing the necessary multi-step behavior: reading by ID, pausing, bounded reads until is_updating is false, running preflight, restoring prior status only under conditions, and the safety failure handling. It also states the effect (workspace-change), permission required, and retry guidance—all extra context beyond the 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 description is lengthy but each sentence carries essential operational information. It is front-loaded with the core purpose, then builds a clear cause-and-effect workflow. No sentences are wasted; even the retry and permission notes are valuable. It is structured to be read sequentially as a safe-update procedure, which suits the complexity.

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 schemas, multiple potential states, and an output schema), the description is exceptionally complete. It covers the full lifecycle of an update, including failures, restoration, and never activating a non-running sequence. It also provides permission and API reference. Since an output schema exists, return values are handled separately, so no major gaps remain.

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?

The schema already provides descriptions for both parameters (sequence_id and body), giving 100% coverage. The description does not add further meaning to these parameters; it focuses on the procedural workflow rather than the argument semantics. The body parameter's complex structure is fully documented by the nested schema definitions, so the description rightfully leaves parameter details to 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?

The description opens with 'Updates an existing paused Sequence,' which clearly states the verb and resource. It proceeds to differentiate the tool by describing its behavior for running sequences, making clear this is a full update tool rather than a status-only toggle. This distinguishes it from siblings like sequences_update_status.

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 explicit when-to-use guidance: it targets existing sequences and provides a detailed protocol for handling running sequences (pause, update, preflight, restore). It tells the agent when not to activate a sequence (never activate a non-running one) and recommends retry only after reading current state. However, it does not explicitly name alternative tools like sequences_update_status or sequences_preflight, though the workflow implies them.

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

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.

Update a sequence

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources