Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Remove Entity

remove_entity

Soft-delete any core entity (asset, attacker, component, trust boundary, or assumption) in a threat model to create a new model version. Reversible via restore, preserving ID and links.

Instructions

Soft-delete a single entity of any core type. Mutating: creates a new model version. Reversible with restore_entity using the same entity_type — the entity's ID is preserved (never reused) so a restore reinstates the same ID and all its links. To change an entity's fields instead of removing it, use the typed edit_* tool.

Dispatches on entity_type. Per-type consequence (all derived at read time; nothing is hard-destroyed):

asset — the asset's (asset × attacker) CO pairs are tombstoned, orphaning any controls mapped to them.
attacker — control objectives anchored to this attacker are tombstoned; controls left with no live anchor become orphaned.
component — controls scoped to this component have their component_id cleared (the controls themselves are kept) and the component's trust-boundary contribution to asset reachability is withdrawn.
trust_boundary — reachability widens: attacker vectors the boundary was filtering now pass freely and its sealed/isolation claim is dropped, so CO reachability verdicts past it can flip toward reachable/indeterminate.
assumption — marked deleted (kept for the audit trail); its CO links are cleared and its attestations retired; controls whose assumption_groups name it keep their groups, which credit nothing through it while it is deleted.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.68.2Aug 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and delivers: it discloses soft-delete rather than hard destroy, that a new model version is created, that IDs are preserved and never reused, and enumerates per-entity-type consequences (tombstoning, orphaning, reachability widening, audit-trail retention) that are far beyond what any structured field provides.

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 operation, reversibility, and alternative tools before the per-type bullet list. The length is justified by genuinely distinct per-type consequences, though the bullets are dense enough that some pruning is possible.

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 multi-type soft-delete mutation with no annotations, the description covers reversibility, dispatch, and the differentiated side effects per type; an output schema exists so return values need not be explained. Nothing an agent needs to call this safely is missing.

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 substantially enriches the key parameter: it explains that ``entity_type`` dispatches behavior and what each of the five values causes, and that ``entity_id`` is preserved across a restore. It adds little on ``model_id`` and ``server_version``, but those are already documented in the schema.

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+resource with scope: 'Soft-delete a single entity of any core type', followed by the mutating semantics and dispatch-on-entity_type. It is clearly distinguishable from sibling tools like edit_*, delete_control, delete_threat_model, and restore_entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between alternatives: use ``restore_entity`` with the same ``entity_type`` to reverse, and use the typed ``edit_*`` tool to change fields rather than remove. The selecting conditions for each alternative are stated, not inferred.

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

Deploy Server