Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Apply Control Changeset

apply_control_changeset

Apply control operations (remap, delete, add, set_groups) as one atomic transaction, all or nothing. Use to deduplicate controls and reassign objectives without losing evidence.

Instructions

Apply a batch of control operations atomically as ONE transaction.

Use this to reorganize a model's controls in a single step — for example to deduplicate controls (remap several onto the right objectives and delete the redundant ones at once), instead of many separate calls. All operations commit together or not at all.

Mapping-only: remap/delete/set_groups change objective mappings and retire controls but never re-author a control's description, so a kept or reused control keeps its status, evidence, and assertions. The orphan guard is evaluated on the FINAL state of the batch, so a delete paired with a covering remap or add in the same changeset is allowed; a changeset that would leave any previously-covered control objective uncovered is rejected as a whole and nothing is written.

Input Schema

TableJSON Schema

Name	Required	Description
`ops`	Yes	JSON array of operation objects. Each object has an "op" of "remap", "delete", "add", or "set_groups": - remap: {"op": "remap", "control_id": "CTRL-03", "co_ids": ["CO1", "CO2"]} - delete: {"op": "delete", "control_id": "CTRL-09", "reason": "duplicate of CTRL-03"} - add: {"op": "add", "description": "...", "co_ids": ["CO5"], "mitigation_group": 1} - set_groups: {"op": "set_groups", "co_id": "CO1", "groups": {"1": ["CTRL-03"], "2": ["CTRL-04"]}}
`model_id`	Yes	ID of the threat model.
`change_reason`	Yes	Why this reorganization is appropriate (min 10 chars). Recorded on every affected control's version history.
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.66.0Aug 5, 2026

TDQS

A4.4/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 of behavioral disclosure and does so thoroughly. It explains atomic all-or-nothing commit, mapping-only semantics, preservation of status/evidence/assertions, and the orphan guard evaluated on the final state. This is exemplary transparency for a mutation tool.

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

Conciseness5/5

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

The description is detailed but every sentence earns its place. It front-loads the core purpose, then adds necessary transaction and constraint details without repetition or fluff. The structure is well organized for a complex 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?

The description fully addresses the tool's complexity: atomicity, operation types, orphan guard behavior, and mapping-only effects. An output schema exists, so return values are covered elsewhere. The only minor gap is server_version, which is neither described in the schema nor the description.

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%, so most parameter meaning is already provided by the schema. The description adds valuable context about operation behaviors but does not significantly elaborate on individual parameter semantics beyond what the schema already includes. server_version remains undocumented, but the high schema coverage keeps this at baseline.

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 opens with a specific verb and resource: 'Apply a batch of control operations atomically as ONE transaction.' It clearly distinguishes this batch tool from single-operation siblings like remap_control and delete_control by emphasizing atomic, multi-operation changes.

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?

The description explicitly states when to use it: to reorganize controls in one step, such as deduplication, 'instead of many separate calls.' It does not explicitly name alternative tools or exclude single-operation cases, but the context is clear enough for an agent to choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server