Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Recompute Verdicts

recompute_verdicts

Re-run coverage and group-sufficiency verdict evaluation for a threat model, or obtain a pre-flight cost estimate. Use dry-run mode to quote charges before committing.

Instructions

Re-run coverage and group-sufficiency verdict evaluation for a model, or return the pre-flight cost estimate without enqueueing anything.

dry_run selects between enqueueing the recompute and a cost-only quote:

  • dry_run=False (default) — ENQUEUE: force a fresh evaluation of every control's coverage verdict and every live control objective's group-sufficiency verdict, bypassing the normal quiet-period batching. Evaluation runs in the background; re-read the model's divergence report (or coverage surfaces) shortly after to see updated verdicts. The response carries estimated_credits — an informational estimate; nothing is charged from it, actual usage is metered as the evaluation runs, per the account's plan. Returns {model_id, model_version, enqueued_coverage, enqueued_group_sufficiency, total_enqueued, estimated_credits, quote, governor}. When governor.exhausted is true the work is queued and resumes automatically at governor.resets_at — it is never dropped.

  • dry_run=True — QUOTE ONLY: return the informational pre-flight cost estimate and enqueue NOTHING. Nothing is charged from the estimate. It carries computed_at and the pricing rate_version in force so a stale quote is detectable. Returns {estimated_credits, computed_at, rate_version, informational, total_enqueueable, already_evaluated, governor}, where total_enqueueable is the number of jobs a recompute would enqueue and already_evaluated counts subjects that already carry a verdict (a portion short-circuit without cost, so the estimate is an upper bound). When governor.exhausted is true, new evaluation would be queued until governor.resets_at.

Scope — what this does NOT do. It evaluates control-objective COVERAGE and GROUP SUFFICIENCY only. It does not evaluate per-control sufficiency (whether a control's assertions cover its description) and it does not evaluate assertion coherence — both of those are computed on assertion write and read back with get_sufficiency / get_verification_report. So a control sitting at partially_verified, or an assertion showing coherence_status: "pending", is NOT a reason to call this tool: the verdict you want already exists, and recomputing spends credits without changing it. Reach for this only when control-to-CO MAPPINGS look wrong (see get_verdict_divergence).

Cost: this fans out across every control and live control objective, so on a large model the estimate can run to thousands of credits. Call it with dry_run=True first and surface the number to the operator before enqueueing.

Both modes return a 503-mapped error when verdict observability is unavailable on the deployment. To un-park verdicts stuck by a transient outage instead of force-enqueueing the whole model, use retry_verdicts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoWhen True, return only the pre-flight estimate and enqueue nothing. When False (default), enqueue the recompute.
model_idYesID of the threat model to re-evaluate (or estimate for).
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.68.2
    • addedInput schema / properties / dry_run
      Added value: +{
+  "default": false,
+  "description": "When True, return only the pre-flight estimate and enqueue\nnothing. When False (default), enqueue the recompute.",
+  "type": "boolean"
+}
    • changedInput schema / properties / model_id / description
      Previous value: -"ID of the threat model to re-evaluate."New value: +"ID of the threat model to re-evaluate (or estimate for)."
  2. Addedv0.62.2
  3. Removedv0.62.1
  4. Addedv0.60.1

TDQS

A4.9/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 disclosure burden and meets it thoroughly: it reveals background execution bypassing quiet-period batching, that estimated_credits is informational and nothing is charged from it, governor queueing behavior with resets_at and never-dropped semantics, the 503-mapped error condition, and the cost magnitude (thousands of credits). It also documents both return shapes and exposes the upper-bound nature of the estimate.

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?

Long but front-loaded and sectioned with bold heads (modes, scope exclusions, cost, error path). Every sentence carries unique information — no filler or restatement of the schema. The length is proportionate to the tool's real complexity: two behavioral modes with different return contracts and a critical negative scope that prevents wasted credits.

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?

For a high-complexity two-mode tool, nothing needed to call it correctly is missing: both modes' behavior and return fields, cost warning, exclusion scope, governor exhaustion handling, stale-quote detection, error mapping, and alternative entry points are all covered. An output schema exists and the description still documents return contracts in prose, exceeding the minimum bar.

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%; dry_run and model_id have schema descriptions while server_version does not. The description massively enriches dry_run semantics — full breakdown of both modes, return fields, governor behavior, and stale-quote detection — far beyond the schema's two-line description. However, server_version is a required parameter and receives no explanation in either the schema or the description, so the compensation is incomplete.

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 a specific verb and resource: 'Re-run coverage and group-sufficiency verdict evaluation for a model, or return the pre-flight cost estimate without enqueueing anything.' It precisely names what is evaluated (coverage and group-sufficiency verdicts), distinguishes the enqueue vs. quote-only modes, and explicitly carves out what it does NOT do (per-control sufficiency, assertion coherence), separating it from siblings like retry_verdicts and get_verdict_divergence.

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?

Gives explicit when-to-use and when-not-to-use guidance: reach for it only when control-to-CO mappings look wrong, and NOT when a control sits at partially_verified or an assertion shows coherence_status pending. Names concrete alternatives (get_sufficiency, get_verification_report, retry_verdicts) and the conditions that select them, plus a cost-based recommendation to call with dry_run=True first.

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