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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful semantic context about local-supervised and the mandatory full-diff Claude review, but it does not describe the tool's own output behavior or other classification criteria in a way that goes substantially beyond the 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?

Two compact sentences with no filler. The category list is front-loaded, and the key term local-supervised is immediately clarified with a consequential constraint. 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?

There is no output schema, so the description should explain what the tool returns or how the classification is expressed, but it does not. Only one of the four categories is defined, leaving deterministic, local, and Claude ambiguous. With 8 parameters, 13% schema coverage, and many related sibling tools, the description is not complete enough for reliable 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 only 13%, so the description carries most of the burden for explaining the 8 parameters. It does not explain task, riskTags, solutionKnown, estimatedFiles, validationKnown, requiresDiscovery, requiresArchitecture, or sensitiveDecisionResolved. The description only indirectly relates to sensitiveDecisionResolved through the local-supervised definition, which is insufficient for an agent to set parameters correctly.

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 categorizes a coding task as deterministic, local, local-supervised, or Claude, and it defines the local-supervised category. It does not explicitly differentiate itself from the sibling execution tools, but its role as a classifier is evident from the title and categories.

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 a routing/classification step for local code tasks and explains when local-supervised applies, but it never explicitly says when to use this tool versus execute_local_code_task, delegate_code_task, or other siblings. The 'full-diff Claude review is mandatory' note provides some routing consequence, but no direct 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'without modifying repository files' reinforces rather than adds behavior. It does contribute the useful detail that this delegates to a 'fast local model' and returns 'bounded' text, but does not explain output size, response structure, or failure 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?

One sentence, front-loaded with the core action and read-only guarantee, with no wasted words. It is concise and easy to parse, though the brevity contributes to the parameter-semantics gap.

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 tool with no output schema, 0% parameter coverage, and several closely related siblings, a single sentence is not enough. The description covers purpose and safety, but omits how the response is shaped, how output/context/language/constraints interact, and when the read-only delegation should be preferred over alternatives.

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?

With schema description coverage at 0% and five parameters, the description was expected to compensate, but it offers no per-parameter guidance. Words like 'code/analysis' hint at the output enum and 'bounded' hints at constraints, but task, context, language, and constraints are left entirely to the agent's inference from names alone.

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 action ('Ask the fast local model') and a clear outcome ('bounded code/analysis text') while explicitly noting it does not modify repository files. This distinguishes it from execution-oriented siblings like execute_local_code_task, though it could be even sharper about what 'bounded text' means.

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 'without modifying repository files' implicitly signals this is the read-only counterpart to execution tools, but it does not explicitly state when to choose this tool over local_coder_health, classify_local_code_task, or execute_local_code_* variants. Usage context is present but mostly inferred.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by stating the tool does not follow symlinks and produces a bounded view, which is behavioral context not present in annotations. However, it does not describe the output structure, though output schema is absent.

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 a single, well-structured sentence that front-loads the core action and carries no filler. It conveys scoping and exclusion in minimal words, earning 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?

Given the complexity of four parameters (one required) and no output schema, the description is incomplete. It fails to explain parameter roles, return format, or any usage examples. While annotations cover safety, the lack of parameter semantics leaves a significant gap for correct 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 compensate for the absence of parameter documentation. It does not mention any of the four parameters (workspace, maxDepth, extensions, maxEntries) or explain their meaning, defaults, or constraints. An agent cannot infer how to set these parameters correctly from the description alone.

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 lists a bounded safe workspace view and root package scripts, with an explicit exclusion of symlink following. This is a specific verb-resource pair that distinguishes it from siblings like search_local_workspace, which implies searching rather than simple listing.

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 the tool is for initial exploration ('discover', 'bounded'), but it provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or conditions for choosing this over sibling tools like search_local_workspace or execute_local_code_task. Usage context is only 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds behavioral context about full-result orchestration, local supervision, and adaptive fast-to-strong retry, but it does not disclose what destructive impact occurs (workspace edits, rollback behavior, failure consequences) beyond the annotation.

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 a single compact sentence with no filler, and the routing guidance is placed at the end. The phrases are dense and somewhat jargon-heavy, but the overall length and structure are appropriately concise for a tool with a rich schema.

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 complex, destructive, 9-parameter orchestrator with no output schema, the description is too thin. It omits when to use this plan-level tool versus task-level siblings, how failures or retries behave, what 'full-result' means, and what the caller should expect after execution.

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 top-level parameters, so the description must compensate by explaining goal, tasks, workspace, or the orchestrator's parameter relationships. It does not mention any parameter names or meanings, leaving all nine parameters effectively undocumented from the description's perspective.

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 title 'Execute Large Feature Plan Locally' gives the primary action, and the description adds that it is an 'orchestrator' supporting subtasks and retries. However, the opening phrase 'Compatibility full-result orchestrator' is jargon-heavy and does not clearly state what the tool actually does from the description alone.

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 a clear routing signal by saying to 'prefer the compact orchestrator for enforced review behavior,' and it indicates this tool is the compatibility/full-result variant. It does not explicitly contrast with execute_local_code_task or delegate_code_task, but the compact-orchestrator exclusion is useful and concrete.

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 annotations' destructive flag, the description adds a meaningful behavioral rule: already-resolved sensitive subtasks can run as local-supervised, and any such task forces full aggregate-diff review by Claude. This helps the agent anticipate a mandatory review step and the special handling of sensitive subtasks.

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 two sentences with no filler. The purpose is front-loaded, and the behavioral caveat about sensitive subtasks is placed second, keeping the most important routing information visible.

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 complex orchestrator with nested task objects, routing flags, validation commands, and rollback behavior, this description is too sparse. The input schema property names carry some meaning, but the description does not explain return behavior, task structure, or failure handling, and there is no output schema to fill the 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?

