Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Control Generation Status

get_control_generation_status

A model's proposed control build and its last started one. Read-only.

Instructions

A model's proposed control build and its last started one. Read-only.

A build runs only when started. proposal (or null): mode, objective_count, estimated_credits (estimate_basis history|bootstrap), the model_version / set_revision / scope_revision start_control_build names, and what to review: flagged_entities, pending_attestations (attestations that would remove objectives from the build); flags_evaluated / attestations_evaluated false when not computed. Poll until terminal; hint names the next act.

status: queued | generating | deferred | pausing | paused | blocked | complete | failed | skipped | discarded | none. deferred waits for the budget reset; paused keeps its work until resume_control_generation or discard_control_build. blocked has code (dependency_unavailable or analysis_incomplete), message, retry_after_seconds: relay it and retry with resume_control_generation, never regenerate_controls (re-bills).

Running: ready_cos / target_cos are progress, not coverage. selfheal_activity is a SAMPLE of a strengthening round: read refining_total / authoring_total / set_aside_total; set_aside waits for a person, NOT a failure.

complete: figures come from diagnosis: covered, uncovered, undecided (strengthen_controls), judging (wait), not_judged (judge_objectives), no_group (group), grouping, no_control (start the build), awaiting_attestation (attest), awaiting_assumption (review queue), mitigated_elsewhere (nothing owed). covered_cos of judged_cos; awaiting_judgement_cos = not_judged + judging; excluded_cos, dispositioned_cos the rest. analysis_pending: figures may still move.

Input Schema

NameRequiredDescriptionDefault
model_idYes
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.84.0
    • removedInput schema / properties / model_id / description
      Removed value: -"ID of the threat model whose control-generation status to poll."
  2. Changed1 schema field changedv0.66.0
    • addedInput schema / properties / model_id / description
      Added value: +"ID of the threat model whose control-generation status to poll."
  3. Addedv0.62.2
  4. Removedv0.62.1
  5. Addedv0.62.0

TDQS

A4/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: read-only, poll-until-terminal behavior, deferred vs paused semantics, blocked codes with retry_after_seconds, that `set_aside` waits for a person and is NOT a failure, and that figures may still move while analysis_pending.

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 text is dense and front-loaded around status, but it is very long and much of the field-by-field enumeration overlaps what the output schema already documents. It is structured, yet several clauses could be relocated to the output schema without loss.

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 values needn't be explained, and the description nonetheless covers state transitions and next-step routing thoroughly. The main gap is that the required input parameters are left completely undocumented.

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?

The schema has 2 required parameters (model_id, server_version) at 0% description coverage, and the description never mentions either one or how they are supplied. It therefore does not compensate for the coverage gap as required at this level.

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 the resource precisely ('a model's proposed control build and its last started one') and marks it read-only, so the agent knows this is the status/proposal view. It distinguishes itself from siblings by naming what other tools do (resume, discard, regenerate). The verb is only implied, but the scope is unambiguous.

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?

It gives explicit operating instructions: poll until terminal, hint names the next act, and for `blocked` relay the message and retry with `resume_control_generation`, never `regenerate_controls` (re-bills). Several statuses are mapped to the sibling to invoke next, which is exactly the routing an agent needs.

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