Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Model Coherence Report

model_coherence_report

Check a model's structural coherence: component bindings, assertion repo alignment, and CO reachability. Returns actionable findings to fix gaps. Read-only.

Instructions

How coherent a model's structure is: its component bindings, the repos its controls' assertions name, and whether every CO is structurally reachable. Read-only.

Pass co_id to keep only the findings about that CO (404 if it does not exist). Each finding carries type, severity, a message and the ids it concerns, so its fix can be called directly:

control_component_unknown, assertion_repo_orphan, control_unscoped_with_scoped_assertions: assign_to_components(target_type="control"). assertion_repo_mismatch: rebind the assertion or rescope the control.
asset_component_unknown: edit_asset with corrected component_ids.
component_unbound: for your own code, edit_component with the real repo_url. An external-zone component (a third-party service, a customer's IdP) stays unbound: the finding is a permanent marker of an external dependency, not a TODO, and client code touching it is no reason to bind it.
co_attacker_unpositioned: edit_attacker with trust_boundary_ids. co_asset_unbounded: assign_to_components(target_type="asset"). co_no_shared_boundary: reposition the attacker or rescope the asset; if the boundaries truly do not meet, that is the answer. co_missing_entity: restore_entity, or remove the CO.

An indeterminate reachability verdict means the structure it needs is missing: supply it. It never means the objective is inapplicable, which is a separate claim recorded with create_co_disposition. get_reachability_verdicts returns the raw verdicts.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`co_id`	No
`model_id`	Yes
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.84.0Oct 4, 2026
- removedInput schema / properties / co_id / description
```
Removed value: -"Optional CO id to scope the report to a single CO."
```
- removedInput schema / properties / model_id / description
```
Removed value: -"ID of the threat model."
```
Addedv0.62.2Jul 22, 2026
Removedv0.62.2Jul 22, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses the read-only nature, the 404-on-missing-CO behavior, the finding shape (type, severity, message, ids), and the nuanced semantics of an indeterminate reachability verdict. Remaining gaps (pagination, size limits, server_version semantics) are minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the description is organized with bullets, but it is long and dense for a read-only report, devoting substantial space to finding-type-to-fix mappings that border on workflow documentation. The information is useful but not tightly scoped.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is technically unneeded, yet the description still explains the finding structure and routes each finding to a fix. Combined with the reachability-verdict caveat, it is nearly complete, with the only real hole being the unexplained required parameters.

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

Parameters2/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 does so only for co_id (filter scope, 404 behavior, default = all). Both required parameters, model_id and server_version, are completely unexplained in the schema and the description, leaving the majority of parameters undocumented.

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 purpose: reporting how coherent a model's structure is across component bindings, assertion-name repos, and CO reachability, and explicitly marks it read-only. It partially distinguishes itself from the sibling get_reachability_verdicts ('returns the raw verdicts'), but other report siblings (assess_model, get_verification_report) are not referenced.

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 concrete usage context: pass co_id to scope findings, and each finding type is mapped to a specific remediation tool call (assign_to_components, edit_asset, edit_component, etc.), which is strong when-to-do-what guidance. It also clarifies the indeterminate-verdict case versus create_co_disposition. There is no explicit 'do not use this when...' exclusion, keeping it below a 5.

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

Deploy Server