Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Get Risk View

get_risk_view

Prioritize control objectives at model, system, or tag scope. Get one row per objective with risk tier, impact, likelihood, coverage, and open findings to identify where attention is needed.

Instructions

Prioritized Risk View — one row per live Control Objective — at a chosen scope. Read-only; no side effects.

scope selects the aggregation boundary and how scope_id is interpreted:

"model" — a single threat model (scope_id = model id). One row per live CO with derived risk tier, asset impact, attacker likelihood, control coverage counts (coverage_ratio), and open-finding count (open_findings). Tombstoned COs are excluded; pair with get_threat_model if historical context is needed. Use to triage which COs need attention on one model — a single call ranks the work, no per-CO fan-out.
"system" — every model in a System, a group of related threat models (scope_id = system id). Same row shape as model with model_id and model_title added per row, so rows can be grouped/filtered by source model without an extra lookup. Use for posture queries spanning multiple models in the same product or service.
"tag" — every member model of a tag, a freely-composed cohort (scope_id = tag id). One delegation-aware row per CO across members (delegation_mitigated / delegating_controls): a CO mitigated via a verified cross-model delegation reads as covered, consistent with each model's own assessment. Use for a portfolio/audit-scope posture rollup.

Input Schema

TableJSON Schema

Name	Required	Description
`scope`	Yes	aggregation boundary — "model", "system", or "tag".
`scope_id`	Yes	id of the model, system, or tag selected by ``scope``.
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.68.2Aug 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses read-only/no-side-effects, tombstoned CO exclusion, delegation-aware aggregation semantics, and that rows are per live CO with derived metrics. This goes well beyond the schema and removes ambiguity about side effects and filtering.

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 front-loaded with a one-line purpose and read-only note, then uses clearly separated bullets for each scope. Each bullet earns its place by adding scope-specific behavior and use cases. The length is justified by the tool's branching semantics.

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 output schema exists and the description already explains row shapes, exclusions, delegation behavior, and scope semantics, nothing essential is missing for an agent to invoke it correctly. Edge cases like tombstoned COs and model grouping are explicitly handled.

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?

The schema covers scope and scope_id only tersely, but the description adds rich meaning for both, explaining how each scope value changes the interpretation of scope_id and the resulting row shape. server_version still lacks any semantic explanation, which prevents a 5, but the main parameters are thoroughly clarified.

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?

States clearly what the tool does: returns a prioritized risk view of one row per live Control Objective at a chosen scope. It is explicitly distinguished from sibling get_threat_model by noting that historical context should be requested there, and the scope variants make the resource and behavior unmistakable.

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?

Provides explicit when-to-use guidance for each scope value: triage on a single model, posture queries across a system, and portfolio/audit rollups with tags. It also names an alternative tool (get_threat_model) for the case where tombstoned COs and historical context are needed, so an agent can choose correctly.

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

Deploy Server