Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Reachability Verdicts

get_reachability_verdicts

Retrieve reachability verdicts for threat model components to determine which attacker-asset paths are reachable, unreachable, or indeterminate, including composed topology for inherited context.

Instructions

Per-CO reachability verdicts for a model — flat or composed topology.

composed selects which topology the verdicts are derived over:

  • composed=False (default) — FLAT: verdicts over THIS model's own structural primitives only (components, asset.component_ids, trust_boundary.passes, attacker.trust_boundary_ids + attack_vector, Assumption.exclusion predicates). Pure derivation, NOT persisted on the CO — re-running against the model JSON is deterministic, the verification an auditor performs. Pass co_id to retrieve a single verdict (skips the cross-CO loop); page / page_size / kind_filter are ignored in this mode. Returns {model_id, model_version, verdicts: [...]} where each verdict carries co_id, kind ("reachable" | "unreachable" | "indeterminate"), reason (structural label: boundary_blocks_vector / assumption_excludes / attacker_unpositioned / asset_unbounded / no_shared_boundary / missing_entity), narration, and (when applicable) boundary_id / assumption_id.

  • composed=True — COMPOSED: the same verdict semantics evaluated over the merged effective tree (own components and trust boundaries combined with everything inherited from ancestors, qualified ids for cross-model references). Use this when the model is a child on the composition tree and you need reach state that reflects the ancestor topology, not just the local model document. Paginated via page / page_size and filterable via kind_filter; co_id is ignored (the composed surface has no single-CO lookup). Returns {model_id, flag_enabled, verdicts: [{co_qid, asset_qid, attacker_qid, kind, reason}, ...], total, page, page_size}. When composition is disabled on the backend, verdicts is empty and flag_enabled: false — fall back to composed=False for the per-model derivation.

When a flat verdict is indeterminate, address the gap via the standard model-edit affordances:

  • attacker_unpositioned → edit_attacker setting trust_boundary_ids

  • asset_unbounded → assign_to_components (target_type="asset") or edit_asset with component_ids

  • no_shared_boundary → re-position attacker, re-scope asset, OR add_assumption with structured exclusion

  • missing_entity → restore the missing asset/attacker, or remove the orphaned CO

Use this before relying on per-CO reach state for triage, auto-remediation, or audit responses. The model_coherence_report tool surfaces the same gaps as actionable findings; this tool exposes the raw verdicts when you need the structured data (boundary_id citations, narration strings) that the findings summarize.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoCOMPOSED mode only. 1-indexed page number (default ``1``). Ignored when ``composed=False``.
co_idNoFLAT mode only. Optional CO id — when set, returns a single verdict; 404 if the CO doesn't exist or is tombstoned. Ignored when ``composed=True``.
composedNoWhen False (default), derive over this model's own topology (flat). When True, derive over the composed effective tree (own ⊕ inherited).
model_idYesID of the threat model.
page_sizeNoCOMPOSED mode only. Verdicts per page (default ``100``). Ignored when ``composed=False``.
kind_filterNoCOMPOSED mode only. Restrict verdicts to one kind — one of ``"reachable" | "unreachable" | "indeterminate"``. Named ``kind_filter`` (not ``kind``) to disambiguate from the verdict object's own ``kind`` field. When omitted, all verdict kinds are returned. Ignored when ``composed=False``.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.68.2
    • 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"
+}
  2. First observedv0.57.0

TDQS

A5/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 burden and does so thoroughly. It discloses that flat derivation is pure and not persisted, that results are deterministic, that certain parameters are ignored per mode, that co_id returns a 404 for missing or tombstoned COs, and that composed mode returns empty verdicts with flag_enabled: false when composition is disabled.

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 long but tightly structured with bold mode headers, code formatting, and bullets. It front-loads the purpose, then explains mode behavior, return shapes, and remediation guidance. Every section earns its place and the formatting makes the length navigable.

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 description is complete for a tool of this complexity. It covers both modes, parameter interactions, pagination, fallback behavior, error cases, and the relationship to sibling tools. The output schema also exists, but the description goes beyond it by explaining mode-dependent return shapes and edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already high at 86%, the description adds substantial meaning beyond the schema. It explains mode-specific parameter behavior, qualified IDs for cross-model references, exact reason enum semantics, and maps each indeterminate reason to concrete remediation actions. This is far more than the schema alone 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?

The description states the exact function: 'Per-CO reachability verdicts for a model — flat or composed topology.' It clearly differentiates the two modes and explicitly contrasts this tool with model_coherence_report, so an agent can distinguish it from a large sibling tool list 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?

It gives explicit when-to-use guidance: 'Use this before relying on per-CO reach state for triage, auto-remediation, or audit responses.' It also names model_coherence_report as the alternative for actionable findings and explains when composed=True vs composed=False is appropriate, including fallback behavior when composition is disabled.

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