Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Remove Entity

remove_entity

Soft-deletes one threat-model entity of any core type, creates a new model version, and preserves the entity ID so it can be restored with the same 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.

Runs as a background job, reporting progress while it waits; a job a client stops waiting for finishes or fails on its own. A removal that is refused (the entity is not found or already deleted, or it is the last live asset or attacker) fails with the reason.

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.

Returns {model, entities, controls_carried, controls_orphaned, orphaned_control_ids}: the model's id, version and title, and the entity as removed.

Input Schema

NameRequiredDescriptionDefault
model_idYesID of the threat model.
entity_idYesID of the entity to soft-delete.
entity_typeYesWhich entity to soft-delete — one of ``asset``, ``attacker``, ``component``, ``trust_boundary``, ``assumption``.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.68.2

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so thoroughly: mutating, creates a new model version, runs as a background job that completes even if the client stops waiting, and fails with a reason when the entity is not found, already deleted, or is the last live asset/attacker. Per-type consequences and the preserved-never-reused ID are disclosed in detail.

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, reversibility and sibling routing before the long per-type consequence block, which is bulleted and scannable. It is long for a delete tool, but nearly every sentence carries information an agent needs to predict side effects.

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?

The description is complete enough to call this mutation safely: side effects per type, job semantics, failure modes, reversibility and the returned fields are all covered. Even though an output schema exists, the return summary ({model, entities, controls_carried, controls_orphaned, orphaned_control_ids}) adds useful orientation about cascade impact.

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 compensates well for the main gap by enumerating what each entity_type value actually does downstream (CO tombstoning, orphaning, reachability widening, audit retention). It also clarifies that entity_id is preserved and never reused. model_id and server_version get no semantic elaboration.

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 ('soft-delete a single entity of any core type') and immediately distinguishes itself from two siblings: restore_entity for reversal and the typed edit_* tools for field changes. An agent can tell exactly what this does 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?

Explicitly names the alternatives for two adjacent intents ('Reversible with restore_entity using the same entity_type', 'To change an entity's fields instead of removing it, use the typed edit_* tool'). It gives clear context and acceptance/failure conditions, though it doesn't state outright when not to remove an entity at all.

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

Deploy Server

Other Tools