Mondovo

Add a journey step

add_journey_step

Destructive

Insert a step into a journey using an existing anchor from get_journey. position defaults to after; before inserts before it, and path_start inserts at a named split path. After a split, insert into its shared continuation below the paths. Supports email/SMS messages, waits, condition splits, A/B splits, contact updates, webhooks, goals and stops. Sending SMS requires a connected verified sender, billing and consent when sending. Removing A/B variants or adding a terminal step can discard or stop downstream paths, so review the confirmation carefully.

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
`subject`	No	Email step: subject line
`path_key`	No
`position`	No
`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
`step_type`	Yes
`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
`wait_minutes`	No	Wait step: minutes (1440 = a day); new waits default to one minute
`after_step_id`	Yes	A step id exactly as get_journey shows it, e.g. n_email_1
`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"
+}

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.5/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true and idempotentHint=false annotations: it warns that removing A/B variants discards their path steps and that adding a terminal step can stop downstream paths, and that a confirmation must be reviewed. It also discloses channel prerequisites for SMS, which the annotations cannot express.

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 core action and anchor requirement, then positioning rules, then step types, then warnings. Dense but every sentence carries information; the step-type enumeration partially duplicates the enum and is the only marginally wasteful piece.

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 destructive mutation with no output schema, it covers the workflow dependency (get_journey anchor), positioning modes, channel prerequisites and path-loss risk. It does not hint at which parameters are required per step_type, which is the main remaining gap for such a wide conditional schema.

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 90%, so the baseline is 3, but the description adds real meaning the schema lacks — the semantics of the position enum values and the shared-continuation rule after a split. It also enumerates the step types supported, though that largely restates the step_type enum.

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 ("Insert a step into a journey") and scopes the anchor requirement to ids from get_journey. The list of supported step types makes it immediately distinguishable from update_journey_step, move_journey_step and remove_journey_step.

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 insertion semantics (position defaults to after; before inserts before the anchor; path_start targets a named split path) and the post-split rule about inserting into the shared continuation. It also lists preconditions for SMS (verified sender, billing, consent). It never explicitly contrasts with update_journey_step or move_journey_step, so no explicit exclusion guidance.

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?