Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Generate Threat Model

generate_threat_model

Turn a feature description into a threat model with trust boundaries, assets, attackers, controls, and assumptions, while avoiding duplicates by suggesting similar existing models.

Instructions

Generate a complete threat model from a feature description.

Analyzes the feature using the Security Properties (Confidentiality, Integrity, Availability, Usage) methodology with capability-defined attackers. Produces trust boundaries, asset inventory, attacker inventory, control objective matrix, and assumptions.

Runs a multi-step AI pipeline. Progress is reported automatically.

Similar-model short-circuit: if the backend finds an existing model in the workspace whose feature description substantially overlaps with the new one, it does NOT generate a duplicate. This tool returns {"similar_models": [{"id", "title", "reason"}, ...], "suggestion": "..."} with the candidate IDs instead. The agent should then either:

Call refine_threat_model on one of the candidates to extend the existing model (usually the right answer — avoids duplicate modeling of the same system and preserves control/assertion history).
Retry this tool with force=True to bypass the check and create a genuinely new model anyway (e.g., when the similarity is superficial and the operator confirmed the new model is distinct).

Input Schema

TableJSON Schema

Name	Required	Description
`force`	No	Skip the similar-model detection and always create a new model. Default False — the check fires unless the operator / agent has explicit reason to bypass it.
`parent_id`	No	Optional ID of an existing model to wire the new model under as a child on the recursive composition tree. The child then inherits the parent's topology and participates in composition (delta / inherited control credit). Default None — the model is created flat.
`provenance_ref`	No	Branch or tag name at that commit (optional).
`server_version`	Yes
`provenance_kind`	No	Where the description came from, one of ``code``, ``ticket``, ``document``, ``manual``, ``mixed``. Empty (default) records nothing. For an existing repository pass ``provenance_kind="code"`` with ``provenance_repo_url`` and ``provenance_commit_sha`` (the HEAD you gathered from): the code is then authoritative and the model follows it. Any other kind means the description is intent and the code is measured against it. The same record can be set later with ``set_model_provenance``.
`feature_description`	Yes	Description of the feature or system to threat model. Can be a few sentences or a detailed spec.
`provenance_repo_url`	No	Repository URL the description was gathered from (``code`` kind).
`provenance_commit_sha`	No	Commit SHA the description was gathered at (``code`` kind).
`provenance_source_ref`	No	Identifier of the ticket or document the description came from (``ticket`` / ``document`` kinds).
`provenance_source_url`	No	URL of that ticket or document.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.75.0Sep 6, 2026

addedInput schema / properties / provenance_commit_sha

Added value: +{
+  "default": "",
+  "description": "Commit SHA the description was gathered\nat (``code`` kind).",
+  "type": "string"
+}

addedInput schema / properties / provenance_kind

Added value: +{
+  "default": "",
+  "description": "Where the description came from, one of\n``code``, ``ticket``, ``document``, ``manual``, ``mixed``.\nEmpty (default) records nothing. For an existing repository\npass ``provenance_kind=\"code\"`` with ``provenance_repo_url``\nand ``provenance_commit_sha`` (the HEAD you gathered from):\nthe code is then authoritative and the model follows it.\nAny other kind means the description is intent and the code\nis measured against it. The same record can be set later\nwith ``set_model_provenance``.",
+  "type": "string"
+}

addedInput schema / properties / provenance_ref

Added value: +{
+  "default": "",
+  "description": "Branch or tag name at that commit (optional).",
+  "type": "string"
+}

addedInput schema / properties / provenance_repo_url

Added value: +{
+  "default": "",
+  "description": "Repository URL the description was\ngathered from (``code`` kind).",
+  "type": "string"
+}

addedInput schema / properties / provenance_source_ref

Added value: +{
+  "default": "",
+  "description": "Identifier of the ticket or document the\ndescription came from (``ticket`` / ``document`` kinds).",
+  "type": "string"
+}

addedInput schema / properties / provenance_source_url

Added value: +{
+  "default": "",
+  "description": "URL of that ticket or document.",
+  "type": "string"
+}

Addedv0.62.2Jul 22, 2026
Removedv0.62.2Jul 22, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A4.9/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 behavioral burden. It discloses the multi-step AI pipeline, automatic progress reporting, and the critical non-obvious behavior: if an overlapping model exists, generation is short-circuited and no duplicate is created. It also names the exact return shape for that case. This is high-value behavioral transparency.

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 purpose, then methodology, then the important short-circuit behavior. Every section earns its place, and the length is justified by the need to explain a non-obvious control flow. There is no filler or tautology.

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 generation tool with 10 parameters and no annotations, the description covers the essential context: what the model is based on, the methodology used, produced artifacts, async pipeline behavior, and the similar-model branch. With an output schema available, return-value details are not needed. Nothing critical 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 description coverage is 90%, so the schema already documents most parameters. The description adds meaningful semantics by explaining the force parameter in context: it bypasses the similar-model short-circuit. It also clarifies the rationale behind choosing refine_threat_model versus forcing a new model. These additions go beyond the schema baseline.

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 clear verb-resource pair: 'Generate a complete threat model from a feature description.' It also names the methodology (Security Properties), the concrete artifacts produced (trust boundaries, asset inventory, attacker inventory, control objective matrix, assumptions), and distinguishes itself from refine_threat_model by explaining the relationship. This makes it easy for an agent to know exactly what this tool does.

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 addresses the similar-model short-circuit and gives a decision procedure: call refine_threat_model to extend a candidate, or retry with force=True to bypass. It even indicates the usual right answer, which is strong usage guidance beyond a generic 'use for X' statement.

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

Deploy Server