With 0% schema description coverage on 9 parameters, the description should compensate for missing parameter documentation, but it only vaguely alludes to sensitive subtasks and review. It gives no guidance on constructing tasks, editableFiles, validation, rollbackPlanOnFailure, or the routing subfields.

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 identifies the tool as a large-feature orchestrator and clarifies that Claude owns planning/decomposition, which distinguishes it from single-task tools like execute_local_code_task. However, it does not explicitly differentiate itself from the closely related execute_local_code_plan or execute_local_code_plan_compact variants.

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 clear context that this is the preferred choice for large features and that Claude handles planning, so when to use it is implied. But it never names alternatives like execute_local_code_plan or says when the non-compact version should be preferred 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?

Annotations already indicate this is a destructive operation, but the description adds no behavioral detail about what gets modified, whether rollback is possible, or what side effects may occur. The contrast with the compact version implies missing safety features, but this is not explicitly 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?

The description is extremely compact with only two sentences and no filler. The purpose is front-loaded and the alternative is named immediately, but the first sentence is cryptic enough to reduce clarity.

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 destructive tool with 10 parameters and no output schema, this description is drastically incomplete. It omits return behavior, file modification semantics, retry/rollback behavior, validation execution details, and any usage conditions. The agent cannot safely invoke this tool based on the description alone.

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 adds no meaning for any of the 10 parameters. Critical parameters like editableFiles, rollbackOnFailure, validation, constraints, and maxAttempts are entirely unexplained, leaving the agent to guess their semantics.

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 title and description make clear the tool executes code tasks locally, and the phrase 'Compatibility full-result executor' distinguishes it from its compact sibling at a high level. However, 'compatibility full-result executor' is jargon and does not precisely explain what the tool does or what 'full-result' means.

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 says to prefer execute_local_code_task_compact and gives concrete reasons: routing preflight, adaptive fast-to-strong retry, and supervised-sensitive review enforcement. It does not, however, state the specific conditions under which this compatibility version should be used 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?

It adds meaningful behavioral context beyond annotations: self-preflighting of routing, a 'bounded' execution model, and the requirement that supervised runs force full-diff Claude review. This gives an agent actionable expectations about control flow and review processes, which the annotations' destructiveHint alone does not provide.

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 two dense sentences with no filler. However, jargon like 'preflights routing' is introduced without elaboration, slightly reducing clarity. Overall it remains appropriately sized and front-loaded with its identity as a preferred bounded executor.

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?

With 11 params, nested routing and validation objects, no output schema, and a destructive profile, a two-sentence description is insufficient. It omits return behavior, the meaning of 'bounded', rollback/attempt defaults, and how the routing object should be populated, leaving significant operational gaps.

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 does not compensate by explaining key parameters like task, workspace, editableFiles, validation, or routing fields. It only alludes to 'sensitive decision' and 'routing' implicitly, leaving required pins undefined.

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 identifies the tool as a 'bounded local executor' that 'preflights routing itself,' which conveys the core function of executing local code with built-in routing. It distinguishes itself as 'preferred' and 'compact' among siblings, though it does not explicitly contrast with execute_local_code_task or execute_local_code_plan_compact.

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 offers partial guidance: it is 'preferred' and sensitive auth/credential work requires Claude to 'explicitly resolve the sensitive decision' before supervised execution. However, it does not state when to choose this tool over its many siblings, nor any exclusions or alternative conditions.

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 cover read-only and idempotent behavior, and the description adds valuable context: lazy retrieval, incremental paging via offset/maxChars, and a caution about context size. No contradiction with annotations; this is exactly the kind of behavioral context agents need beyond structured hints.

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 sentences with no filler. The core purpose is front-loaded, followed by operational guidance. 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?

For a read-only retrieval tool with four simple parameters and no output schema, the description covers purpose, when to use, and how to retrieve incrementally. It doesn't describe the exact return shape, but the named views imply result kinds, and annotations cover safety. The only minor gap is where runId originates, which is reasonably inferable from sibling context.

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 it does by explaining the meaning of view (summary/diff/validation/full) and the role of offset/maxChars for incremental loading. It doesn't restate defaults or constraints (schema has them), but it maps parameters to an intended usage pattern. runId is contextually obvious as the identifier of the stored run.

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 ('Fetch') and resource ('stored local execution result'), and the title adds 'Lazily'. The description clearly distinguishes this retrieval tool from the execute_* siblings by emphasizing incremental detail fetching rather than execution.

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?

