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

With no annotations, the description carries the full burden, and it does unusually well: it discloses that running cancellation blocks until worker process tree termination is confirmed (a non-obvious synchronous behavior) and clarifies that a 'completed' status reflects only invocation/report normalization, not master-agent acceptance. Idempotency, behavior on already-terminal tasks, and permission requirements remain undisclosed.

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 action and scope are front-loaded in the first sentence, and the subsequent sentences about blocking behavior and result semantics each carry real information. The master-agent 'PASS' caveat is slightly tangential to invoking this specific tool but is not wasted given the result ambiguity it resolves.

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 explained, yet the description goes further and disambiguates the 'completed' status, which is the main interpretive hazard for this tool. Combined with the blocking-termination disclosure, it is nearly complete; prerequisites and failure modes are the only notable omissions.

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 single parameter task_id is never mentioned in the description, so no meaning is added beyond the property name. The name is largely self-explanatory, which keeps this at baseline rather than below it, but the description does not say where the id comes from or its expected format.

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 first sentence states a specific verb (cancel) and resource (task) plus the scope ('queued or running'), and no sibling tool offers cancellation, so an agent can route to it unambiguously. This is a clean verb+resource+state statement.

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 implied by the scope qualifier ('queued or running'), which tells the agent the tool is valid for tasks in either state, but there is no explicit when-to-use guidance, no statement about what happens if the task is already finished, and no reference to alternatives such as zcode_status or zcode_continue for inspecting tasks.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the downstream effect on future tasks, but says nothing about whether the change is reversible, whether it errors when no Bridge default is set, or what permissions it requires for a mutating operation.

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?

A single sentence that front-loads the action and then the effect, with no filler or redundancy. Every clause earns its place.

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 zero-param schema is fully described. The only shortfall is the absent behavioral detail around the mutation itself, which leaves a minor gap for an agent about to clear state.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline for a parameterless tool applies. No parameter-related gap exists.

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 (Remove), the exact resource (Bridge default model), and the concrete consequence of the operation. It is trivially distinguishable from zcode_set_default_model and zcode_default_model, which set or read the model rather than clearing it.

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 explains the condition under which clearing is useful: future tasks lacking an explicit zcode_task.model will fall back to the ZCode session default. It gives clear usage context but names no alternative (e.g., zcode_set_default_model) nor any when-not-to-use caveat.

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 no annotations, the description carries the full burden and does so admirably: it discloses side effects (attempt increment, evidence preservation), an authority rule (a ZCode-flagged decision is never auto-approved and requires a master follow-up instruction), and critically redefines status 'completed' as invocation/report completion rather than work acceptance. It also instructs independent review of the diff and checks.

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 dense but front-loaded, leading with the core action and mechanics before the caveats. Every sentence carries a distinct obligation (mechanics, preconditions, auto-approval rule, status semantics), though the status-semantics passage is on the longer side.

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 still adds the essential status-semantics caveat that the schema cannot express. Preconditions and authority handling are covered; only the third parameter remains unexplained.

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 all 3 parameters, so the description must compensate. It conveys that task_id is the reused identifier and feedback is the master's follow-up instruction, but additional_requirements is neither described nor hinted at, leaving one parameter fully 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 description gives a specific verb+resource ('continue a finished task') and enumerates the concrete mechanics that define this operation: reuse of task ID and workspace, attempt increment, and evidence preservation. This clearly distinguishes it from zcode_task (starting new work) without needing to name the sibling.

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 states the precise precondition set — allowed from completed, failed, or waiting_for_master — which tells the agent exactly when invocation is legal. It stops short of naming an alternative tool for the disallowed cases (e.g., what to call when a task is still running), so it is strong context without full when-not routing.

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?

No annotations are provided, so the description carries the disclosure burden, but for a zero-parameter read operation the safety surface is small. It states what is returned but does not say what happens when no default has been set or whether any permission is needed, leaving modest gaps.

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?

A single front-loaded sentence that names the returned fields and the condition under which they apply. Every clause earns its place, with zero 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-value explanation is unnecessary, and with no parameters the call surface is trivial. The only minor omission is the edge case of no default model being configured (null vs. error), which an agent might want to know.

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?

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a no-param tool is 4. The description correctly frames the call as requiring no input.

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?

