Skip to main content
Glama
Mipiti
by Mipiti

Set Objective Grouping

set_objective_grouping

Group or ungroup a threat model's objectives by asset groups, creating a new model version and remapping controls as objectives move.

Instructions

Group a model's objectives by asset groups, or stop grouping them. Mutating; creates a model version. Calls no model, so nothing is estimated: the judgements the new version re-keys are queued as for any edit.

Read get_objective_grouping first, relay the groups and the objective counts to the person, and pass the model_version it returned: a model that moved since is refused 409 review_stale. Grouping is refused 409 behavioural_off where get_objective_grouping reports available false; stopping is never refused for it. The write gate refuses it while a control build holds the model.

Grouping forms the groups from scratch; stopping deletes every group, so each asset has its own objectives again. Either way the controls' mappings move with the objectives (moved: each retired objective to where its mappings went), each mitigation group landing as a group of its own. A disposition on a retired objective does not carry over.

Input Schema

NameRequiredDescriptionDefault
enabledYes``true`` to group, ``false`` to stop grouping.
model_idYesID of the threat model.
model_versionYesThe version read with ``get_objective_grouping``.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.100.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 burden and does so thoroughly: it discloses that the tool is mutating, creates a model version, calls no model, queues judgements, and has destructive/regrouping effects on existing groups. It also explains mapping movement, mitigation group handling, and that dispositions on retired objectives do not carry over.

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 purpose is front-loaded, followed by usage, refusal conditions, and side effects. Some sentences are dense and multi-clause, but the operational detail is useful rather than filler.

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 complex mutating operation with no annotations and an existing output schema, the description supplies the critical preconditions, failure modes, side effects, and output-related context. Nothing essential for correct invocation appears to be missing.

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 coverage is 75%, and the schema already describes enabled, model_id, and model_version. The description adds prerequisite/refusal context for model_version and mode semantics for enabled, but server_version remains unexplained and the description does not fully compensate for that 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?

States a specific verb and resource: grouping a model's objectives by asset groups, or stopping grouping them. It clearly distinguishes the two modes and names the related read tool get_objective_grouping.

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?

Explicitly instructs the agent to read get_objective_grouping first, relay groups and counts, and pass the returned model_version. It also states when the call is refused with 409 review_stale, 409 behavioural_off, and while a control build holds the model.

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