MCP tools for publication, backups, and undo
Publish draft configuration, inspect change history, restore saved states, and undo changes through MCP.
Publication changes the configuration served to your live website. Restoring and undoing replace the draft, not the live configuration. Confirm the project and intended change before calling a mutating operation.
MCP publication access and version IDs
Every operation accepts an optional string project_id and follows the shared MCP authorization and project-selection rules. Missing project selection, invalid IDs, inaccessible projects, and unavailable MCP access return errors.
A connection that uses an API token is held to the token's abilities. publish-config needs publish. The reads (get-publish-history, list-config-versions, get-config-version-changes) need read or write. describe-config-version, the restores, and undo-last-change save to the project, so they need write: restoring a published configuration copies it into the draft rather than publishing it. Your assistant isn't offered a tool its token can't use. OAuth connections aren't limited this way.
There are three different configuration identifiers:
version_ididentifies a backup snapshot returned bylist-config-versions.version_numberis that snapshot's display sequence, not an input ID.published_config_ididentifies a published configuration returned in publication history or thepublisheslist.
Snapshots preserve configuration, not every account record. They do not undo integration connections, external provider writes, exports, stored personalized emails, or deleted split-test records.
Restores and undo must also respect running question-test locks. A replacement that changes a locked question's wording, options, display, behavior, segment values, or non-sync Auto-Segment rules is rejected. End the test and choose its winner before restoring conflicting configuration.
Examples are illustrative and were not executed. Requests show tools/call parameters. Responses show decoded JSON or plain text, not the MCP envelope.
publish-config
Compiles and publishes the project's existing draft, together with any hosted page and site-style changes. This is the explicit live-site boundary.
| Argument | Type | Required | Default and behavior |
|---|---|---|---|
project_id | string | No | Active or eligible project. |
message | string | No | Publication note. |
auto_generate_message | boolean | No | false; can derive a note from recent MCP snapshot actions when a note is needed. |
tabId | string | No | Optional dashboard tab identifier used by publication notifications. |
include_page_ids | array of strings | No | Hosted pages (pg_… IDs from list-pages) taken offline with unpublish-page to publish again with this publish. |
Automatic notes use up to 50 recent action records; this option does not ask an AI model to inspect the full configuration.
The response is text, not {published_at: ...}. The operation saves a snapshot, queues the draft, then compiles and publishes it. It can publish all pending draft changes, not only changes made by the calling assistant. Review the complete draft first.
The published configuration leaves out features the project's plan doesn't include: campaigns and conversion goals without Scale or Pro, and running campaign A/B tests without Pro. A no-card trial includes every Pro feature, so nothing is left out while it runs. When something is left out, RightMessage keeps the complete, unstripped configuration as the project's draft after publishing, so nothing is lost and the left-out features still show as unpublished changes. The success text is the same whether or not anything was left out. After an upgrade, call publish-config again to make them live.
A project with no plan yet can't publish: the call returns This project needs a plan before it can publish. Choose one in the dashboard., or, for an agency demo project, This is an agency demo project. Choose a plan for it in the dashboard before publishing. No draft and no pending hosted page changes returns No draft changes to publish. Validation or compilation failures return errors. Concurrent experiment activation can return experiment_activation_busy: .... Don't assume every failure means nothing changed. Inspect publication history and its live marker before retrying an uncertain result.
Publishing is what starts or restarts an A/B test for visitors. If the draft starts or restarts a campaign A/B test and the project isn't on Pro, nothing is published and the call returns Starting an A/B test needs the Pro plan. Remove the test or upgrade to Pro. Publishing an ended test, a deployed winner, or an undeploy needs no particular plan. A test that was already running isn't refused, but without Pro, publishing takes it off the live site and keeps it in the draft.
Hosted pages
Every project publishes its page and site-style changes with the same call. The success text then adds what happened to them: Hosted pages published., with a sentence for each page that kept its previous version and why, and a warning for each page whose removed elements still have campaign changes. When something holds the pages back, it adds Hosted pages were not published: … with the reason, and says the page drafts are kept. A page taken offline with unpublish-page stays out of every publish until include_page_ids names it. include_page_ids is checked before anything is published: an unknown ID names it. See MCP tools for pages.
get-publish-history
Lists recent publication records and identifies the currently live configuration.
Arguments: optional project_id string; optional limit number, default 10, converted to an integer and clamped to 1–25.
The envelope contains total_publishes, nullable last_published_at, and history. Each item contains config_id, published_at, message, status, and is_live. Queued-for-publication records can appear alongside published records. Use is_live, not list position or a timestamp alone, to identify the active configuration. This read does not publish or cancel pending work.
list-config-versions
Lists recoverable configuration snapshots and, on the first page, recent published configurations.
| Argument | Type | Required | Default and limits |
|---|---|---|---|
project_id | string | No | Active or eligible project. |
limit | integer | No | 20; nonpositive values reset to 20; maximum 50. |
offset | integer | No | 0; negative values become 0. |
Illustrative response with an empty history:
Each versions item contains id, version_number, source, source_detail, description, ai_description, checksum, created_by ({name,email} or null), and created_at. Retention metadata reports the snapshot policy: keep-count 50 and daily history 30 days.
Only offset: 0 adds publishes, up to 50 entries with id, publish_message, published_at, and is_live. This is metadata, not a full JSON backup payload. The operation does not create a new snapshot.
get-config-version-changes
Explains the change associated with a pre-change snapshot by comparing it to the next saved state, or current configuration if no newer snapshot exists.
Arguments: optional project_id string; required version_id integer; optional limit integer, default 100, maximum 200, nonpositive values reset to 100; optional offset integer, default 0, clamped to at least 0.
compared_to is {type:"version",version_id}, {type:"current"}, or null. Changes contain path and type. Added/removed entries have value; changed entries have before and after.
This is a summarized diff. Strings have markup stripped and are truncated to 160 characters. Arrays are limited to five items, and objects retain selected identifying fields. Do not use these values as a restoration payload. There is no argument for choosing an arbitrary second version. Unknown or cross-project versions and unavailable stored payloads return errors. The read does not alter either state.
describe-config-version
Returns a short AI-generated explanation of a snapshot's associated change.
Arguments: optional project_id string and required version_id integer.
The model receives up to 60 summarized changes. A saved description is reused. Descriptions are stored only when a newer snapshot makes the comparison final; a description of the latest still-changing draft can return stored: false. No differences or an AI-service failure can return description: null, stored: false.
This may call an AI service and persist description metadata. It does not restore, edit, or publish configuration. A nonexistent or inaccessible version returns an error.
restore-config-version
Replaces the entire draft with a saved snapshot, including when that snapshot predates a publication.
Arguments: optional project_id string and required version_id integer.
Illustrative text response:
Get explicit approval for the target timestamp and summary first. Restoring can overwrite unrelated unsaved work. RightMessage saves a snapshot of the current draft before replacing it and notifies connected editors. This is not a selective restore of one phrase, flow, or campaign.
Unknown or cross-project IDs, missing configuration, unavailable archived payloads, and validation/storage failures return errors. No live change occurs until a separate successful publish-config call.
restore-published-config
Copies a prior publication's full configuration into the draft.
Arguments: optional project_id string and required published_config_id integer.
Illustrative response excerpt:
The full text identifies the restored publication and its timestamp. Only a project-owned published or queued-for-publication configuration can be selected. The current live configuration is rejected as a restoration target.
This destructively replaces the draft after saving a pre-restore snapshot. It does not switch the live-site pointer directly. Confirm the exact publication and review the resulting draft before publishing. Missing IDs, invalid status, unavailable payloads, and storage failures return errors.
undo-last-change
Restores the most recent eligible non-undo snapshot associated with the current configuration.
Arguments: optional project_id string only. There is no count, resource ID, or cross-publication target argument.
Illustrative response excerpt:
The response identifies the restored version, source, description, and age where available. RightMessage saves a snapshot of the current state before replacing the draft. Undo does not necessarily reverse your last tool call. Other dashboard or assistant edits may be newer. It also does not restore a state across publications. Use a selected version_id when the target state matters.
No prior eligible snapshot returns an operation error. Undo remains a draft action and does not reverse publication, provider writes, account-record deletion, or other non-configuration side effects.