Specific verb+resource: 'Read the provider, model, and optional reasoning level' for the bridge default model. It even scopes the resource semantically ('used when zcode_task has no model override'), which distinguishes it from siblings like zcode_set_default_model, zcode_clear_default_model, and zcode_model_catalog.

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 phrase 'used when zcode_task has no model override' implies the context of use (inspecting the fallback model), but the description never states explicitly when an agent should call this versus sibling read tools such as zcode_model_catalog or zcode_status, nor any preconditions.

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 no annotations, the description carries the burden and does well: it declares the read-only nature, explicitly states it does not start a ZCode session, and discloses that app-server model availability and real permission approval remain unverified until a task runs. It omits any note on permissions or runtime cost, but the core behavioral profile is clear.

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 tight sentences, front-loaded with the check scope, followed by the scope exclusion and the verification caveat. Each sentence adds distinct information with no waste.

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 explained. For a no-param read-only diagnostic, the description covers what is checked, what is deliberately not done, and the limits of the results. Only the tie-break against similar diagnostic siblings like zcode_status is missing.

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?

Zero parameters, so the baseline applies; there is nothing parameter-level for the description to add. The 100% schema coverage is trivially satisfied by an empty object.

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 (run read-only checks) plus a concrete resource scope: Bridge prerequisites, ZCode runtime/provider config, execution mode, task storage, and Desktop task-index availability. It explicitly negates the adjacent session-starting behavior, distinguishing it from siblings like zcode_task.

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?

Implies pre-flight/diagnostic usage by enumerating prerequisite checks and excluding session start, but never names an alternative (e.g., when to prefer zcode_status) or states the conditions under which this tool should be chosen. Usage is inferable rather than 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?

With no annotations, the description carries the full burden and does well: it discloses that raw is the default view, that summary merges adjacent model-text chunks, that next_seq advances across all scanned events, that hidden reasoning is excluded, and that interaction_requested events include bounded detail. It does not state read-only nature, error behavior, or what limit does under the hood.

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 is front-loaded, but the middle is dense and mixes tool semantics with agent workflow instructions ('report the project path... report the ZCode session...'). It is information-rich but longer than needed and not tightly scoped to describing the tool itself.

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-value explanation is not required, and the description focuses on how to page and poll. Given the 5-param, no-annotation surface, it gives the agent enough to call and drive the tool correctly, aside from the undocumented limit parameter.

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 and largely does: view (summary merges chunks; raw default), after_seq (last next_seq), and wait_ms (up to 25000) are all explained. limit is never mentioned, and task_id is left to the pattern in the schema.

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 first sentence gives a specific verb+resource: 'Read persisted progress events for a task.' That is unambiguous. However, it does not distinguish itself from close siblings like zcode_progress_probe, zcode_status, or zcode_result, leaving the agent to infer which read path to use.

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?

Strong operational guidance: set after_seq to the last next_seq, keep polling until turn_started or startup failure, wait_ms up to 25000. This tells the agent how to drive the polling loop. It does not, however, name an alternative sibling or state when NOT to use this tool in favor of zcode_progress_probe/zcode_status.

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 no annotations, the description carries the full burden and does disclose key policy behavior (what authorizes an allow, what must not be treated as authorization, and that this does not approve the task result). It stops short of describing the effect of replying (does the task resume, is the decision final/irreversible) or any auth requirements.

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 core action and the trail back to zcode_events, then layered policy constraints in short declarative sentences. No filler and no repetition of the title or name.

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?

No output schema, so the description needn't explain returns, but for a 5-parameter tool with 0% schema coverage it leaves request_id/task_id sourcing and the reason/answers fields entirely unexplained. The decision-policy side is well covered; the mechanical side is 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 coverage is 0%, so the description must compensate. It implicitly maps the decision enum to request types (allow/deny for permission requests, answer for input requests), which is genuinely useful, but it never addresses task_id, request_id, reason, or how the nested answers object is keyed.

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 (reply) and resource (a pending ZCode permission or user-input request) and ties the request back to the sibling tool that surfaces it, zcode_events. It also draws a boundary against another sibling by noting it 'does not approve the task result.' An agent can distinguish this from zcode_result or zcode_continue without opening a 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?

