Mondovo

Change a journey step

update_journey_step

DestructiveIdempotent

Change ONE step of a journey by its step id (from get_journey). Pass only what changes. Email and SMS message steps, waits, condition/A-B splits, contact updates, webhooks, goals and stops are supported, including advanced JSON values. Sending SMS requires a connected verified sender, billing and consent when sending. The whole journey is validated before saving; a change that would break it is refused with the reason. On a live journey the change applies to people who enter from now on.

Input Schema

Name	Required	Description
`body`	No	Plain message body. Required for SMS; use body_html for email HTML.
`tags`	No	Contact update: full replacement tag list
`label`	No	Optional step label
`stage`	No	Contact update: pipeline stage
`channel`	No	Message step: email or SMS. Sending SMS requires a connected, verified sender, billing, and consent when sending.
`site_id`	Yes	The site, from list_sites
`step_id`	Yes	A step id exactly as get_journey shows it, e.g. n_email_1
`subject`	No	Email step: subject line
`template`	No	Message step: optional template name
`body_html`	No	Email step: body HTML; one unsubscribe link is added at send time
`condition`	No	Advanced JSONLogic condition, exclusive with condition_field/operator/value; primitive booleans are valid
`goal_name`	No	Goal step: goal name
`user_goal`	No	Optional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
`ab_weights`	No	A/B step: complete replacement variant map. Removed keys discard their path steps; new keys add empty paths. Weights may be relative.
`journey_id`	Yes	The journey, by id from list_journeys
`lead_score`	No	Contact update: score; null clears it
`contact_set`	No	Contact update: complete advanced attribute map, exclusive with tags/stage/lead_score
`exit_reason`	No	Exit step: reason
`webhook_url`	No	Webhook step: destination URL
`custom_event`	No	Trigger step: configuration for trigger_event=custom. Use business-defined event fields and optional intent_options; there is no universal intent taxonomy.
`wait_minutes`	No	Wait step: minutes (1440 = a day); new waits default to one minute
`trigger_event`	No	Trigger step: event name
`trigger_filter`	No	Trigger step: advanced JSONLogic filter; null clears it and may use contact.id and ctx
`webhook_method`	No	Webhook step: HTTP method
`condition_field`	No	Simple condition split: field; use condition for advanced JSONLogic instead
`condition_value`	No	Simple condition split: comparison value
`webhook_payload`	No	Webhook step: JSON payload; null clears it
`condition_operator`	No	Simple condition split: operator
`webhook_fail_on_error`	No	Webhook step: stop the journey if the request fails
`translate_to_contact_language`	No	Email step: send each contact the email translated into their language; contacts without one get the original

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / user_goal

Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / custom_event

Added value: +{
+  "additionalProperties": false,
+  "description": "Trigger step: configuration for trigger_event=custom. Use business-defined event fields and optional intent_options; there is no universal intent taxonomy.",
+  "properties": {
+    "fields": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "example": {
+            "type": [
+              "string",
+              "number",
+              "boolean"
+            ]
+          },
+          "key": {
+            "maxLength": 64,
+            "minLength": 1,
+            "type": "string"
+          },
+          "label": {
+            "maxLength": 500,
+            "minLength": 1,
+            "type": "string"
+          },
+          "required": {
+            "type": "boolean"
+          },
+          "type": {
+            "enum": [
+              "text",
+              "number",
+              "boolean",
+              "url"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "key",
+          "label",
+          "type",
+          "required"
+        ],
+        "type": "object"
+      },
+      "maxItems": 32,
+      "type": "array"
+    },
+    "intent_options": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "description": {
+            "maxLength": 500,
+            "minLength": 1,
+            "type": "string"
+          },
+          "id": {
+            "maxLength": 64,
+            "minLength": 1,
+            "type": "string"
+          },
+          "label": {
+            "maxLength": 500,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "label",
+          "description"
+        ],
+        "type": "object"
+      },
+      "maxItems": 32,
+      "type": "array"
+    },
+    "name": {
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "stop_events": {
+      "items": {
+        "maxLength": 128,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 16,
+      "type": "array"
+    }
+  },
+  "required": [
+    "name",
+    "stop_events",
+    "fields"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 27, 2026

addedInput schema / properties / body

Added value: +{
+  "description": "Plain message body. Required for SMS; use body_html for email HTML.",
+  "maxLength": 200000,
+  "type": "string"
+}

changedInput schema / properties / channel / description

Previous value: -"Message step: email is currently available"New value: +"Message step: email or SMS. Sending SMS requires a connected, verified sender, billing, and consent when sending."

changedInput schema / properties / channel / enum

Previous value: -[
-  "email"
-]New value: +[
+  "email",
+  "sms"
+]

First observedOct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=true and not-read-only, so the safety profile is known; the description adds genuinely new behavior: the whole journey is validated before saving and a breaking change is refused with a reason, and on a live journey the edit applies only to future entrants, not people already in flight. Those two facts are exactly the ones an agent cannot get from the schema. It stops short of saying what gets destroyed when a value is replaced (e.g. ab_weights path steps, tag list replacement), which the schema covers but the prose could reinforce.

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?

Six sentences, front-loaded with the identity and partial-update rule, and every sentence carries operational information. The SMS requirement sentence duplicates the channel property description verbatim in substance, so it is mild redundancy rather than waste.

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 30-parameter mutation with nested custom_event and no output schema, the description covers the mutation semantics, validation gate and live-journey effect, which are the highest-risk unknowns. It would be complete at 5 if it flagged the destructive replacement behaviors (tag list full replacement, A/B variant map replacement) in prose rather than relying on the agent to read every property description.

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 baseline is 3, but the description adds cross-parameter meaning the schema cannot: that only changed fields should be sent, the enumeration of step kinds (message, wait, condition/A-B split, contact update, webhook, goal, stop, trigger) that maps parameter clusters to step types, and that advanced JSON values are accepted. It does not resolve the exclusivity between tags/stage/lead_score and contact_set, which is left entirely 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?

"Change ONE step of a journey by its step id" gives a specific verb, resource and scope, and the emphasis on ONE step immediately separates it from add_journey_step, remove_journey_step and move_journey_step in the sibling list. It also names the read tool that supplies the identifier (get_journey).

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?

"Pass only what changes" establishes partial-update semantics and the step-id source is stated, plus the supported step kinds tell the agent which cases this tool handles. It never explicitly names the alternatives it should be chosen over (add_journey_step, move_journey_step, remove_journey_step), so routing is inferred rather than stated.

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

All Mondovo 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?