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

With no annotations present, the description carries the full behavioral disclosure burden. It reveals the non-obvious safe-mode constraint requiring confirm=true for AGENTS.md, explains placement behavior for section_header, and adds content policy constraints. It omits error/idempotency details, but the output schema covers return expectations.

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 with the core action and requirements, then moves to optional behavior, a conditional constraint, and content policy. Every sentence carries operational value 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?

For a mutation tool with no annotations, the description covers target files, required vs optional parameters, the conditional confirm flag, and content constraints. Output details are left to the output schema, so nothing critical blocks correct invocation, though usage-vs-alternatives guidance is only implicit.

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?

Input schema description coverage is 0%, so the description must compensate, and it does: it defines file values, marks file and content as required, explains the optional section_header behavior, and explains when confirm matters. This adds substantive meaning beyond the otherwise bare 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 description states a precise verb ('Append'), a clear target resource ('one of the persistence files'), and enumerates the allowed file values ('agents|projects|memory'). The operation is semantically distinct from read/update siblings, and the safe-mode note explicitly connects to update_persistence without blurring the purpose.

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 implies this tool is for adding content to persistence files and gives required/optional fields, but it does not explicitly say when to choose append over update_persistence or read_persistence, nor does it describe conditions for when not to use it. The safe-mode note hints at a related tool but stops short of clear alternative-selection guidance.

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 of behavioral disclosure. It clearly explains the signal mechanism (SIGTERM vs SIGKILL), the ~5s cleanup window, OS escalation, and the possible return statuses. This gives the agent a solid mental model of the tool's side effects and outcomes.

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 well-organized with a front-loaded purpose statement, bulleted escalation levels, and a concise return-value explanation. Every sentence adds meaningful information without redundancy or 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?

The description covers both parameters, the escalation behavior, and the full set of return statuses. The only minor gap is the behavior when req is null, but the schema already indicates this via the nullable type. Overall, an agent has the information needed to invoke the tool correctly.

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 thoroughly explains the force parameter, including default and recommended sequence. The run_id is only implicitly described via the 'not_found' status, but its role as the task identifier is understandable from context. Some additional detail on run_id sourcing would strengthen it.

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 and resource: 'Cancel a running task.' It clearly identifies the tool's function and differentiates it from siblings like claude_run_task, claude_start_task, and claude_poll_task by being the only cancellation operation.

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 provides explicit guidance on how to use the two escalation levels, including 'Try this first' for force=false and 'Use only if the subprocess doesn't respond' for force=true. It does not explicitly name alternative tools for selection, but the usage context is clear enough for an agent to know when cancellation is appropriate.

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 of behavior, and it delivers: it states it verifies the binary on PATH, captures --version, inspects ~/.claude.json for an OAuth token, and reports auth_status. It also defines the effect of expected_version on ok, exceeding a typical health-check disclosure.

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 logically ordered: purpose, behavior, usage timing, optional parameter, return fields. No filler sentences; every line adds necessary 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?

Given the tool's simplicity (1 optional parameter, no annotations), the description covers purpose, usage context, behavior, parameters, and return values. The output schema is said to exist, so the return field list is a bonus. An agent has everything needed to call it first and correctly.

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 add meaning. It explains the sole parameter expected_version, noting it is optional and that setting it returns ok=false on mismatch — exactly what an agent needs beyond the raw anyOf 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 description opens with a concrete verb+resource: 'Health check for the Claude Code CLI binary' and lists specific checks (PATH, --version, auth status). This clearly differentiates it from sibling task-execution tools like claude_run_task or claude_self_test.

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 instructs to call this 'as the first call in any orchestration session to validate the environment.' This provides clear context for when to invoke, though it does not name alternatives or exclusions, preventing a 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 burden and it delivers: it discloses idempotency, the no-op behavior when files exist, directory creation, the exact files written, and the effect of force. This goes well beyond a simple 'init' label.

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 statement is front-loaded, followed by a tight idempotency note and a compact optional-fields list. No sentence is 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?

