Skip to main content
Glama
Mipiti
by Mipiti

Regenerate Controls

regenerate_controls

Propose a regeneration of the model's controls. Starts nothing.

Instructions

Propose a regeneration of the model's controls. Starts nothing.

A regeneration re-authors controls from the current COs; its publish creates the next model version. Controls whose descriptions survive unchanged KEEP their implementation status, evidence, notes, assertions, and Jira / compliance mappings. Controls whose descriptions change or disappear are soft-deleted (still queryable via get_controls(include_deleted=True)). When co_ids is given, only those COs' controls are regenerated — all other controls are left as-is.

This tool records the regeneration as the model's PROPOSED build and returns at once with status: "proposed" and proposal (mode, objective_ids, objective_count, estimated_credits, and the model_version, set_revision and scope_revision a start must name). A proposal merges with any already proposed for the model, the broader one winning. Show the user what it would build and cost; once they agree, call start_control_build with those values and confirm_estimate=True. A build someone started holds the model, so this is refused (409 generation_active) until it finishes, or is resumed and finishes, or is discarded.

To rebuild everything, omit co_ids. To fix only stale/orphaned CO mappings without re-authoring control text, prefer remap_control (mechanical, no LLM).

Input Schema

NameRequiredDescriptionDefault
modeNo"batch" (default) or "per_co" (most thorough — one LLM call per CO).batch
co_idsNoOptional comma-separated CO IDs to regenerate (e.g. "CO1,CO5"). Omit to regenerate all controls.
model_idYesID of the threat model.
batch_sizeNoCOs per batch in batch mode (default 15). Smaller = more accurate and more granular progress, but more LLM calls.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.66.0
    • changedInput schema / properties / batch_size / description
      Previous value: -"COs per batch in batch mode (default: 15). Smaller\n= more accurate + granular progress, more LLM calls."New value: +"COs per batch in batch mode (default 15). Smaller =\nmore accurate and more granular progress, but more LLM calls."
    • changedInput schema / properties / co_ids / description
      Previous value: -"Optional comma-separated CO IDs to regenerate (e.g.\n\"CO1,CO5\"). When omitted, regenerates all controls."New value: +"Optional comma-separated CO IDs to regenerate (e.g.\n\"CO1,CO5\"). Omit to regenerate all controls."
    • changedInput schema / properties / mode / description
      Previous value: -"\"batch\" (default) or \"per_co\" (most thorough, one LLM\ncall per CO)."New value: +"\"batch\" (default) or \"per_co\" (most thorough — one LLM call\nper CO)."
  2. First observedv0.57.0

TDQS

A4.6/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 behavioral burden and does so thoroughly: it explains proposal merging, what happens to unchanged versus changed controls, soft-deletion, the immediate return shape, and the model-holding/refusal behavior. These details go well beyond the schema and make the side effects and state transitions clear.

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?

The description is front-loaded with the key distinction that this tool only proposes and starts nothing. It is necessarily detailed for a complex stateful operation, though it is long and repeats the co_ids omission behavior near the end.

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 complex proposal/build lifecycle, the absence of annotations, and the many sibling tools, the description provides a complete enough picture for correct invocation. It also explains the immediate return values and the required follow-up start_control_build call, despite an output schema existing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the schema already documents most parameters. The description adds some co_ids semantics—only selected COs are regenerated and others are left as-is—but does not explain mode, batch_size, model_id, or server_version beyond what the schema provides.

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 description states a specific verb and resource: it *proposes* a regeneration of the model's controls, and explicitly says 'Starts nothing.' It clearly distinguishes itself from start_control_build and remap_control, so an agent can tell what this tool does 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when/when-not guidance: call start_control_build after showing the user the proposal, omit co_ids to rebuild everything, and prefer remap_control for stale/orphaned mappings without re-authoring control text. It also explains the 409 generation_active refusal condition and the alternatives for resolving an active build.

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