Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Start Control Build

start_control_build

Start the model's proposed control build. Mutating only with confirm_estimate=True; consumes credits then.

Instructions

Start the model's proposed control build. Mutating only with confirm_estimate=True; consumes credits then.

A model's controls are built only by a build someone starts. Generating or refining the model, editing an entity and regenerate_controls each PROPOSE one; get_control_generation_status shows it as proposal.

  1. Call with confirm_estimate=False (the default). Nothing starts and nothing is charged; the answer is {started: false, proposal, message}, the proposal carrying a fresh estimated_credits and the model_version, set_revision and scope_revision the model stands at. Show the user what it would build and cost, and what it lists to review.

  2. Call again with confirm_estimate=True and those three values once they have reviewed the model. The build starts ({started: true, job_id, model_version, status: "queued", status_detail}) and holds the model until it publishes, fails or is discarded: other writers of the model's controls are refused meanwhile, and reads show the last published controls. Poll get_control_generation_status until terminal; the publish is one step, after which get_controls shows the result.

Refusals come back as data:

  • {started: false, http_status: 404, code: "no_proposal"} — nothing is proposed for the model.

  • {started: false, http_status: 409, code: "review_stale", proposal, model_version, set_revision, scope_revision, estimated_credits} — the model, its controls or the objectives the build would author changed since the values were read (or none were named). Review again and start with the values returned.

  • {started: false, http_status: 409, code: "generation_active", status} — a build already holds the model.

  • {started: false, http_status: 402, ...} — the balance this workspace bills to cannot cover the estimate.

Input Schema

NameRequiredDescriptionDefault
model_idYesID of the threat model.
set_revisionNoWith ``confirm_estimate=True``: the proposal's ``set_revision``.
model_versionNoWith ``confirm_estimate=True``: the proposal's ``model_version``.
scope_revisionNoWith ``confirm_estimate=True``: the proposal's ``scope_revision``.
server_versionYes
confirm_estimateNoFalse (default) returns the proposal and its estimate and starts nothing; True starts the build.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.87.0
    • addedInput schema / properties / scope_revision
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "With ``confirm_estimate=True``: the proposal's\n``scope_revision``."
+}
  2. Addedv0.84.0

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: it discloses that the tool is mutating only when ``confirm_estimate=True``, that credits are consumed at that point, that the build locks the model ('other writers of the model's controls are refused meanwhile'), and it enumerates concrete refusal codes (404 no_proposal, 409 review_stale, 409 generation_active, 402 insufficient balance) with recovery instructions.

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 two-phase contract, then a bulleted refusal table – a structure that lets an agent scan to the error case it hits. It is long, and some of the verbatim response payloads duplicate what the existing output schema already provides, which is the only thing keeping it from a 5.

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 credit-consuming, model-locking mutation with no annotations, this is essentially complete: side effects, the confirm gate, the locking window, the polling loop and every documented failure mode are all present. Output schema exists, so the description is not obligated to explain return values, yet it still maps them to next actions.

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 83%, so the schema already documents most parameters and baseline is 3. The description adds genuine meaning beyond the schema by explaining that ``model_version``, ``set_revision`` and ``scope_revision`` must be carried over from the proposal returned in step 1, and by describing the default/true split of ``confirm_estimate`` in terms of side effects rather than just types.

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 precise verb+resource ('Start the model's proposed control build') and immediately scopes it against siblings by noting that generating/refining the model, editing an entity and ``regenerate_controls`` merely PROPOSE a build. An agent can distinguish it from ``regenerate_controls``, ``get_control_generation_status`` and ``discard_control_build`` without opening any 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?

Gives an explicit ordered procedure: first call with ``confirm_estimate=False`` to preview cost and revisions, then call again with ``confirm_estimate=True`` once the user has reviewed. It names the polling alternative (``get_control_generation_status``) and the terminal condition, so when-to-use and what-to-do-next are both unambiguous.

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