Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Undo Composition Event

undo_composition_event

Preview and apply the inverse of a lift or split event, refusing when model state has diverged; dry runs show the undo plan or refusal before confirmation.

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.

503 where composition is not available.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON 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: default read-only vs mutating mode, the exact {plan, refusal} return shape with one non-null, the 409 refusal payload path, the 503 unavailability, cross-model persistence, and the recorded undo event. This is unusually complete disclosure for a mutation tool.

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, then structured into default dry_run behavior, confirmed mutation behavior, and error codes. It is dense but every sentence adds actionable detail; a short leading verb phrase for the mutating path would tighten it slightly.

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?

For a complex, multi-model destructive operation with 5 parameters at 0% schema coverage and no annotations, the description covers prerequisites, default safety, refusal conditions, error codes, and side effects. An agent can invoke it correctly on the first attempt.

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 compensate, and it does: event_type (lift/split), event_id (forward lift_applied/split_applied id or the lift_id/split_id in the payload), model_id (404 for another model's event), and dry_run semantics are all explained. Only server_version, a required parameter, goes unexplained.

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 ('undo of a lift or split') and clearly scopes it as a preview-then-apply operation. An agent can distinguish it from siblings like lift_composition_entity, split_composition_entity, and undo_model_change without opening any 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?

Gives strong conditional guidance: dry_run defaults to True (read-only preview), and dry_run=False mutates only 'after explicit confirmation', with the divergence check re-running. It does not, however, name the sibling alternative (e.g., why use this versus undo_model_change), so it stops short of explicit alternative routing.

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

Deploy Server