For a low-complexity initialization tool with zero required parameters and an output schema, the description covers location, file names, idempotency, force behavior, and template seeding. Nothing essential for a correct call 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%, so the description must compensate. It names force and seed_templates and gives a functional meaning for each, although it leaves the null-vs-false distinction for seed_templates slightly implicit.

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?

Begins with a specific verb and resource: 'Initialize the persistence directory and seed the three markdown files' and even names AGENTS.md, PROJECTS.md, MEMORY.md. This clearly separates it from sibling persistence tools that read, append, update, or load.

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?

Provides clear usage context through the idempotency statement: re-running is a no-op unless force=true, and explains what force does. It does not explicitly compare against alternatives or state when not to use it, so it falls just short of full guidance.

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 of behavioral disclosure. It reveals ordering (newest-first, active at top), source (in-memory store), bound (Settings.max_runs), and cross-restart persistence. It does not explicitly state read-only behavior, but 'list' strongly implies that, and 'recent' is not precisely defined—minor 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?

Three sentences, all informative: the scope, the ordering/source/bound detail, and the recovery use case. The text is front-loaded and wastes no words; every sentence 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?

The description covers the main behavior, ordering, bound, and recovery workflow, and an output schema exists so return-value detail is unnecessary. It is incomplete only in omitting the optional limit parameter and not explicitly confirming that this is a read-only operation—minor for a tool that works fine with no arguments.

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 by explaining the req.limit parameter, but it never mentions it. The only bound referenced is Settings.max_runs, which is a different limit. An agent reading the description would have no idea that an optional limit parameter with default 50 exists, especially since the schema itself provides no description.

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 clear verb and resource ('List recent runs') and immediately scopes it to active plus recently completed. It distinguishes the tool from siblings by referencing claude_start_task, claude_poll_task, and claude_cancel_task for different roles, and specifies the returned ClaudeRunSummary entries with ordering.

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 explicitly states when to use this tool: 'Use this for recovery after orchestrator restart.' It goes further to explain that active async runs survive restarts and can be polled/cancelled via claude_poll_task and claude_cancel_task, guiding the complete workflow. No alternative list tool exists among siblings, so no exclusion is required.

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 burden. It discloses useful behavioral traits: returns head+tail excerpts, head_ratio is settings-controlled, and max_chars_per_file caps output. It does not directly state that the operation is non-mutating or describe failure behavior, but for a context-loading operation this is reasonably transparent.

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, front-loaded with the core purpose, and uses a clear optional-fields section. There is no filler or repetition of schema structure; every sentence adds functional value.

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 the simple optional-parameter interface, the description covers purpose, usage timing, return truncation behavior, and parameter semantics. It does not mention what happens if persistence files are missing or how this differs from claude_read_persistence, but the presence of an output schema and the startup-context guidance make this sufficiently complete for agent invocation.

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 add parameter meaning. It does: 'include' is a subset of files (agents|projects|memory), None means all three, and max_chars_per_file is a per-file character cap. It slightly defers the default to settings while the schema specifies 20000, but overall it compensates well for the schema's lack of descriptions.

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 uses a specific verb and resource: 'Load the persistence files as context for the current session.' It clearly identifies what the tool does and adds return-behavior detail, but it does not explicitly differentiate itself from the sibling claude_read_persistence, so the agent must infer the distinction from context signals.

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 clear when-to-use guidance: 'Use this at the start of each session to hydrate orchestrator memory before dispatching tasks.' However, it does not provide when-not-to-use guidance or name an alternative tool such as claude_read_persistence, so the exclusion side 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?

