Skip to main content
Glama
Mipiti
by Mipiti

get_reachability_verdicts

Evaluate threat model reachability verdicts across flat or composed topologies, returning structured reasons and boundary IDs for triage and auditing.

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_unpositionededit_attacker setting trust_boundary_ids

  • asset_unboundedassign_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

Behavior5/5

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

With no annotations, the description carries the full burden and goes beyond basics: flat derivation is deterministic and not persisted, co_id skips the cross-CO loop, pagination params are ignored in flat mode, and composed mode returns flag_enabled: false with empty verdicts when disabled. It also lists exact reason labels and the conditions producing indeterminate verdicts.

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 elaborates each mode, but the front-loaded summary and clear bullet-like structure make it scannable. The remediation guidance and sibling-tool distinction are useful, though the text could be tightened without loss of core information.

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 a 7-parameter tool with two modes and an existing output schema, the description covers all relevant behaviors: the two derivation modes, ignored parameters, return shapes, fallback behavior, and how to address indeterminate verdicts. It sufficiently equips an AI to invoke the tool correctly in both modes and interpret results.

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, but the description adds meaningful cross-modal semantics: it explains which parameters are ignored in flat mode, the effect of co_id, and the meaning of composed flag. It also maps verdict kinds and reason strings to concrete values such as 'boundary_blocks_vector' and 'attacker_unpositioned', going beyond the schema's per-parameter notes.

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?

'Per-CO reachability verdicts for a model — flat or composed topology' names a specific resource, verb, and mode concept. It clearly distinguishes the flat and composed retrieval cases and differentiates itself from model_coherence_report as the raw-verdict tool.

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 explicitly says when to use composed=True vs composed=False, when to pass co_id, and when to fall back to flat mode when composition is disabled. It also names model_coherence_report as the alternative for actionable findings and says 'Use this before relying on per-CO reach state for triage, auto-remediation, or audit responses.'

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mipiti/mipiti-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server