CONTINUUM

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

Annotations only declare readOnlyHint=false, so the description's explanation that recovery replays from the newest checkpoint and that checkpointing bounds crash cost is real added context about consequences. It stops short of saying whether checkpoints are overwritten or retained, or what the call returns, but with an output schema present that latter gap is acceptable.

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

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

Two short paragraphs, front-loaded with the action and timing guidance, with the parameter guidance split out appropriately. The model_id sentence is slightly circuitous but its content is not wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The purpose, timing, and recovery semantics are complete, and the output schema covers return values. The definition is still incomplete for a 5-parameter tool where three optional parameters and the sole required one are undocumented anywhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry full parameter burden, and it only explains model_id (its role in continuum_resume's model-identity check and the 'unknown' fallback). The required run_id and the env, reason, and provider parameters are given no meaning at all in either structured or prose form.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Save a durable checkpoint of the current task state.' That clearly separates it from the record_* siblings, which log progress/summaries rather than snapshotting state, though the description never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger conditions: at milestones, before risky or irreversible steps, and before a long gap. What's missing is a negative case or an explicit contrast with continuum_record_progress, which an agent could easily confuse with checkpointing.

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

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

Annotations only give readOnlyHint=false; the description adds the meaningful behavioral fact that this mutates action state to COMPENSATED and must be called post-hoc, after the reversal, not before. It stops short of saying what happens on a duplicate call or whether the transition is reversible.

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

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

Three short sentences with the core verb first, the operational trigger second, and the resulting state third. Nothing redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema means return values need not be described, and the state transition is covered. But for a 4-parameter mutation tool with no schema descriptions, leaving by and note entirely unexplained is a real gap an agent could trip over.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description explains none of the four parameters. An agent must infer that 'the action' is identified by action_key and the side effect by run_id, and gets no clue about what 'by' (actor) or 'note' are for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: recording that a completed side effect was undone, and marking the action as COMPENSATED. It implicitly separates itself from continuum_complete_action and continuum_fail_action by insisting the compensating work has already been executed, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Call this after executing a compensating action' gives a clear trigger condition tied to ordering in the workflow. It does not state when NOT to use it or name continuum_reconcile_action / continuum_complete_action as the alternatives an agent should prefer in other cases.

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

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

Annotations only say readOnlyHint=false, so the description carries most of the burden and does well: it discloses the cost of omission ('leaves the action uncertain and blocks recovery') and the purpose of consumed_inputs ('recorded for restore-point admissibility') with its default of none. It does not address idempotency, retry, or what happens if completion is reported twice for the same action_key.

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

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

Three sentences ordered well: what it is, exactly when to call it, then the optional input. The consumed_inputs parenthetical is dense but every clause conveys real information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with an output schema (so return values need no explanation), the workflow guidance is solid, but an agent still cannot learn where run_id comes from or what result and external_id are expected to contain. The core pairing with continuum_intercept_action is explained; the remaining required/optional fields are not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains action_key (returned by continuum_intercept_action) and enumerates the sub-fields of consumed_inputs in useful detail, but run_id, result, and external_id are completely undocumented in either place, leaving 3 of 5 parameters opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Report that ... succeeded') and resource (an intercepted action), tying it to the exact lifecycle stage. The 'intercepted action' framing separates it cleanly from continuum_fail_action, continuum_compensate_action, and continuum_intercept_action without needing to see the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete trigger ('immediately after performing the side effect') and names the sibling that supplies the required key (continuum_intercept_action), plus a consequence for skipping. It does not explicitly route the failure path to continuum_fail_action, so the when-not is only implied by the word 'succeeded'.

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

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

Annotations only say readOnlyHint=false, but the description adds far more: the operation mutates the run, it will be REFUSED without an operator-set token, and an agent must not self-certify. That refusal condition is critical behavioral information an agent cannot get from structured fields.

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

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

Front-loaded with purpose, then auth gate, then parameter semantics — good ordering. Dense and nearly every sentence earns its place, though the issue #394 citation and the restated 'Mutates the run' at the end add minor noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, auth-gated tool the description covers safety, refusal conditions, and scope semantics thoroughly, and an output schema exists so return values need no explanation. The only gap is expected_model, which is undocumented in both schema and description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does for scope (["goal"] / ["progress"] vs omit for full confirm), but 'expected_model' is never mentioned and 'run_id' is only implied. Strong partial coverage of a 3-param tool, with one clear omission.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Confirm a run's self-reported goal and progress so it can resume') and immediately frames the situation that distinguishes it from siblings like continuum_resume or continuum_record_progress. An agent can tell exactly what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the preferred alternative ('the normal path is for a human to run continuum confirm <run_id> on the host') and the exact precondition for the agent path (CONTINUUM_MCP_CONFIRM_TOKEN presented as _meta.authToken). It also explains the partial-vs-full confirm choice via scope, leaving nothing to inference.

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

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

Beyond the bare readOnlyHint=false, the description explains the real consequence of a wrong flag — treating an ambiguous outcome as failed 'could cause a duplicate' — which is exactly the behavioral risk an agent needs. It does not cover idempotency guarantees, retry behavior, or whether repeated failure reports are safe.

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

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

Three sentences, front-loaded with the action, then the decision rule, then the rationale. No filler, and the most dangerous mistake (duplicate creation) is stated last as the payoff for the rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no explanation, and the critical semantic ambiguity of 'certain' is fully resolved. What's missing is the expected content/format of 'error' and any pointer to the reconcile sibling for ambiguous cases, which keeps it just short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only illuminates one of four parameters ('certain', with default false), explaining it very well. run_id, action_key, and especially the free-form 'error' string get no guidance on format or content, so half the parameter surface remains undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Report that an intercepted action failed'), making it clearly distinct from completion/compensation siblings. It does not explicitly name the counterpart tools (e.g. continuum_complete_action, continuum_reconcile_action), so differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete when-to-use guidance for the key decision: certain=true only when nothing happened (rejected before send), certain=false for timeouts/dropped connections. It stops short of naming a sibling alternative such as continuum_reconcile_action for ambiguous outcomes, which would have made routing explicit.

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

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