With no annotations provided, the description fully carries behavioral disclosure. It states that drain=false returns immediately, drain=true blocks and is bounded by the client request timeout, and it lists the return fields and terminal statuses. This is transparent about the tool's behavior.

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 well-structured with bullet points and a return section, making it easy to scan. It front-loads the core purpose and then details modes, without unnecessary 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 details are partially covered, but the description still outlines the response structure. It covers the main behavioral differences and timeout bound. Missing details like wait_seconds are minor, making it sufficiently complete for a polling tool.

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 thoroughly explains the 'drain' parameter (the core behavior) but does not mention 'wait_seconds' or the nullable 'req' field. The omission of wait_seconds leaves a partial gap in parameter understanding.

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 clearly states 'Poll an asynchronous task' with a specific verb and resource. It distinguishes itself from siblings like claude_start_task, claude_cancel_task, and claude_list_runs, leaving no ambiguity about its role.

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 explicitly describes two polling modes—drain=false for tight control loops with explicit backoff and drain=true for fire-and-wait—and advises orchestrator-level polling for long blocks. While it doesn't name alternatives directly, the mode guidance provides clear when-to-use context.

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 by disclosing line-based offset/limit behavior, automatic truncation at Settings.persistence_max_file_bytes, and the truncated flag in the response. It does not cover error handling or file-not-found behavior, but the most operationally surprising behavior is disclosed.

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?

Compact and well-structured: a one-line purpose, a short bullet list for optional parameters, and a single note about truncation. Nothing is redundant with the schema, and every sentence 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?

The description covers parameters, defaults, and truncation behavior, and an output schema exists for return-value details. It could be slightly more complete by naming sibling tools or clarifying when load_persistence_context is preferable, but nothing critical is missing for calling the tool correctly.

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 for the schema. It explains all parameters clearly: file choices and default, offset being 0-indexed, and limit accepting None for no limit. This adds real meaning beyond the raw 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 opening sentence states a specific verb and resource ('Read one of the three persistence files') and enumerates the allowed files: agents, projects, memory. It is clear, though it does not explicitly distinguish itself from the sibling claude_load_persistence_context, which may also involve reading persistence data.

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 implies when to use the tool: when raw contents of the agents, projects, or memory persistence files are needed. However, it provides no explicit when-not-to-use guidance or mention of alternatives such as load_persistence_context.

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. It discloses synchronous execution, the 600s cap, cost expectations, and the full response shape including timed_out and optional git diff, which implies workspace mutation. It does not explicitly warn about side effects or permission risks beyond mentioning permission_mode, but the disclosure is substantial.

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 purpose, then structured into required/common, cost, routing, and return sections. Every sentence adds information, and the line breaks make it scannable for an agent.

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?

Despite the rich detail, the description omits the required `req` object wrapper, which is a critical invocation detail. It also contains a factual contradiction with the schema on default and maximum timeout values. Given the tool's complexity, the undocumented advanced parameters further reduce completeness.

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 description names required and common options, but it does not mention the top-level `req` wrapper that the schema actually requires, so an agent may pass workspace_path/prompt incorrectly. Its timeout_s claim (default 300, max 600) directly contradicts the schema (default 600, max 3600), and with 0% schema coverage, many parameters (effort, max_turns, change_scope, max_budget_usd, etc.) are left unexplained.

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: 'Run a single Claude task synchronously' and explicitly notes the 600s wrapper cap. It clearly differentiates from the async sibling claude_start_task, so an agent can immediately tell this is the sync execution tool.

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 lists required and common options and gives concrete routing rules: use claude_start_task for tasks exceeding 600s, and call claude_timeout_help for timeout routing. This is exactly the when-to-use-vs-alternatives guidance an agent needs.

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 of behavioral disclosure. It clearly states that no tools are actually invoked, which is a key safety trait. It also discloses the exact argument wrapping requirement (the 'req' object) and the backwards-compatibility fallback ('args={}'), giving the agent precise calling behavior. It does not cover error handling or output format, but those are partially covered by the output schema.

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 structured with a clear purpose statement, a note on metadata-only behavior, and then the argument shape. It includes an example and a note about backwards compatibility, which are useful. It is somewhat verbose but each part contributes to understanding the tool. The key information is front-loaded with the purpose and the no-invocation note.

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 the tool has one parameter with a nested structure and no schema descriptions, the description is not fully complete. It explains the wrapper structure but does not define the meaning of 'include' or 'only_show_tolerant', which are essential for correct use. The existence of an output schema covers return values, but the parameter semantics are left underspecified, making it less than 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?

