Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Generate Threat Model

generate_threat_model

Generate a complete threat model from a feature description using the Security Properties methodology, producing trust boundaries, asset inventory, and control objectives.

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).

The request names its purpose, so the platform always generates: it never reads the description as a question or a change to another model.

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 ``update_threat_model``.
`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.

Changed1 schema field changedv0.84.0Oct 4, 2026

changedInput schema / properties / provenance_kind / description

Previous value: -"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``."New value: +"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 ``update_threat_model``."

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.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and performs well: it discloses a multi-step AI pipeline, automatic progress reporting, the exact JSON shape returned on similar-model short-circuit, and the rule that the request is always treated as generation rather than a question or a change to another model. It does not state permission/auth requirements, rate limits, or whether created models are reversible, which keeps it from a 5.

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?

The purpose is front-loaded in the first sentence, and the remaining sections are logically ordered: methodology, outputs, pipeline behavior, then similarity handling. It is longer than typical, but most sentences carry decision-relevant information; the closing paragraph about request intent is useful but slightly advisory.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex multi-step generation, 10 parameters, 90% schema coverage, and an output schema, the description covers the non-obvious behaviors an agent needs: pipeline execution, progress reporting, similarity short-circuit return shape, and next-step routing. It stops short of stating permissions or workspace side effects, but those are secondary for this tool.

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?

Schema description coverage is 90%, so the schema already documents the 10 parameters in detail; per the rubric that sets a baseline of 3. The description adds a usage cue for force=True but does not add meaning for parent_id, provenance fields, or the other parameters beyond what the schema provides.

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 (generate) and resource (threat model) scoped to a feature description, and names the methodology used. Sibling differentiation is explicit: the short-circuit paragraph points to refine_threat_model as the alternative when an overlapping model exists, so the agent can distinguish this tool from its nearest neighbor without opening schemas.

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 gives a clear when-not condition (backend finds a substantially overlapping model) and prescribes the alternatives: call refine_threat_model on a candidate, or retry with force=True to bypass. It also explains why refine is usually right (avoids duplicate modeling and preserves control/assertion history), which is exactly the kind of routing guidance the dimension rewards.

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

Deploy Server