The only annotation is readOnlyHint=false, so the description carries nearly the full burden and does so well: it discloses the proceed/unknown return semantics and the interruption behavior that could otherwise cause duplicate side effects. It does not discuss auth/grant requirements or failure/error modes beyond the interrupted case.

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

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

Front-loaded with the decision rule and outcomes in the first sentences, then a focused second paragraph on the deduplication key. It is slightly long and contains a typo ('may or may or may not'), but every sentence carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully explains the return contract, and the interrupt/duplicate workflow is fully covered. The residual gap is behavioral detail on the optional control parameters (grant, pinning, scoped_to_run), which an agent would have to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there are 7 parameters, so the description must compensate. It does an excellent job on `key` (stable identity, reuse across sessions, formatting-immunity rationale), but `run_id`, `action_type`, `grant`, `pinning`, `arguments`, and `scoped_to_run` are left entirely undocumented — notably `grant`, which likely governs authorization for the action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and intent: ask permission before an external side effect, with concrete examples (creating an issue, sending a message, charging a card). It also names the follow-up tool continuum_complete_action, which cleanly separates it from continuum_fail_action and continuum_reconcile_action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing for every outcome: do it when proceed=true, do NOT repeat when proceed=false with a prior result, and stop and ask a human when status='unknown'. It also mandates the post-action call to continuum_complete_action, leaving no ambiguity about sequencing.

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

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

readOnlyHint=true is confirmed by 'Read-only' (consistent, no contradiction), and the description goes beyond the annotation by explaining the semantics of the 'outcome_unresolved' flag and the consequence of ignoring it before resuming. It does not cover ordering, pagination, or volume of results, which keeps it from a 5.

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

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

Three short sentences, purpose first, the key output field semantic second, the safety profile last. No filler or restated title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure needn't be described, and the one behavior an agent must understand (the unresolved-outcome flag) is explained. Minor gaps remain: result ordering/pagination and whether the list is complete or filtered are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions run_id, so nothing is added about the single required parameter or what a valid run identifier looks like. The parameter is largely self-explanatory by name, which prevents a 1, but the description makes no compensating effort for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('List external side effects recorded for a run') with a clear scope bounded by the run_id parameter. That verb alone separates it from the mutation-heavy sibling set (compensate, reconcile, confirm, fail), so an agent can pick it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the note that unresolved outcomes 'must be reconciled before resuming' hints at a pre-resume inspection workflow and indirectly at continuum_reconcile_action, but the tool is never named as an alternative and no explicit when/when-not guidance is given.

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

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.

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.

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.

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.

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.

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.

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

Annotations only declare readOnlyHint=false; the description adds the meaningful upsert behavior 'Creates the run if needed' and restates the mutation explicitly. It does not cover idempotency, overwrite semantics for existing units, or error behavior, so it adds real but not exhaustive value beyond annotations.

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

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

Purpose, call timing, payload shape, and mutation nature are all packed into four front-loaded sentences with no filler. Every sentence contributes actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need no explanation, and the mutation plus auto-create behavior is disclosed. The only real gap is the missing run_id description and unit-array overwrite semantics, which matter for a tool with 0% schema documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the units array is a bare object with additionalProperties=true, so the description carries the load by specifying the payload shape {plan_id, units:[{id,title,status,depends_on}]} and the four legal status values. It omits run_id entirely and does not explain plan_id, leaving one required parameter undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Record a structured plan milestone update') and scopes it to unit-level status tracking, which separates it from the summary/progress siblings. It stops short of naming which sibling to pick for non-unit-level progress, so it does not earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Call as you define or complete units so the run can resume with exact remaining work' plus 'One call per unit status change' gives concrete timing and call-frequency guidance. No explicit exclusion or comparison against continuum_record_progress or continuum_record_summary, so the alternative-selection guidance is missing.

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

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