Gives explicit when/when-not rules: use allow only when the user explicitly authorized the action, otherwise deny or ask; do not infer permission from task instructions, worktree use, or ZCode mode; for input requests, answer only from known facts or explicit user direction. These are directly actionable decision constraints.

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 no annotations, the description carries the behavioral burden well: it discloses the 24-hour cache lifetime, refresh triggers (provider settings change or cache expiry), the retry behavior (re-reads provider config), and a specific response-shape quirk (current_model=null on cache responses). These are non-obvious operational details that meaningfully help correct invocation. It stops short of stating rate limits or full error semantics.

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 front-loaded with the core action and then layers in cache/refresh behavior and a response hint. Three sentences, each carrying distinct operational information with 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?

Given a single-parameter read tool with an output schema, the description covers cache semantics, refresh triggers, retry behavior, and a response-shape edge case (current_model=null). This is substantial for a tool of this complexity; only explicit when-to-use guidance is missing.

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 the single `workspace` parameter, but the description implies the catalog is workspace-scoped ("for this workspace"). The description provides contextual meaning for the parameter even though it does not document its format or constraints; baseline 3 is appropriate given the minimal parameter surface.

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 ("Read") and resource ("models and reasoning levels") for the workspace, which clearly distinguishes it from state-mutating siblings like zcode_set_default_model or zcode_clear_default_model. It could better differentiate from zcode_default_model, which likely returns the current default, but the catalog scope is reasonably clear.

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?

No explicit when-to-use or when-not-to-use guidance is provided, nor are any sibling tools named as alternatives. The agent must infer that this is called to discover available models before, e.g., selecting one via zcode_set_default_model.

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 no annotations provided, the description carries the full burden and does well: it declares itself read-only, states the runtime (three seconds), the number of notifications emitted, and that it does not start or modify a ZCode task. It does not describe the return payload, but for a disposable probe this is minor.

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 tight sentences with zero padding, and the read-only/experimental nature is front-loaded so an agent immediately knows the safety profile.

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?

A zero-parameter, no-output-schema diagnostic whose full behavior and scope are captured in the description. Nothing needed to invoke it correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level gaps exist.

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 (sends three MCP progress notifications over three seconds) and its purpose (test whether the host displays server progress). It explicitly distinguishes itself from siblings that start or modify ZCode tasks, so an agent can tell it apart from zcode_task or zcode_continue without inspecting 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?

The description conveys context (a temporary experiment to probe host progress rendering) and an explicit exclusion: it does not start or modify a task. It does not state when-not to use it relative to named alternatives, but there is effectively no competing sibling for this diagnostic role.

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 no annotations provided, the description carries the full burden and does so: it discloses the TASK_NOT_FINISHED error condition, the exact meaning of status 'completed' (invocation and report normalization finished, not master acceptance), and that files_changed/tests/decisions are unverified normalized claims. This is unusually rich behavioral disclosure for a read tool.

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 core action and terminal-state gating, and most sentences earn their place. However, the 'completed is not a master-accepted PASS' warning is restated twice in near-identical phrasing, which is mild redundancy.

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 single-parameter read tool with an output schema (which already documents the return shape), the description supplies everything else an agent needs: when it succeeds, when it errors, and how to interpret the result fields. Given no annotations, this is 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 coverage is 0% and the single parameter (task_id) is never mentioned in the description, so nothing explains where the id comes from, its accepted format, or whether it references a task handle returned elsewhere. For a 1-param schema with no documentation, the description fails to compensate.

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 ('Read the persisted TaskResult') and scopes it to a 'finished task' / terminal state, which separates it from status-, events-, and progress-oriented siblings. An agent can identify the retrieval role 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?

