Skip to main content
Glama
Mipiti
by Mipiti

Generate Threat Model

generate_threat_model

Generate a threat model from a feature description: trust boundaries, assets (Confidentiality, Integrity, Availability, Usage), capability-defined attackers, the control objective matrix and assumptions.

Instructions

Generate a threat model from a feature description: trust boundaries, assets (Confidentiality, Integrity, Availability, Usage), capability-defined attackers, the control objective matrix and assumptions. A multi-step pipeline; progress is reported automatically.

Similar models: where an existing model of the workspace overlaps the description, nothing is generated: {"similar_models": [{"id", "title", "reason"}], "suggestion"}. Refine a candidate with refine_threat_model (usually right: it keeps controls and history), or retry with force=True once the operator confirms it is distinct.

Saved first: where the platform models what the system does, the model is saved holding the description and generated from it later. extracting: true (model_id, job): its behaviour is extracted in the background. needs_answers: true (model_id, questions): RELAY THE QUESTIONS TO THE PERSON and answer them with answer_behavioural_questions. Then poll get_behavioural_model until generation_ready is true and call generate_from_behavioural_model with the model_id (next says so). No control build is proposed until then. Deprecated: model_id here; with an empty description it does the same, with one it is refused (resume_takes_no_description).

Answer: {model_id, version, title, asset_count, attacker_count, control_objective_count, controls_status, ...}. proposed: a build is proposed (proposal: what it builds, estimated_credits, the model_version, set_revision and scope_revision a start names); review it with the user, then start_control_build with confirm_estimate=True. none_owed: nothing is owed; unavailable / error: read get_control_generation_status. A governor at warning or exhausted: relay it; queued work resumes at resets_at, never dropped.

Input Schema

NameRequiredDescriptionDefault
forceNoSkip the similar-model detection and always create a new model. Default False: the check fires unless the operator or agent has explicit reason to bypass it.
model_idNoDeprecated: use ``generate_from_behavioural_model``. With an empty ``feature_description`` it does the same; with a description it is refused (``resume_takes_no_description``).
parent_idNoOptional 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_refNoBranch or tag name at that commit (optional).
server_versionYes
provenance_kindNoWhere 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_descriptionYesDescription of the feature or system to threat model. Can be a few sentences or a detailed spec.
provenance_repo_urlNoRepository URL the description was gathered from (``code`` kind).
provenance_commit_shaNoCommit SHA the description was gathered at (``code`` kind).
provenance_source_refNoIdentifier of the ticket or document the description came from (``ticket`` / ``document`` kinds).
provenance_source_urlNoURL of that ticket or document.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.90.0
    • changedInput schema / properties / force / description
      Previous value: -"Skip the similar-model detection and always create a\nnew model. Default False — the check fires unless the\noperator / agent has explicit reason to bypass it."New value: +"Skip the similar-model detection and always create a\nnew model. Default False: the check fires unless the\noperator or agent has explicit reason to bypass it."
    • changedInput schema / properties / model_id / description
      Previous value: -"Only to resume a generation that stopped on owner\nquestions (above): the model it saved. Pass it once\n``get_behavioural_model`` reports ``generation_ready: true``.\nBefore then it is not a resume, and a new model is generated."New value: +"Deprecated: use ``generate_from_behavioural_model``. With\nan empty ``feature_description`` it does the same; with a\ndescription it is refused (``resume_takes_no_description``)."
    • changedInput schema / properties / parent_id / description
      Previous value: -"Optional ID of an existing model to wire the new\nmodel under as a child on the recursive composition tree.\nThe child then inherits the parent's topology and\nparticipates in composition (delta / inherited control\ncredit). Default None — the model is created flat."New value: +"Optional ID of an existing model to wire the new\nmodel under as a child on the recursive composition tree.\nThe child then inherits the parent's topology and\nparticipates in composition (delta / inherited control\ncredit). Default None: the model is created flat."
  2. Changed1 schema field changedv0.87.0
    • addedInput schema / properties / model_id
      Added value: +{
      +  "default": "",
      +  "description": "Only to resume a generation that stopped on owner\nquestions (above): the model it saved. Pass it once\n``get_behavioural_model`` reports ``generation_ready: true``.\nBefore then it is not a resume, and a new model is generated.",
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.84.0
    • 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``."
  4. Changed6 schema fields changedv0.75.0
    • 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"
      +}
  5. Addedv0.62.2
  6. Removedv0.62.2
  7. First observedv0.57.0

TDQS

A4.6/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 the multi-step pipeline, automatic progress reporting, similar-model suppression behavior, background extraction, deprecated model_id handling, response branches such as proposed/none_owed/unavailable/error, governor states, and queued-work resumption. It goes well beyond a bare operation description.

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 description is long and dense, but it is front-loaded with the core purpose and organized under clear bold headings for similar-model handling, saved-first behavior, and response branches. For a complex multi-step pipeline with many edge cases, most sentences earn their place, though the density is near the upper limit.

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?

Given the tool's complexity, 11 parameters, no annotations, and an existing output schema, the description is complete enough for an agent to understand generation, fallback paths, deprecations, response branches, and next actions. It does not need to explain raw return values because the output schema covers that, but it still provides useful workflow context.

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 91%, so the schema already documents most parameters in detail. The description reinforces force usage and deprecated model_id behavior, but it does not add much parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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 specific verb and resource: 'Generate a threat model from a feature description', and names the exact outputs (trust boundaries, assets, attackers, control objective matrix, assumptions). It also distinguishes the tool from siblings by calling out refine_threat_model and generate_from_behavioural_model as alternative paths.

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 explicit when-to-use and when-not-to-use guidance: overlap with existing models suppresses generation and routes to refine_threat_model or force=True after operator confirmation. It also lays out the saved-first flow, including relaying questions via answer_behavioural_questions and polling get_behavioural_model before calling generate_from_behavioural_model.

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