Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Request Model Check

request_model_check

Request a model check of the obligations the behavioural analysis could not settle. Mutating only with confirm_estimate=True; a paid action then.

Instructions

Request a model check of the obligations the behavioural analysis could not settle. Mutating only with confirm_estimate=True; a paid action then.

A check is paid for by whoever requests it, so it is estimated first and the estimate is RELAYED TO THE PERSON before it is confirmed. Never confirm on your own.

Call with confirm_estimate=False (the default): nothing runs or is charged. The answer carries the obligations it would cover (each with its completion prediction), the scope, the cones (each module, its runs, and remedies / not_run where it may not complete or fits no runner), the estimate, the model_version and set_revision the model stands at, and notices on what a check does. Show all of it to the person. With nothing to check, the message says so: name obligations to check some anyway.
Once they agree, call with confirm_estimate=True and those two values. The check is queued (confirmed: true, job_id, status: "queued"); poll get_model_check until terminal.

Refusals come back as data, {confirmed: false, http_status, code, message}: 409 not_confirmed (confirm the behavioural model first, after reviewing it), differences_open (answer the open questions an earlier check raised), check_active (one is live: read it), generation_active (a build holds the model), review_stale (the model or its controls changed since the estimate: confirm again with the values returned), no_runner_size (every module is larger than any runner holds: answer the defaults it rests on, or narrow the scope or the obligations); 503 not_priced or no_runner_pool (checks cannot run here yet); 402 (the balance cannot cover the estimate). A 404 means model checks are not available for the model, or the caller may not start paid actions on it.

Input Schema

TableJSON Schema

Name	Required	Description
`scope`	No	Optional JSON object lowering some of the scope's constants, the keys the estimate's ``scope`` reports (e.g. ``{"domain": 1, "horizon": 4}``); each must be a non-negative integer at most the declared value, and those left out keep it (400 ``bad_scope`` otherwise).
`model_id`	Yes	ID of the threat model.
`obligations`	No	Optional comma-separated obligation ids to cover in place of the default (the unsettled ones the controls' groups reach).
`set_revision`	No	With ``confirm_estimate=True``: the estimate's value.
`model_version`	No	With ``confirm_estimate=True``: the estimate's value.
`server_version`	Yes
`confirm_estimate`	No	False (default) estimates; True queues the check.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.87.0Oct 14, 2026

TDQS

A4.8/5.0

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 does so thoroughly: it discloses that the action is paid, that the requestor pays, that step 1 charges nothing, that step 2 queues a job (confirmed/job_id/status), and enumerates concrete refusal codes (409 not_confirmed, check_active, generation_active, review_stale, no_runner_size; 503; 402; 404).

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?

Front-loaded with the core purpose and the mutating condition, then organized into numbered steps. It is long and the refusal-code enumeration is dense, but nearly every sentence carries routing or prerequisite information, so little is wasted.

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 paid, multi-step, gated operation with an output schema, the description supplies the flow, the confirmatory values, the async polling path, and the full refusal matrix. An agent has everything needed to call it correctly and interpret non-success responses.

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 (86%), so the baseline is 3, but the description adds real meaning: it explains confirm_estimate as the estimate-vs-queue switch and clarifies that model_version and set_revision come from the estimate's returned values in step 2.

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 (request), a specific resource (model check), and the exact scope (obligations the behavioural analysis could not settle). This cleanly separates it from siblings like get_model_check (polling) and manage_model_check.

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?

Lays out an explicit two-step protocol: call with confirm_estimate=False to estimate, show results to the person, then call with confirm_estimate=True once agreed. It also states an exclusion ('Never confirm on your own') and routes to get_model_check for polling.

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

Deploy Server