Model Changes (Pro)

manage_model_changes gives you a safety net for authoring:

• change history (“what happened?”),
• diffs (“what changed?”),
• undo/redo,
• checkpoints (named restore points),
• rollbacks to prior states,
• changesets (stage a batch, preview, then apply).

Use it when you’re doing multi-step edits and want safe rollback and reviewable change summaries.

You won’t call the tool directly-tell the LLM what you want (checkpoint, preview, rollback) and it will use manage_model_changes behind the scenes.

What to ask the LLM (quick prompts)

What this gives you in practice

Think of it like version control for your semantic model:

• Undo/redo - you renamed a measure and broke downstream reports. Undo reverts the rename instantly, no manual cleanup needed.
• Checkpoints - you are about to refactor 15 measures into a calc group. Create a checkpoint called "before-refactor". If anything goes wrong, roll back to that checkpoint and the model returns to exactly how it was.
• Changesets - you want to stage a batch of related edits (rename 5 measures, update 3 display folders, add descriptions) and review the whole batch as a diff before applying. A changeset lets you preview everything, then apply it as one unit after confirmation.
• History and diffs - something changed overnight and totals look wrong. Pull up the last 10 transactions and see exactly what was modified, when, and by which tool call.

Prompt:

Locked-down environments (mode behavior)

Recommended workflow (safe refactors)

Copy/paste prompt:

Common recipes (copy/paste prompts)

Review what changed

Diff detail levels

Undo/redo safely

Checkpoints

Changesets (batch edits with preview)

Changesets are scoped to the model that created them. A changeset ID from another currently connected model is rejected for add, preview, apply, and delete. Connection-management operations cannot be queued or replayed inside changesets.

Changesets: stage, review, then apply

Use a changeset when you want the assistant to prepare a related batch of model edits, show you what it is about to do, and apply the batch only after you confirm. This is useful for refactors where the edits are connected and should be reviewed together, such as:

• renaming a set of measures,
• moving measures into display folders,
• adding descriptions or format strings across a table,
• updating related semantic metadata in one planned pass.

Do not use a changeset as a general script runner. Changesets are for model-editing tool calls. They cannot include connection-management operations, and they should not be used to change which model is active.

Changeset lifecycle

1. 1

   Create

   Start a named changeset so the planned operations have a shared review boundary.

   “Create a changeset named Sales measure cleanup.”
2. 2

   Queue edits

   Ask the assistant to add the planned model edits to the changeset instead of applying them immediately.

   “Add these measure rename and display-folder edits to the changeset, but do not apply it yet.”
3. 3

   Preview

   Review the queued operation list before anything is applied.

   “Preview the changeset and summarize the operations in plain language.”
4. 4

   Apply

   Apply only after the preview matches your intent.

   “Apply the changeset now, then summarize the transaction and validation steps.”
5. 5

   Validate

   Run queries/tests after apply. A preview is not a substitute for validation.

   “Run the validation queries and show before/after results for the affected measures.”

Recommended changeset workflow

For important work, pair a changeset with a checkpoint:

1. Create a checkpoint before the refactor.
2. Create a changeset for the planned edits.
3. Queue all related edits into the changeset.
4. Preview and review the changeset.
5. Apply after confirmation.
6. Validate with queries and tests.
7. Restore the checkpoint if validation fails and you need to return to the prior state.

Copy/paste prompt:

What a preview tells you

A changeset preview shows the queued operations and a readable summary of what will be replayed. Use it to catch wrong objects, missing edits, or edits that should be split into a smaller batch.

Preview does not prove the final model is correct. After applying, validate the actual model state with list_model, run_query, and test packs when available.

Safety rules

• Changesets are tied to the model that created them.
• Direct changeset_id operations are rejected if you switch to another model.
• Connection-management operations cannot be queued or replayed from a changeset.
• Applied changesets are immutable history entries and cannot be deleted.
• Draft and failed changesets can be deleted.
• Changeset history is local to the MCP server instance.

Confirmations (client support)

Some operations are intentionally destructive (rollback/restore/delete). In clients that support confirmations/elicitation, you’ll see a confirmation dialog.

In clients that don’t support confirmations, the assistant should:

• ask you explicitly (“Type ‘yes’ to proceed”), and
• proceed only after you confirm.

If the assistant reports “confirmation required”, reply with a clear approval:

Limitations and gotchas

• This history is local to the MCP server. It won’t follow you to a different machine/server instance.
• It captures changes made through MCP tooling. It won’t capture model edits performed directly in Desktop UI outside the session.
• Always confirm you’re connected to the correct model before applying or rolling back.

Risk & governance notes (read this once)

Troubleshooting

See also

• Change safely
• Dependencies / impact analysis (Pro)
• Unit testing (Pro)
• Tools index