CONTINUUM

continuum_reconcile_action

Resolve an action with unknown outcome by checking the external system: record it as completed when it occurred or release it for retry when it did not.

Instructions

Settle an action whose outcome was unknown, after checking the external system. occurred=true records it as done (never repeated); occurred=false frees it to be retried. Only call this with real evidence; guessing here causes either a duplicate or lost work.

'action_key' accepts either the action_key from continuum_intercept_action or the action_id that continuum_resume and continuum_list_actions report, so the identifier named in next_allowed_action can be passed as-is.

Input Schema

Name	Required	Description	Default
`note`	No
`result`	No
`run_id`	Yes
`occurred`	Yes
`action_key`	Yes
`external_id`	No
`consumed_inputs`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Nov 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With only readOnlyHint=false in annotations, the description carries the important behavioral load: occurred=true records the action as done and prevents repeat execution, occurred=false permits retry, and guessing can cause duplicates or lost work. This is exactly the state-change context an agent needs.

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 first paragraph front-loads the operation, the occurred semantics, and the evidence warning; the second handles identifier compatibility. Every sentence adds useful information and there is no filler.

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?

An output schema exists, so return values need not be described, and the description covers the core decision logic and action_key compatibility. It is still somewhat incomplete because the 0%-documented optional input fields, especially evidence-related ones, are not explained.

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 description coverage is 0% for seven parameters, and the description explains only occurred and action_key in any depth. It leaves run_id, note, result, external_id, and consumed_inputs undocumented, which is a significant gap for a reconciliation call where evidence fields matter.

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 states a specific verb ('Settle') and resource ('an action whose outcome was unknown') and scopes it to reconciliation after checking the external system. That condition implicitly distinguishes it from complete/fail action siblings, so an agent can identify the intended case.

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?

It clearly says when to call: only for an unknown outcome after checking the external system and only with real evidence. It also warns that guessing causes duplicates or lost work, though it does not explicitly name complete_action/fail_action as alternatives for known outcomes.

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

Deploy Server