Skip to main content
Glama
Mipiti
by Mipiti

Get Control Work Order

get_control_work_order

Retrieve the complete work order for a control before implementing it: scan brief, evidence requirements, acceptance criteria, steps, delegation rules, and reconciliation guidance in one read.

Instructions

Get the work order for one control. Call this BEFORE implementing a control: it is the ticket. Read-only; no side effects.

The work order bundles everything an implementing agent needs in one read: the scan brief (where to look and what to look for), what counts as proof (the assertion_contract: which assertion types apply grouped by soundness class, the evidence rule, the universal rule, what to submit with, and when the control counts as verified), the acceptance_criteria and steps, the reconcile_rules to follow when the code disagrees with the model, the delegation block (what this agent may decide on its own and what must be escalated), any open_proposals on the control, and the model's provenance (whether the code or the description is authoritative).

The proof the order asks for is stated by-construction first. Where the order names a required class for a clause, required_evidence[] carries one entry per such clause: the clause text, its clause_id (the value to put in covers), its quantifier, the required_class that closes it, what is missing, and a suggested_submission skeleton (type, params_template, covers). The skeleton is a fill-in, not a submission: its <...> placeholders are values only you can supply, and one left unreplaced is refused — before the submission leaves this client and again when it arrives — by the same format rule, because a placeholder that validated would be recorded as a claim about your code that nothing backs. For a for-all clause the required class is [by_construction, sound_over_approximation] and the suggestion prefers typed_boundary — declare the type the sinks accept and its constructors — else sink_default_deny — declare the sinks that realise the clause, the safe forms, a reviewed allowlist. When evidence of the wrong class is already bound, missing says so: the evidence is the wrong CLASS, not merely incomplete. acceptance_criteria[] is GENERATED from those entries — a clause that has to hold at every site the attacker reaches is named as such, so no number of tests reads as closing it. steps[] reads: for each clause, submit the class the order names, bound with covers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model.
control_idYesID of the control to implement (e.g. "CTRL-03").
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.75.0

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and meets it: it states 'Read-only; no side effects' outright and discloses a notable behavioral rule — that an unreplaced placeholder is refused both at the client and on arrival by the same format rule. This is exemplary behavioral disclosure for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is well front-loaded (verb, timing, safety in two sentences), but the remainder is several dense paragraphs detailing return-value semantics — required_evidence[], assertion_contract, acceptance_criteria generation, steps, for-all clauses — that an output schema could carry. This is far more prose than a get tool needs, so it is over-specified rather than concise.

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 genuinely complex domain, the description richly explains why to call it and what the returned order contains, adding semantic nuances the output schema cannot convey (the skeleton is a fill-in not a submission; wrong evidence class vs incompleteness; acceptance_criteria being generated). The sole practical gap is the undefined server_version. It is over-explanatory rather than under-specified.

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 coverage is 67%: model_id and control_id are described, but server_version is undocumented in the schema and the description adds nothing about it. The description never mentions any of the three parameters or provides formats/value guidance beyond the schema's CTRL-03 example, so it does not compensate for the server_version gap.

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 opener 'Get the work order for one control' states a specific verb and resource, and 'Call this BEFORE implementing a control: it is the ticket' sharply positions it against siblings like get_controls (list), refine_control (mutate), delete_control (destroy), and update_control_status (state change). An agent can tell exactly what this tool is for and how it differs.

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?

Explicit when-to-use guidance is given ('Call this BEFORE implementing a control: it is the ticket'), which sequences the agent correctly relative to implementation. It does not name exclusions or alternative tools to consider instead, but the timing context and read-only framing effectively route the agent away from the mutating siblings.

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