Tells the agent when to call it ('only when Claude needs more detail') and prescribes a sequence ('Prefer summary first'), plus warns against loading a large result at once. It doesn't name sibling tools as alternatives, but the when and how guidance is clear enough to select this tool.

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 and idempotentHint=true, reducing the need to restate safety. The description adds useful scoping about connectivity and model availability, but does not clarify whether local state is queried or what 'resource settings' means. No contradiction with 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?

A single sentence with no filler and a front-loaded verb and subject. It efficiently lists the checked dimensions without redundancy or unnecessary detail.

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 zero-parameter health check with strong annotations, the description is largely complete: an agent knows what is being checked and that it is safe/idempotent. Minor gaps are the lack of return-value description and the slightly ambiguous 'resource settings' wording, but these are low-risk for a simple health-check call.

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 documentation burden. Schema coverage is effectively 100% and the description adds no further parameter detail because none is needed.

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 a specific verb ('Check') and concrete resources: Ollama connectivity, adaptive model availability, and resource settings. It is distinguishable from the execution/workspace siblings, though it does not explicitly distinguish itself from the similarly named local_coder_telemetry.

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 guidance is provided about when to choose this tool over alternatives such as local_coder_telemetry or when a health check is prerequisite to other operations. The intended usage is only implicitly derivable from the description's function.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about privacy preservation and exact per-model usage, but it does not disclose operational behaviors such as whether the data is cached, how freshness behaves, or what aggregation period is used beyond the implicit 'days' parameter.

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 a single, focused sentence that front-loads the key concept (aggregation of telemetry) and then specifies the notable detail (per-model Ollama inference usage). There is no redundant wording 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?

For a read-only telemetry tool with no output schema, the description explains the data scope well but omits the 'days' parameter and any indication of the return format (e.g., summary stats, time series, per-model breakdowns). Given the low complexity and strong annotations, the description is adequate but leaves the aggregation window and output shape to be inferred.

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 does not mention the 'days' parameter at all. The parameter itself is inferable from its name and constraints (default 30, max 3650), but the description leaves the aggregation window entirely implicit, which is a notable gap for a single-parameter tool.

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 ('Aggregate') and clearly identifies the resource: privacy-preserving routing/execution/orchestration telemetry, including exact per-model Ollama inference usage. This distinguishes it from sibling tools like local_coder_health or get_local_run, though it does not explicitly name any 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?

No guidance is provided on when to use this tool versus alternatives such as local_coder_health or get_local_run. The description implies a telemetry/aggregation use case but does not state conditions, exclusions, or preferred 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: it relies on a persistent local index (which may be stale) and explicitly warns that cited file:line evidence should be verified, indicating the output is not authoritative on its own.

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 sentences, no filler. The core function is front-loaded, and the usage guidance and verification caveat are each one clause, earning their 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 what the tool does and when to prefer it, but with no output schema and five underdocumented parameters, an agent still lacks a clear picture of the returned 'context capsule' structure and how to fine-tune it. It is adequate for a high-level selection decision but not fully complete for confident 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 carries the burden of explaining parameters. It only implies size limits through the word 'compact' and does not clarify the semantics of 'hints', 'maxFiles', 'maxCharsPerFile', or how 'workspace' and 'task' interact with the index. This leaves significant ambiguity for an agent selecting parameter values.

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 ('Build') and describes a concrete resource ('compact evidence-first context capsule') plus the mechanism ('persistent local repository index'). It clearly separates this tool from the execute/search/delegate siblings by framing its output as context preparation rather than task execution or discovery.

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 says to prefer this tool before broad Claude file exploration, and to use it for architectural or risky decisions where file:line evidence must be verified. It provides clear context and timing, though it does not name specific sibling tools or state explicit exclusions.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by labeling the search as 'literal' and 'bounded,' which suggests exact text matching and enforced limits, though it does not explain the concrete bound or return 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 entire description is a single front-loaded sentence with no filler or repetition. It is efficient, though it achieves this by leaving parameter-level detail to the schema.

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 six-parameter tool with no output schema and no parameter descriptions, the one-line description is minimally adequate: the field names and defaults clarify many optional parameters. However, it does not define 'literal' (e.g., case sensitivity), specify what 'bounded' limits, or indicate the result format, so an agent still has notable gaps when invoking it.

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 carries the full burden of explaining the six parameters, but it only loosely implies query and workspace. It never mentions maxDepth, maxFiles, extensions, or maxResults, leaving their semantics to the schema field names and constraints.

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 ('search') and resource ('local workspace'), and 'literal bounded' clarifies the scope as exact-match and limited. It is distinguishable from execute/delegate siblings, but it does not explicitly contrast with the closely related discover_local_workspace, so the differentiation is left implicit.

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 'inside a safe workspace' implies a constrained read-only environment, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not name sibling alternatives such as discover_local_workspace or execute_local_code_task, so an agent must infer that this is for simple lookups rather than discovery or execution.

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