Skip to main content
Glama
Mipiti
by Mipiti

Get Control Generation Status

get_control_generation_status

Read a model's current and proposed control build status, including progress, blockers, and hints, so you can poll, resume, or discard generation.

Instructions

Read a model's control build: the one proposed, and the last one started. Read-only.

A build runs only when someone starts it; a write that owes controls PROPOSES one. proposal (or null) carries mode, objective_count, estimated_credits and the model_version / set_revision that start_control_build must name. Poll until terminal; hint names the next action.

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

While running: ready_cos / target_cos count progress, never coverage; stage names the stage; elapsed_seconds is the time since the last progress (large means it may be stuck). selfheal_activity is a SAMPLE of what a strengthening round works on: read refining_total / authoring_total / set_aside_total for the counts; set_aside objectives wait for a person and are NOT a failure.

Once complete: covered_cos of judged_cos objectives would be mitigated by their controls; awaiting_judgement_cos have no answer yet. diagnosis counts covered, uncovered and undecided (what strengthen_controls works on), judging (queued: wait), not_judged (none queued: judge_objectives) and awaiting_assumption (in the review queue). strengthening says whether that pass has run. analysis_pending means the figures may still move; duration_seconds is the runtime.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
server_versionYes

Output Schema

TableJSON 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

A3.9/5.0
Behavior4/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 well: it enumerates the status state machine, explains deferred vs pausing vs paused, states that paused retains staged work, surfaces blocked codes with retry_after_seconds, and warns that set_aside is not a failure and that large elapsed_seconds may mean a stuck build. It omits auth/rate-limit or polling-frequency guidance, which keeps it short of a 5.

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?

Purpose is correctly front-loaded, but the bulk of the text is a field-by-field walkthrough of the response, which an output schema already covers. The state-semantics explanations add interpretive value, so it is not wasted, but it is longer than needed for a two-parameter polling tool.

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?

For a stateful build-tracking tool the behavioral coverage is thorough and an output schema exists, so return values do not need narrating here. The remaining gap is the complete silence on the two required input 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% and both required params (model_id, server_version) are undocumented in the schema, so the description must compensate. It never explains what model_id or server_version are or their formats; the only version-adjacent text refers to returned fields (model_version, set_revision), not inputs.

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?

The opening sentence names a specific verb and resource ('Read a model's control build') and immediately states scope ('the one proposed, and the last one started') plus the read-only nature. An agent can distinguish this from start_control_build, resume_control_generation and regenerate_controls without opening another schema.

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 a concrete usage loop ('Poll until terminal; hint names the next action') and explicit alternative routing ('retry with resume_control_generation, never regenerate_controls', and judge_objectives for awaiting_judgement). It lacks a clean when-to-call/when-not framing at the top, but the routing content is strong.

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