Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Refine Threat Model

refine_threat_model

Update an existing threat model by applying an instruction, revising assets, attackers, trust boundaries, and controls while preserving semantic integrity and creating a new version.

Instructions

Refine an existing threat model based on an instruction.

Updates the model's assets, attackers, trust boundaries, and control objectives based on the instruction. Creates a new version. Progress is reported automatically.

Refine CANNOT silently replace an entity's identity under a stable ID or silently drop an entity. Behavior:

  • Preserved entities where the LLM proposed an identity- bearing rewrite (name / description / security_properties on assets; capability / archetype / position on attackers) run through a semantic-preservation guard. Rewrites classified as replace or ambiguous (or unavailable if the gate LLM is down) have their identity fields REVERTED to the pre-refine values. Each rejection shows up as an entry in the semantic_rejections array in this tool's return value — surface these to the operator.

  • Entities the LLM drops from the refined output are re- appended to the model unchanged. The only sanctioned removal path is remove_entity (entity_type="asset") / remove_entity (entity_type="attacker") (soft-delete).

  • CO IDs are stable across refinements; pairs (asset, attacker) that disappear come back as tombstones with removed=True (not renumbered). Controls that only mapped to tombstoned COs become orphaned at read time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model to refine.
instructionYesWhat to change, e.g. "Add CSRF attack vectors".
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.66.0
  2. Removedv0.62.2
  3. First observedv0.57.0

TDQS

A4.3/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. It discloses preservation guarantees, the semantic-preservation guard, reverting identity fields, semantic_rejections, re-appending dropped entities, stable CO IDs, tombstones, orphaned controls, and the sanctioned removal path through remove_entity.

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 a concise summary and then structured into clear behavior bullets. The length is justified by the non-obvious preservation, revert, tombstone, and orphan semantics it must communicate; each sentence adds needed detail.

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 covers purpose, side effects, edge cases, and the key return artifact (semantic_rejections), and an output schema is present to define return values. It provides enough behavioral context for an agent to invoke the tool correctly, especially given the complex preservation guarantees.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents model_id and instruction, and the description adds some meaning by explaining what the instruction changes. However, server_version is a required parameter with no schema description and no mention in the tool description, so the parameter semantic coverage remains incomplete.

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 ('Refine'), a specific resource ('an existing threat model'), and the exact elements updated (assets, attackers, trust boundaries, control objectives), plus the fact that it creates a new version. This clearly distinguishes it from generation or query siblings like generate_threat_model or get_threat_model.

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

Usage Guidelines3/5

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

The opening sentence implies the use case: refine an existing threat model based on an instruction. However, it does not explicitly say when to use this tool over siblings like generate_threat_model or edit_asset, and it does not provide exclusion conditions or 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

Other Tools