Adds meaningful behavior beyond readOnlyHint=false: it is a write, it survives crashes, it creates the run on first call when 'goal' is supplied, and it is cheap enough to call frequently. The upsert-on-first-call side effect is exactly the kind of non-obvious trait an agent needs. It does not state whether repeat calls with the same completed value are idempotent or whether concurrent writers conflict.

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

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

Three short sentences, front-loaded with purpose, then the side-effect caveat, then the cost guidance. Nothing is padded and the imperative framing suits an action tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 documented, and the description covers purpose, side effects, and call cadence. However, for a 5-parameter mutation with zero schema descriptions, leaving four parameters undefined is a real completeness gap — particularly run_id, which is required and cannot be guessed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it explains only 'goal' (its role in run creation). The required 'completed' and 'run_id' plus 'total' and 'failed' are left completely unexplained — an agent cannot tell whether 'total' is a denominator for a percentage, what 'failed' counts, or how run_id is obtained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Record how far through a task you are') and clarifies the unit of work is a completed item. It does not distinguish itself from close siblings like continuum_checkpoint or continuum_record_summary, so an agent must infer the difference from the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use guidance ('Call this as you complete units of work') and a frequency policy ('Cheap: call it often'), which is unusually actionable. It stops short of naming an alternative — e.g., when to prefer continuum_checkpoint over this tool — so the routing decision against siblings remains implicit.

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

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

With only readOnlyHint=false for annotations, the description carries most of the load and does disclose persistence semantics (a fresh session inherits the state) and a hard 4096-character cap with the instruction to summarise, not dump transcripts. It doesn't say whether a new call replaces or merges with a prior summary, or what happens when the cap is exceeded.

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

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

Dense and front-loaded: purpose first, then trigger timing, then the schema sketch, then the size constraint. Every sentence earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 needn't be explained, and the state-shape guidance is strong. However, for a write tool with seven parameters, the unexplained required run_id and the opaque pinning field leave a real gap the agent must resolve by trial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the inline schema sketch genuinely explains four parameters well – plan_stack ordered current-step-first, decisions as {what, why} pairs, open_questions, and working_set as files/ids in play. But the required run_id, plus note and pinning, get no explanation at all, leaving the agent to guess how run_id is obtained and what pinning does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: record a compact summary of reasoning state so an interrupted session can resume the plan. The intent is unmistakable, but with siblings like continuum_record_progress, continuum_record_plan, and continuum_checkpoint in the same family, the description never says how this differs from those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real timing guidance: 'Call at natural checkpoints and before ending a turn,' which tells the agent when to fire it. It stops short of exclusions or alternatives – nothing says when to prefer continuum_record_progress or continuum_checkpoint instead.

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

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

The readOnlyHint annotation already declares safety, and the description reinforces 'Read-only.' It adds useful behavioral context by explaining the mode/next_allowed_action gate and the defaulting behavior when run_id is omitted.

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

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

The description is compact and front-loaded: it states the purpose, the required timing, how to interpret results, and the default run_id behavior with no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 fully documented, and the read-only annotation covers safety. However, two optional parameters remain unexplained despite 0% schema description coverage, leaving some invocation ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the key run_id omission behavior, but does not explain what env or expected_model mean or when to supply them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific purpose: asking whether it is safe to continue a run after interruption and what to do first. It clearly distinguishes the gating/resume-check role from recording or checkpoint siblings, though it does not explicitly name alternative tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear timing guidance: 'Call this BEFORE resuming work.' It also explains how to interpret the result: mode 'resume' means proceed, anything else means stop and perform 'next_allowed_action'. It lacks explicit when-not-to-use guidance or named alternatives.

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

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

Annotations already declare readOnlyHint=true, so the 'read-only' sentence is partly redundant, but the description adds real behavioral context: what invalidates results (a dependency that moved since the checkpoint). It does not describe the output on failure or how staleness is reported, though an output schema exists.

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

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

Three short sentences, front-loaded with purpose, then parameter meaning, then safety. No filler; every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values needn't be explained, and the invalidations logic is covered. However, with a required run_id and an expected_model parameter entirely unaddressed in both schema and description, an agent lacks guidance on what to pass for them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains 'env' well as a {resource: version} map, but says nothing about 'run_id' (the required param) or 'expected_model', leaving two of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Check whether saved state is still trustworthy, without changing anything.' That distinguishes it from the mutation siblings (checkpoint, record_progress, resume), though it never names an alternative directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a condition for passing 'env' and says it is 'safe to call anytime', which implies but does not state when to prefer this over siblings like continuum_confirm or continuum_resume. No explicit when/when-not guidance.

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