Skip to main content
Glama
Mipiti
by Mipiti

model_coherence_report

Detects coherence gaps in threat models: unknown components, mismatched repo bindings, and unreachable control-object paths, enabling resolution before audit.

Instructions

Static-analysis report on coherence between the model's component declarations, the code-binding strings on its controls and assertions, and the structural reachability of every CO.

Pass co_id to scope the report to findings carrying that CO id (the co_* reachability findings + the attestation cross-link findings). Component- and assertion-level findings without a CO binding are excluded in single-CO mode. 404 if the CO doesn't exist on the model.

The report carries up to twelve finding types, grouped below by concern. Each finding includes the entity IDs it concerns (co_id, asset_id, attacker_id, component_id, etc.) so the agent can dispatch the resolution tool directly without re-fetching the model.

Component / assertion bindings:

  • control_component_unknown — control references a component ID that no longer exists. Resolve: assign_control_to_components.

  • asset_component_unknown — asset references a missing component. Resolve: edit_asset (with corrected component_ids).

  • assertion_repo_mismatch — an assertion's repo does not match the repo_url of any component scoping its control. Resolve: rebind the assertion or rescope the control.

  • assertion_repo_orphan — an assertion has a repo but its control is unscoped. Resolve: assign_control_to_components to scope the control, or correct the assertion's repo.

  • control_unscoped_with_scoped_assertions — control is unscoped, but its assertions all carry a single component's repo. Resolve: assign_control_to_components to that component.

  • component_unbound — a component has no repo_url (speculative; LLM-proposed during generation, or operator- added without a binding yet). Resolve: edit_component with the real repo URL once the codebase exists. Speculative is a valid lifecycle state, not an error — surfaced so the gap is visible to auditors.

Reachability findings (deterministic composer; indeterminate verdicts surface as findings, never auto-decided by an LLM):

  • co_attacker_unpositioned — the CO's attacker has no positioned trust boundaries. Resolve: edit_attacker (set trust_boundary_ids), or add_assumption with a structured exclusion predicate.

  • co_asset_unbounded — the CO's asset has no component-derived trust boundaries. Resolve: assign_asset_to_components, edit_asset (with component_ids), or add_assumption with a structured exclusion.

  • co_no_shared_boundary — attacker and asset boundaries do not intersect. Resolve: re-position the attacker via edit_attacker, scope the asset to a shared component via assign_asset_to_components, or add_assumption with a structured exclusion.

  • co_missing_entity — the CO references a missing asset/attacker; model state inconsistent. Resolve: restore the entity (restore_asset / restore_attacker) or remove the orphaned CO via refine_threat_model.

Use this before relying on component-scoped control discovery, when assertion verification fails for path/repo reasons, or to enumerate structural-completeness gaps the operator should address before treating the model as audit-ready. get_reachability_verdicts exposes the underlying composer verdicts directly when the finding-shape summary isn't enough.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
co_idNoOptional CO id to scope the report to a single CO.
model_idYesID of the threat model.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations provided, but the description fully discloses behavior: it lists twelve finding types with resolution suggestions, explains single-CO mode behavior, 404 for nonexistent CO, and deterministic composer handling of indeterminate verdicts. This exceeds the burden carried without annotations.

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 well-structured with bullet points for finding types, front-loaded purpose, and every sentence adds value. Despite length, it remains focused and organized.

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 (12 finding types), the description covers scope, resolution hints, behavioral nuances, and references sibling tools. With an output schema likely detailing return values, the description is comprehensive for an AI agent.

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 67%, and the description adds significant value for 'co_id' by explaining scoping behavior and exclusion of unbounded findings. However, 'server_version' lacks any explanation beyond the schema, preventing a perfect score.

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 clearly defines the tool as a static-analysis report on model coherence, detailing specific components, bindings, and reachability. It distinguishes from sibling 'get_reachability_verdicts' by positioning this as a finding-shape summary when direct verdicts aren't needed.

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?

Explicitly states when to use: before relying on component-scoped control discovery, when assertion verification fails, or to enumerate structural-completeness gaps. Also notes when to use the alternative 'get_reachability_verdicts' for direct verdicts.

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