Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Get Reachability Verdicts

get_reachability_verdicts

Determine if components or attack paths are reachable in a threat model by retrieving per-CO reachability verdicts. Supports single-model and composed-tree analysis.

Instructions

Per-CO reachability verdicts, over this model alone or the composed tree. Read-only; derived each time, never stored.

composed=False (default): derived from this model's own structure (components, asset.component_ids, trust_boundary.passes, each attacker's trust_boundary_ids and vector, assumption exclusion predicates), deterministic, the derivation an auditor re-runs. co_id returns one verdict (404 if absent or tombstoned). Returns {model_id, model_version, verdicts: [{co_id, kind, reason, narration, boundary_id?, assumption_id?}]}; kind is reachable, unreachable or indeterminate.

composed=True: the same derivation over the model with everything it inherits from its ancestors, for a child on the composition tree. Paginated (page, page_size); kind_filter keeps one kind; co_id is ignored. Returns {model_id, flag_enabled, verdicts: [{co_qid, asset_qid, attacker_qid, kind, reason}], total, page, page_size}, empty with flag_enabled: false where composition is not available.

An indeterminate verdict names the missing structure: attacker_unpositioned (edit_attacker with trust_boundary_ids), asset_unbounded (assign_to_components(target_type="asset")), no_shared_boundary (reposition the attacker, rescope the asset, or an add_assumption exclusion), missing_entity (restore it, or remove the CO). model_coherence_report presents the same gaps as findings.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`co_id`	No
`composed`	No
`model_id`	Yes
`page_size`	No
`kind_filter`	No
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.84.0Oct 4, 2026

removedInput schema / properties / co_id / description

Removed value: -"FLAT mode only. Optional CO id — when set, returns a single\nverdict; 404 if the CO doesn't exist or is tombstoned. Ignored\nwhen ``composed=True``."

removedInput schema / properties / composed / description

Removed value: -"When False (default), derive over this model's own\ntopology (flat). When True, derive over the composed effective\ntree (own ⊕ inherited)."

removedInput schema / properties / kind_filter / description

Removed value: -"COMPOSED mode only. Restrict verdicts to one kind —\none of ``\"reachable\" | \"unreachable\" | \"indeterminate\"``. Named\n``kind_filter`` (not ``kind``) to disambiguate from the verdict\nobject's own ``kind`` field. When omitted, all verdict kinds are\nreturned. Ignored when ``composed=False``."

removedInput schema / properties / model_id / description
```
Removed value: -"ID of the threat model."
```

removedInput schema / properties / page / description

Removed value: -"COMPOSED mode only. 1-indexed page number (default ``1``).\nIgnored when ``composed=False``."

removedInput schema / properties / page_size / description

Removed value: -"COMPOSED mode only. Verdicts per page (default ``100``).\nIgnored when ``composed=False``."

Changed5 schema fields changedv0.68.2Aug 22, 2026

changedInput schema / properties / co_id / description

Previous value: -"Optional CO id. When set, returns a single verdict;\n404 if the CO doesn't exist or is tombstoned."New value: +"FLAT mode only. Optional CO id — when set, returns a single\nverdict; 404 if the CO doesn't exist or is tombstoned. Ignored\nwhen ``composed=True``."

addedInput schema / properties / composed

Added value: +{
+  "default": false,
+  "description": "When False (default), derive over this model's own\ntopology (flat). When True, derive over the composed effective\ntree (own ⊕ inherited).",
+  "type": "boolean"
+}

addedInput schema / properties / kind_filter

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "COMPOSED mode only. Restrict verdicts to one kind —\none of ``\"reachable\" | \"unreachable\" | \"indeterminate\"``. Named\n``kind_filter`` (not ``kind``) to disambiguate from the verdict\nobject's own ``kind`` field. When omitted, all verdict kinds are\nreturned. Ignored when ``composed=False``."
+}

addedInput schema / properties / page

Added value: +{
+  "default": 1,
+  "description": "COMPOSED mode only. 1-indexed page number (default ``1``).\nIgnored when ``composed=False``.",
+  "type": "integer"
+}

addedInput schema / properties / page_size

Added value: +{
+  "default": 100,
+  "description": "COMPOSED mode only. Verdicts per page (default ``100``).\nIgnored when ``composed=False``.",
+  "type": "integer"
+}

First observedv0.57.0Jul 8, 2026

TDQS

A4.6/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 richly: it discloses read-only status, that verdicts are derived each time and never stored, determinism, 404 behavior for absent or tombstoned COs, pagination behavior, `flag_enabled: false` when composition is unavailable, and the meaning of each `kind`. It also enumerates the indeterminate-verdict reasons and points to the corrective actions for each.

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 front-loaded with the core purpose and then organized by mode, which is appropriate for a complex two-mode tool. It is long but mostly information-dense, with each section explaining distinct behavior. Some return-shape detail may overlap with the output schema, but the structure remains readable and useful.

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 7-parameter tool with no annotations, 0% schema coverage, and compositional behavior, the description is unusually complete. It covers both modes, parameter interactions, return behavior, error conditions, and the follow-up actions for indeterminate verdicts. An agent has enough context to invoke the tool correctly in either mode.

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 0%, so the description must compensate, and it explains five of the seven parameters in meaningful behavioral terms: `composed`, `co_id`, `page`, `page_size`, and `kind_filter`. It does not explain `server_version` or `model_id`, though `model_id` is likely self-evident. The default behavior for `composed` and the interaction between `co_id` and composed pagination are especially well covered.

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 and resource: per-CO reachability verdicts over a model alone or the composed tree. It immediately distinguishes the two scopes (`composed=False` vs `composed=True`) and notes the read-only derived nature of the result. An agent can tell what this tool returns without opening the schema.

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?

The description gives explicit mode-specific context: `composed=False` derives from the model's own structure, while `composed=True` is for a child on the composition tree. It also explains that `co_id` returns one verdict in the default mode and is ignored in composed mode, and that `kind_filter` keeps one verdict kind. It stops short of naming a preferred alternative beyond noting that `model_coherence_report` presents the same gaps as findings.

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

Deploy Server