The schema has 0% description coverage, so the description must compensate. It explains the overall shape: arguments must be wrapped in a 'req' object, and it provides an example with 'include' and 'only_show_tolerant'. However, it does not explain the semantics of these fields (what 'include' filters or what 'tolerant' means), leaving some ambiguity. The example helps, but the meaning of the fields is only implied.

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 clearly states the tool's purpose: inspecting every registered tool's input schema and reporting robustness. It is specific with a verb ('inspect') and a resource ('registered tool's input schema'), and it explicitly distinguishes itself as a metadata-only check that does not invoke tools. This differentiates it from sibling tools like claude_health or claude_run_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?

The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. It implies that it is for schema inspection and robustness checking, but it does not provide guidance on when a user would prefer this over other tools. The absence of any alternative comparison leaves the agent to infer usage from the purpose alone.

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 it does well: async background execution, immediate return, timeout boundaries, and the MAX_CONCURRENT_RUNS_EXCEEDED error are all disclosed. It could go further on side effects or cleanup expectations, but the core behavioral traits are clearly stated.

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 tightly written and well structured, with the most important operational facts front-loaded. Each paragraph earns its place: async behavior, return semantics, when to use it, required parameters, and concurrency limits.

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 description covers the main async workflow and monitoring guidance well, but the tool is complex with many optional parameters and no annotations. It omits the likely synchronous alternative claude_run_task and does not clarify how to pass required fields inside the 'req' object, which is a meaningful invocation gap.

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, but it only names a subset of parameters and does not explain the required 'req' object wrapper. More importantly, it states options.timeout_s default is 300 while the schema says 600, creating a direct contradiction that could lead to incorrect invocation.

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 and resource: 'Start a Claude Code CLI task asynchronously'. It clearly distinguishes itself from siblings by emphasizing async execution, immediate return of a run_id, and the ability to run up to 3600s.

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 explicit guidance for when to use this tool: 'Use this for any task that may exceed 600s' with concrete examples. It also directs the agent to claude_poll_task and claude_cancel_task for lifecycle management. However, it does not explicitly contrast with claude_run_task, which appears to be the likely synchronous alternative.

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 it does well: it discloses the safe-mode constraint, the default mode, and the exact matched=true/matched=false return semantics including that no edit happens when the anchor is not found. It does not discuss destructive risk beyond the word 'replace' or atomicity/ordering details, but the key failure behavior is exposed.

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 primary action and uses short labeled lines for required/optional/safe-mode/return behavior. Each section adds information, though the safe-mode paragraph is slightly dense.

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 persistence tool with no annotations, it covers the essential edge cases: anchor not found, safe mode, mode default, and return signal. An output schema exists for the return shape, so not explaining all return fields is acceptable. The nested req wrapper is the main missing call-construction detail.

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 explain parameters, and it does: it defines mode's replace vs append behavior, explains when confirm=true is required, and clarifies section_anchor matching. The only gap is that it lists file/section_anchor/new_content as top-level required inputs while the schema nests them under a req object, which could confuse an agent constructing the call.

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: 'Replace or append to a section in one of the persistence files.' This clearly conveys the tool's core operation. It does not explicitly distinguish itself from the sibling claude_append_persistence, but the mode parameter partially covers that overlap.

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 lists required and optional parameters and explains the safe-mode confirm condition, which is actionable guidance. However, it does not say when to prefer this tool over claude_append_persistence or other persistence tools; the alternative routing is left implicit.

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