Systems Intelligence Performative Commercial Benchmarking

close_intervention

Close an active intervention by recording outcome notes and marking it complete, ending its eligibility for verify_change comparisons.

Instructions

Close an intervention with outcome notes and mark it complete. The intervention must exist and be active. Outcome notes should describe observed changes, unintended effects, and whether the target metric moved. After closing, the intervention is no longer eligible for verify_change comparisons. REQUIRES AUTHORIZATION — contact pilots@mos2es.org for pilot access. In the synthetic demo, this returns an authorization notice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`outcome_notes`	No	Free-text notes about the intervention outcome — observed changes, unintended effects, whether the target metric moved
`intervention_id`	Yes	Intervention ID to close (e.g., intv_001, intv_007). Must be an active intervention.

Output Schema

TableJSON Schema

Name	Required	Description
`tool`	Yes	Tool name that was called
`error`	Yes	Error type if authorization fails (e.g., 'authorization_required')
`status`	No	New status of the intervention (e.g., 'closed')
`message`	Yes	Human-readable status message
`closed_at`	No	ISO timestamp of closure (on success)
`intervention_id`	No	ID of the closed intervention (on success)

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.4.3Aug 28, 2026

changedInput schema / properties / intervention_id / description

Previous value: -"Intervention ID (e.g., intv_001)"New value: +"Intervention ID to close (e.g., intv_001, intv_007). Must be an active intervention."

changedInput schema / properties / outcome_notes / description

Previous value: -"Free-text notes about the intervention outcome"New value: +"Free-text notes about the intervention outcome — observed changes, unintended effects, whether the target metric moved"

addedOutput schema / properties / closed_at

Added value: +{
+  "description": "ISO timestamp of closure (on success)",
+  "type": "string"
+}

addedOutput schema / properties / error / description

Added value: +"Error type if authorization fails (e.g., 'authorization_required')"

addedOutput schema / properties / intervention_id

Added value: +{
+  "description": "ID of the closed intervention (on success)",
+  "type": "string"
+}

addedOutput schema / properties / message / description
```
Added value: +"Human-readable status message"
```

addedOutput schema / properties / status

Added value: +{
+  "description": "New status of the intervention (e.g., 'closed')",
+  "type": "string"
+}

addedOutput schema / properties / tool / description
```
Added value: +"Tool name that was called"
```

First observedv0.4.0Aug 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate idempotent=false and destructive=false, and the description adds significant behavior: the intervention becomes ineligible for verify_change after closing, and in the synthetic demo the call returns an authorization notice rather than performing the close. This is valuable context beyond the structured annotations.

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?

Every sentence earns its place: purpose, prerequisites, note content guidance, post-closing consequence, authorization requirement, and demo behavior. The structure is front-loaded with the core action and then expands with necessary details.

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?

The description covers what the tool does, when it is valid, what happens after, who is allowed, and what to expect in a demo environment. With only two simple parameters, nothing essential is 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 description coverage is 100%, so the baseline is 3. The description reinforces the meaning of outcome_notes by specifying what should be included, but it largely restates the schema rather than adding new detail.

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 ('close'), explicit resource ('intervention'), and the outcome ('mark it complete'). The reference to verify_change comparisons distinguishes it from its most related sibling, making its purpose unambiguous.

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?

Clearly specifies prerequisites (must exist and be active) and postconditions (no longer eligible for verify_change). The authorization requirement adds important gatekeeping context, though it does not explicitly name alternative tools for comparison.

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