Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Restore Entity

restore_entity

Un-soft-delete a single entity to reverse a prior removal, restoring its original ID and linked controls in a new model version.

Instructions

Un-soft-delete a single entity of any core type, reversing a prior remove_entity. Mutating: creates a new model version. Only affects an entity that is currently soft-deleted.

Dispatches on entity_type. Per-type effect:

asset — revives the asset's tombstoned (asset × attacker) COs with their original IDs, un-orphaning any linked controls.
attacker — reinstates the attacker under its original ID, revives the COs tombstoned when it was removed, and un-orphans any controls that were anchored to it.
component — reinstates the component under its original ID, restoring its trust-boundary contribution to asset reachability.
trust_boundary — reinstates the boundary: the reachability it filtered re-narrows and its sealed/isolation claim is restored, so CO reachability verdicts past it can flip back toward unreachable.
assumption — returns the assumption to active status; controls whose assumption_groups referenced it keep their group structure intact. Its CO links are not restored (set them again with edit_assumption), and re-attestation is required before it counts anywhere it is linked or grouped.

Returns the entity-change result: {"model": {id, version, title}, "entities", "controls_carried", "controls_orphaned", "orphaned_control_ids", ...}, entities holding the entity as restored.

Input Schema

Name	Required	Description
`model_id`	Yes	ID of the threat model.
`entity_id`	Yes	ID of the entity to restore.
`entity_type`	Yes	Which entity to restore — one of ``asset``, ``attacker``, ``component``, ``trust_boundary``, ``assumption``.
`server_version`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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 provided, the description carries the full behavioral burden and does so well. It discloses that the tool is mutating, creates a new model version, only affects soft-deleted entities, and that behavior dispatches by entity type with specific per-type effects and restoration 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 front-loaded with the core action and then uses a structured per-type list that is justified by the dispatch complexity. It is somewhat long, and the return-shape sentence is less necessary because an output schema exists, but the content is organized and mostly earns its place.

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 mutating, type-dispatched restore operation with no annotations, the description provides the necessary behavioral context: soft-delete precondition, mutation/versioning impact, per-type effects, and return shape. An output schema exists, but the added return summary is still consistent and not required to be omitted.

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 75%, and the description adds substantial meaning for ``entity_type`` by enumerating per-type restoration effects. ``model_id`` and ``entity_id`` are documented in schema, while ``server_version`` is undocumented in both schema and description, keeping this below 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 and resource: un-soft-delete a single entity, reversing a prior ``remove_entity``. It also explicitly limits scope to currently soft-deleted entities, which cleanly distinguishes it from related entity tools such as ``remove_entity`` and the ``edit_*`` siblings.

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 clearly identifies the prerequisite condition: the entity must currently be soft-deleted. It also names the reversing operation, ``remove_entity``. However, it does not explicitly contrast usage with sibling edit or add tools beyond that condition.

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

Deploy Server