Gives clear context for use: only meaningful after the task reaches a terminal state, and it explicitly notes it returns TASK_NOT_FINISHED otherwise. It also warns the caller to verify independently. It does not name an alternative tool for the pre-terminal case (e.g., zcode_status or zcode_progress_probe), so it stops short of full when/when-not routing.

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 no annotations, the description carries the burden and does disclose real behavior: the selection is persisted, validated by the app-server only when a task starts, reasoning_level attaches to the configured default, and per-task overrides win. It omits any note on permissions, reversibility, or failure behavior, keeping it below 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 tight sentences, front-loaded with the core action, and each sentence adds distinct information (scope, ID source/validation, reasoning_level and override). No filler or repetition of the tool name.

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 described, and the description covers persistence, validation timing, and override precedence for a mutation tool lacking annotations. The main remaining gap is the absence of valid reasoning_level values.

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 points provider_id/model_id at zcode_model_catalog or configured rules and explains that reasoning_level applies to the configured default, but it gives no accepted values or format hints for reasoning_level, leaving a gap for one of three parameters.

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 ('Persist a default provider/model selection') and scopes it to 'future tasks that omit zcode_task.model'. It is readily distinguishable from siblings zcode_default_model (read) and zcode_clear_default_model (clear), and it names zcode_model_catalog as the ID source.

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?

Explains when the setting takes effect (tasks that omit zcode_task.model) and that a per-task selection can still override it, which implicitly frames when this tool is and isn't needed. It never explicitly contrasts itself with the sibling read/clear tools, so it stays at 4 rather than 5.

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 no annotations, the description carries the full burden and does so well: it defines the semantics of 'completed' (invocation and report normalization finished, not master-agent acceptance) and clarifies the absence of PASS/FAIL data. It does not mention read-only/permission requirements or pagination, but the semantic warnings are the higher-value disclosure here.

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?

Four sentences, all front-loaded around the core semantics, with no filler. Each sentence earns its place by disambiguating status from judgment, though the final sentence about the master agent is somewhat ceremonial.

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 need not be explained, and the description instead supplies the interpretation guidance an agent needs to avoid misreading 'completed' as acceptance. Given the single trivial parameter and available output schema, this is close to complete; only task_id provenance is unaddressed.

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?

There is a single required parameter, task_id, and schema description coverage is 0%, so the description adds no format, sourcing, or constraint detail for it. The name is largely self-explanatory, keeping this at a baseline 3 rather than lower.

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 opens with a specific verb+resource ('Read the execution status record for one task') and immediately scopes what the record is not ('execution status only and never contains a PASS/FAIL code-review judgment'). That implicitly separates it from the sibling zcode_result, though it never names a sibling 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?

Usage is implied through the contrast with code-review judgment and the note that the master agent must independently review the diff, which hints at when this tool is appropriate. However, it never states an explicit when-to-use or when-not-to-use condition, nor names an alternative tool such as zcode_result for retrieving review 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?

With no annotations, the description carries the full burden and does so well: it discloses async detached execution, that a TaskReceipt is returned immediately, that 'completed' means only invocation/report normalization finished and NOT master-agent acceptance, and that the master must independently review the diff and checks. These are exactly the non-obvious behavioral traits 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?

It is longer than typical but front-loaded, with the core purpose first and the critical 'completed ≠ accepted' caveat near the end. Nearly every sentence carries load (worktree rules, model scoping, async semantics), though the worktree/Bridge point is stated twice.

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 12-parameter mutation tool with no annotations, it covers the highest-risk aspects: worktree ownership, model scoping, and result interpretation. An output schema exists, so return-value detail is not required, yet it still clarifies the receipt's meaning. The gap is the unexplained bulk of array/scalar task-package parameters.

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% across 12 parameters, so the description must compensate and only partly does: it explains workspace, worktree_path, and the nested model object's effect. It says nothing about task_id's pattern, requirements, allowed_paths/forbidden_paths semantics, acceptance_criteria, test_commands, timeout_ms, or context, leaving most parameters 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?

The first sentence names a specific verb and resource — 'Create a bounded coding task' — and identifies the actor ('local ZCode subordinate agent'). This cleanly separates it from siblings like zcode_continue, zcode_cancel, and zcode_result, which operate on tasks that already exist.

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 gives concrete conditional guidance: decide whether to create a worktree, pass its existing absolute directory as worktree_path, and if omitted ZCode runs in workspace. It also clarifies that the Bridge never creates/selects worktrees and that model only affects the session. It stops short of explicitly naming when to prefer a sibling (e.g., continue vs a new task).

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