Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Create Co Disposition

create_co_disposition

Documents that a control objective does not apply, with owner, justification, and expiry; keeps it visible for review while suppressing controls and coverage gaps.

Instructions

Record that a control objective DOES NOT APPLY to this system — a signed, expiring judgment, not a dismissal.

The sibling of create_risk_acceptance, and the distinction between them is the claim being made. A risk acceptance says the exposure is real and we are carrying it. A disposition says this objective does not apply here at all — the asset is not handled the way the objective assumes, the attacker position does not exist in this deployment, the capability is not present.

The objective is not removed. It stays in the control-objective matrix, stays in every coverage count, and is reported in its own class alongside the owner and justification recorded here. That is the point: a reviewer can see the judgment and challenge it. An objective that simply vanished would be indistinguishable from one nobody modelled.

What it does change is work: no controls are generated for the objective and no coverage gap is raised against it, because an objective that does not apply is not a gap.

review_by is required and is not a formality — the claim stops applying on that date, and the objective returns to whatever posture its controls give it, gap included. Choose a date by which someone can realistically re-check that the claim still holds.

Use create_risk_acceptance instead when the objective DOES apply and the exposure is being carried deliberately. If an objective is only unaddressed rather than inapplicable, neither tool is right — add controls.

Input Schema

TableJSON Schema

Name	Required	Description
`owner`	Yes	Who owns the judgment (name / role). They answer for it.
`model_id`	Yes	ID of the threat model.
`review_by`	Yes	ISO 8601 date the claim expires (e.g. "2027-02-06T00:00:00Z").
`justification`	Yes	Why the objective does not apply to this system.
`server_version`	Yes
`control_objective_id`	Yes	The objective being declared not applicable.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.71.0Sep 1, 2026

TDQS

A4.8/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 disclosing behavioral traits. It does this thoroughly: the objective remains in the matrix, no controls are generated, no coverage gap is raised, and the claim expires at review_by. This goes far beyond what the schema alone communicates.

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 core claim and then structured into clear behavioral, temporal, and alternative-usage sections. It is longer than strictly necessary, but the length is justified by the nuance of the tool and the need to prevent confusion with create_risk_acceptance.

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 6 required parameters, no annotations, and an existing output schema, the description covers the tool's semantics, side effects, timing constraints, and sibling distinctions thoroughly. An agent has enough information to decide when to call it and what the call will do.

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 high at 83%, so the baseline is already solid. The description adds meaningful semantics beyond the schema, especially for review_by: it is 'not a formality,' the claim stops applying on that date, and the date should be realistic for re-checking. It also reinforces that owner is the accountable party.

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: 'Record that a control objective DOES NOT APPLY to this system.' It also explicitly distinguishes this from create_risk_acceptance by defining the type of claim being made, so an agent can tell the tools apart without needing to compare schemas.

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?

The description gives explicit routing guidance: use create_risk_acceptance when the objective DOES apply and the risk is carried deliberately, and use neither tool when an objective is merely unaddressed rather than inapplicable. It also explains the operational consequences of using this tool, giving clear context for when it is appropriate.

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

Deploy Server