Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Remove Entity

remove_entity

Soft-delete any threat-model entity by type while preserving its ID for later restore. Dependencies update automatically, and the action remains reversible for audit.

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); linked COs are no longer mitigated by it; controls with assumed_by pointing to it are preserved as inert pointers that reconnect on restore.

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.9/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 burden and succeeds. It discloses that the operation is mutating, creates a new model version, is reversible, preserves IDs, never hard-destroys data, and enumerates per-entity-type consequences, including tombstoning, orphaning, clearing fields, and reachability impacts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior and reversibility, then uses clear bullet points to organize per-type consequences. The length is justified by the complexity of the tool, and there is minimal fluff or redundancy beyond what is needed.

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 mutation tool with no annotations, the description covers essential invocation context: what is affected, reversibility, side effects, and alternatives. Since an output schema exists, return-value details are not necessary, and the description provides enough information for an agent to use the tool 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?

The input schema already describes model_id, entity_id, and entity_type, and the description adds meaningful semantic detail, especially for entity_type, by explaining consequences for each allowed value. The only slight gap is that server_version is required but not elaborated in either the schema description or the tool description.

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 opens with a precise action and scope: 'Soft-delete a single entity of any core type.' It then clearly distinguishes itself from the related restore_entity and typed edit_* tools, so an agent knows exactly what this tool does and how it differs from siblings.

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?

The description explicitly states when to use an alternative: 'To change an entity's fields instead of removing it, use the typed edit_* tool.' It also names restore_entity for reversal and describes per-type behavior, giving clear decision guidance for this tool versus siblings.

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

Deploy Server