Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Undo Composition Event

undo_composition_event

Preview or apply an undo for a model lift or split event, checking divergence first and requiring confirmation before mutating composition state.

Instructions

Preview, and on confirmation apply, the undo of a lift or split.

event_type is lift or split; event_id is the forward lift_applied / split_applied activity event's id, or the lift_id / split_id in its payload. model_id is the model the event was raised on (another model's event is 404).

By default (dry_run=True) it is read-only: {plan, refusal}, exactly one non-null. plan lists the inverse operations an undo would commit (lift: tombstone the LCA entity, restore the source copies, rewrite CO references; split: restore at the ancestor, tombstone the target copies). refusal lists why it cannot: state has moved since the event (assertions submitted on the entity, objectives referencing it, an edit). Show it to the operator.

With dry_run=False it is mutating, after explicit confirmation: the divergence check runs again (409 with detail.refusal.reasons when it refuses), the inverse is persisted across every affected model, and a lift_undone / split_undone event citing original_event_id is recorded. Returns {undone_event_id, original_event_id, applied_state_ops, models}; models is {lca_model, source_descendant_models} for a lift and {ancestor_model, descendant_models} for a split, each model its id, version and title.

503 where composition is not available.

Input Schema

Name	Required	Description	Default
`dry_run`	No
`event_id`	Yes
`model_id`	Yes
`event_type`	Yes
`server_version`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.84.0Oct 4, 2026

addedInput schema / properties / dry_run

Added value: +{
+  "default": true,
+  "type": "boolean"
+}

removedInput schema / properties / event_id / description

Removed value: -"Either the surrogate id of the forward\n``lift_applied`` / ``split_applied`` activity event, or the\nstructured ``lift_id`` / ``split_id`` carried in the event\npayload."

removedInput schema / properties / event_type / description

Removed value: -"Which forward composition event to undo. One of:\n  - ``\"lift\"``: undo a ``lift_applied`` event. On success,\n    persists the inverse across the LCA + every affected\n    source descendant and emits a ``lift_undone`` event. The\n    returned ``models`` block carries ``lca_model`` and\n    ``source_descendant_models``.\n  - ``\"split\"``: undo a ``split_applied`` event. On success,\n    restores the ancestor's entity, tombstones the duplicated\n    copies on every target descendant, persists across all\n    affected models, and emits a ``split_undone`` event. The\n    returned ``models`` block carries ``ancestor_model`` and\n    ``descendant_models``."

removedInput schema / properties / model_id / description

Removed value: -"The model whose composition view originated the event.\nMust match the cited event's ``threat_model_id`` — the server\nrejects cross-model citations with 404."

Addedv0.68.2Aug 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: dry_run is read-only by default, dry_run=false is mutating after confirmation, divergence is rechecked with a 409, and a 503 occurs when composition is unavailable. It also discloses the exact return shapes and refusal semantics.

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 dense but front-loaded: purpose, parameter semantics, preview behavior, and mutation behavior are presented in a logical order. It is longer than ideal, but the complexity of a preview/apply undo operation justifies most of the detail.

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?

An output schema exists, yet the description still explains return values, error cases, model coverage, and event recording. For a complex mutation tool with no annotations, this is complete enough for an agent to invoke it correctly.

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 0%, so the description must explain parameters; it meaningfully defines event_type, event_id, model_id, and the dry_run mode. The only gap is server_version, which is required but not described, keeping this from a 5.

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 states a specific verb+resource: preview/apply undo of a lift or split composition event. It clearly distinguishes the two event types and the forward event identifiers, so an agent can identify the operation without opening the schema.

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?

It explicitly describes the default dry-run preview path, the explicit confirmation required for mutation, and when refusals should be shown to the operator. It does not name sibling alternatives such as undo_model_change, but the when/when-not guidance for this tool is strong.

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

Deploy Server