Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Threat Model

get_threat_model

Retrieve a threat model by ID to read its trust boundaries, assets, attackers, assumptions, and components, with optional paginated clarifications and inventory completeness data.

Instructions

Get a threat model by ID: its trust boundaries, assets, attackers, assumptions and components. Read-only.

The answers to its questions are counted (clarification_count) and left out unless include_clarifications=True, which pages them (clarifications_offset, clarifications_limit: default 50, at most 200; clarifications_next_offset null at the end). A read over 200,000 characters is cut, and cuts says what and how to read it: the objectives, then the clarifications, then each entity collection, largest first, kept as rows that name its entities.

include_inventory_completeness=True (latest version only) adds inventory_completeness: how much of the inventory the claims rest on, with bounded_by (the entities holding the tier down) and grounding_gaps, keyed by entity id. Each gap names a ground the entity lacks (position, privileges, extent, components, flagged, inherited), a detail, and acts: each act's mcp_tool and mcp_arguments (that tool's arguments, the entity named and lists comma-separated; fields is the REST body), a value in angle brackets being yours to fill. Taking every listed act grounds the entity; a gap with no act says no act can supply it on this deployment. An attestation an act names is a judgment (see edit_attacker). null when the record could not be read.

Important for agents reading model state:

  • Assets and attackers may carry deleted: true (soft-deleted). Exclude these when showing "what's in the model now"; include them only when discussing history or offering restore. Restore an entity via restore_entity (entity_type="asset") / restore_entity (entity_type="attacker").

  • Control objectives may carry removed: true (tombstone — the (asset, attacker) pair was removed in a later version). Exclude these from coverage math and LLM prompts; they exist to keep CO IDs stable so controls referencing them can be detected as "orphaned" rather than silently rebinding.

Input Schema

NameRequiredDescriptionDefault
versionNoOptional specific version number. Defaults to latest.
model_idYesID of the threat model.
include_cosNoInclude control objectives inline (default False: the answer carries no ``control_objectives`` key; read them with ``get_control_objectives``).
server_versionYes
clarifications_limitNoAnswers per page.
clarifications_offsetNoThe first answer of the page.
include_clarificationsNoInclude a page of the answers to the model's questions (default False).
include_inventory_completenessNoAdd the completeness record and its ``grounding_gaps`` (default False).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.91.0
    • addedInput schema / properties / clarifications_limit
      Added value: +{
+  "default": 50,
+  "description": "Answers per page.",
+  "type": "integer"
+}
    • addedInput schema / properties / clarifications_offset
      Added value: +{
+  "default": 0,
+  "description": "The first answer of the page.",
+  "type": "integer"
+}
    • addedInput schema / properties / include_clarifications
      Added value: +{
+  "default": false,
+  "description": "Include a page of the answers to the\nmodel's questions (default False).",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.87.0
    • addedInput schema / properties / include_inventory_completeness
      Added value: +{
+  "default": false,
+  "description": "Add the completeness record and\nits ``grounding_gaps`` (default False).",
+  "type": "boolean"
+}
  3. Changed1 schema field changedv0.84.0
    • changedInput schema / properties / include_cos / description
      Previous value: -"Include control objectives inline."New value: +"Include control objectives inline (default False:\nthe answer carries no ``control_objectives`` key; read them\nwith ``get_control_objectives``)."
  4. 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 provided, the description carries the full behavioral burden and does so thoroughly. It discloses read-only status, pagination defaults and limits, the 200,000-character cut behavior via cuts, null behavior when the record cannot be read, soft-delete and tombstone semantics, and the latest-version constraint for inventory completeness.

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 into behavior, agent warnings, and edge-case semantics. Most sentences add real value for a complex retrieval tool, though some of the detailed return-value explanation could be trimmed given the presence of an output schema.

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 tool is complex, with eight parameters and no annotations, and the description covers the operational constraints an agent needs to call it correctly. Although an output schema exists, the description adds useful context about truncation, pagination, and special record states, so nothing critical appears 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 coverage is high at 88%, so the schema already defines most parameters. The description still adds meaningful semantics beyond the schema, notably clarifications pagination maximums and end-of-page signaling, latest-version restriction for inventory completeness, and the use of angle-bracket placeholders in grounding_gaps actions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: retrieve a threat model by ID, including its trust boundaries, assets, attackers, assumptions, and components. It is far from tautological and clearly distinguishes this from list-oriented tools, but it does not explicitly explain how it differs from a sibling such as query_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 Guidelines4/5

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

It gives clear usage context by labeling the operation read-only and by providing explicit guidance for agents reading model state, including how to treat soft-deleted assets/attackers and tombstoned control objectives. It also explains when include flags change the result, but it does not directly route the agent between this tool and alternatives such as query_threat_model or get_entity.

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