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

Goes well beyond the annotations, which only say readOnly=false, destructive=false, idempotent=false. The description discloses that output is a two-line receipt rather than code, that generated content never enters context, that missing directories are created, and that failure on an existing target happens BEFORE generation. That ordering detail is genuinely useful behavioral context.

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-loads the key constraint with bold emphasis, and the Args block is tight and scannable. The 'that is where the saving is' sentence is slightly rhetorical but does justify why target is required, so it roughly 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?

A mutation tool with a schema, annotations, and an output schema. The description covers the write behavior, the receipt-only return, directory creation, and overwrite failure ordering, so an agent can call it correctly with no further inference.

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 and does so: it defines spec, language, target (absolute path, missing dirs created), and overwrite (default failure semantics and pre-generation check). That is a complete contract for all four 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 (generates), a specific resource (boilerplate code), and names the mechanism (a local code model), which cleanly separates it from siblings like local_translate or local_summarize. An agent knows exactly what this tool produces 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?

The description explains the rationale for `target` being mandatory and tells the agent to open the file to see the code, which implies the intended workflow. However, it never states when to choose this over alternatives such as local_delegate, nor any 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 and openWorldHint=false, which the phrase 'with a local model' reinforces consistently. The description adds the useful output contract ('returns exactly one label... with no additional text'), though an output schema exists, so this is partially redundant.

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-loads the purpose, then the return contract, then the args — no wasted sentences. The return statement is slightly redundant given an output schema exists.

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 simple two-parameter read-only classification tool with an output schema present, the description covers purpose, return shape, and both parameters. Only the missing when-to-use guidance against siblings keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden; it does list both args and glosses them ('text: Text to classify', 'labels: List of candidate labels'). However it adds no format guidance beyond the schema types, e.g. whether labels must be unique or non-empty.

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 (classifies) and resource (text) plus the constraint that output is ONE of the provided labels, using a local model. It does not explicitly differentiate itself from siblings like local_extract or local_summarize, though the label-constrained framing is distinctive enough to infer.

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 statement of when to pick this tool over the ten sibling local_* tools, and no exclusions or prerequisites. The agent must infer usage entirely from the name and purpose sentence.

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 openWorldHint=false, and the description adds genuinely new context: the file is read server-side so the diff never enters Claude's context, and the output must always be reviewed. It does not describe latency/quality limits of the local model, but with these annotations this is strong.

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 PREFER routing rule, then the action, then the args list. Every sentence earns its place; slightly long but no filler.

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

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

An output schema exists, so return values need no explanation. Combined with routing guidance, both input modes, the style options, and the review caution, an agent has everything needed to invoke it 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% and the schema has no enum, so the description carries the whole burden — and it does: diff is text, path is a server-read file (mutually exclusive with diff), and style takes 'conventional' or 'plain', an enum the schema itself lacks.

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: drafts a commit message from a diff using a local code model. It also names what it is not (a way to read contents), so an agent can separate it from local_summarize / local_explain_code without opening the schema.

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

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

Explicitly says PREFER this over reading the file with Read when the file is large (>200 lines / >10 KB) and only a commit message is needed. Names the alternative tool and the exact condition that selects this one, plus a review-before-use rule.

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

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

Annotations only cover readOnlyHint/openWorldHint; the description goes well beyond them by disclosing the chunking algorithm (splits at Markdown headers/paragraphs), the ordering guarantee (concatenates outputs in order), and the concrete failure mode (a long input may come back truncated with chunk='off'). That is the exact behavioral context an agent needs before invoking.

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 one-line purpose, then a usage paragraph, then a compact Args block; every section does work. It is slightly longer than strictly necessary (the Args list restates parameter names), but given 0% schema coverage that repetition is functional rather than padding.

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

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

Output schema exists, so return-value explanation is correctly omitted. For a 5-parameter tool with no schema descriptions and no enum metadata, the description supplies chunking behavior, truncation risk, model default, and sibling routing — nothing an agent needs to call 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?

Schema description coverage is 0%, so the description carries the full burden, and it does: task is defined as a one-sentence instruction with an explicit output format, input as the content, output_format as the exact expected format, model's default and provenance, and chunk's three enum values are each given semantics. This fully compensates for the empty schema 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 first line states a specific verb and resource ('delegates a text->text task to a local model') and explicitly frames itself as the generic fallback ('escape tool'). It also names a sibling (local_summarize) and the condition that routes away from it, so an agent can place it against the ten other local_* tools without opening schemas.

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

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

Gives explicit when-to-use ('when no specific tool fits'), explicit when-not (reduction tasks over the whole text: counting, maximum, single global summary), and names both escapes: pass chunk='off' or use local_summarize. The chunk mode tradeoff (correct for transforms, wrong for reductions) is spelled out rather than implied.

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 openWorldHint=false, but the description adds critical behavior the annotations cannot convey: the image is read server-side and NEVER enters Claude's context, only the text answer returns, and it never generates/edits images. This context-channel disclosure is exactly the kind of trait structured fields can't express.

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-loads the most decision-relevant guidance (the PREFER clause) and then explains mechanics and scope. Efficient overall, though the preamble plus separate scope-guardrail sentence is slightly redundant and could be tightened.

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 an output schema present, return values need not be described, and the description fully covers the input channel, scope, and when-to-use. Nothing an agent needs to select and invoke this tool 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?

Schema description coverage is 0%, so the description must compensate, and it documents all three parameters with added meaning: accepted formats (png/jpg/jpeg/webp/gif) for path, the optional/default behavior of question, and the semantic of max_words. It does not restate the numeric default (200) or the null default, which remain 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?

States a specific verb+resource ('Describes an image or answers a question about it with a local vision model') and explicitly bounds scope with a guardrail ('ONLY image->text... NEVER generates or edits images'). Though the sibling tools (local_summarize, local_translate, etc.) are not image-oriented, the description still makes the image->text boundary unambiguous.

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 says when to prefer this tool ('over attaching or reading the image yourself when you only need a description, the visible text... or a specific answer') and when not to (when you need the image itself in context). The scope guardrail further clarifies the class of tasks it handles.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries real added weight: it discloses that with 'path' the full code never enters Claude's context, that only the explanation returns, and that a local model writes it and should be reviewed for quality. These are non-obvious traits an agent needs before delegating.

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-loads the decision rule (PREFER over Read, with thresholds) before mechanics and args, so the most actionable content comes first. The 'Args:' block restates the schema somewhat, but the local-model quality caveat 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-format detail is unnecessary; the description supplies selection criteria, the context-saving behavior, and per-param meaning. The remaining gap is edge-case behavior when 'code' and 'path' are combined or omitted, which a 0-required-param tool should address.

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 and largely does: it documents all three params ('code', 'path' read server-side, optional 'question' focus) and the code-or-path alternation. It stops short of saying what happens if both are supplied, if neither is supplied (0 required params), or any size/format expectations for inline code.

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+resource: 'Explains in prose what a code snippet/file does, with a local code model.' It also distinguishes itself from the Read tool, giving an agent a clear basis for choosing it without opening the schema.

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

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

Explicitly names the alternative ('PREFER this tool over reading the file with Read') and the exact conditions that select it: file >200 lines / >10 KB and needing an explanation rather than literal content. Both when-to-use and when-not are covered.

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

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

Annotations only cover readOnly/openWorld, but the description adds substantial behavior: returns an object with exactly the requested keys already validated, reserved-key envelope semantics for non-data (`truncated`, `warning`, `read_server_side`, `fallback`, `error`, `raw`), automatic routing between mechanical and long-context models, and a schema-constrained JSON attempt with free-mode retry.

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 selection rule and outcome, then supporting detail. Mostly earns its place, though implementation minutiae such as '~5-10% difference in UTF-8, acceptable' and the `LOCAL_DELEGATE_JSON_SCHEMA=auto` env-var name are more detail than a calling agent needs.

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 3-parameter extraction tool with no enum or nested schemas, everything needed to call it correctly is present: input selection, return shape, reserved-key envelope, and fallback behavior. The output schema exists, but the description's return-shape detail is complementary rather than redundant.

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 does: 'fields' = JSON keys to extract, 'text' = source text, 'path' = source file read server-side (spending no Claude context), and the text/path mutual exclusivity is stated. All three parameters gain meaning not present 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?

States a specific verb+resource+output form: 'Extracts structured fields from a text/file as JSON, with a local model.' It also distinguishes itself from siblings by naming the alternative behavior (Read) and from local_summarize/local_delegate by emphasizing 'structured fields, not the literal content'.

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 an explicit when-to-use rule with thresholds ('PREFER ... over reading the file with Read when the file is large (>200 lines / >10 KB) and you only need structured fields'), plus per-parameter selection guidance ('use this or path') and the automatic model-routing rule.

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

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

Annotations only cover readOnlyHint/openWorldHint, but the description discloses substantial extra behavior: the file is read server-side, the raw log never enters Claude's context, output is grouped by file with per-rule counts, most important first, and it auto-routes between a mechanical and long-context model.

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-loads the key selection rule ('PREFER this tool over reading the file with Read...') before elaborating. It is a bit long and the Args section partly repeats schema titles, but every major sentence adds usable context.

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

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

An output schema exists so return values need not be described, and the description covers selection criteria, input modes, server-side reading, and routing. Nothing an agent needs in order to call 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?

Schema coverage is 0%, so the description must compensate, and it does for path (read server-side) and text (alternative input), including their mutual exclusivity. max_words is only restated in the args list with no added nuance, so it falls slightly short of full compensation.

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 (Summarizes) and resource (linter/test/CI output) and immediately differentiates itself from reading files with Read. An agent can distinguish it from siblings like local_summarize or local_extract without opening 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?

Explicitly states when to prefer this tool ('large file >200 lines / >10 KB and you only need a grouped summary, not the literal content') and names the alternative (Read). It also gives routing guidance (path vs text, automatic model selection), leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds the useful behavioral framing that it is a diagnostic/precondition probe and a failure-triage entry point. It does not mention cost, latency, or caching, so it stops short of full 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?

Two short sentences and a bulleted intent list, front-loaded with the one-line purpose before the usage cases. Nothing is padded and every clause carries information.

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

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

For a zero-parameter, read-only probe with annotations covering safety and an output schema covering the return shape, the description supplies everything an agent needs: what it inspects, when to call it, and that it serves as a diagnostic for the sibling local_* tools.

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 per the rubric the baseline is 4; there is no parameter meaning for the description to add or omit.

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+resource+scope: 'Read-only diagnostics of the local backend and the model catalog.' This clearly separates it from the sibling local_* action tools (classify, summarize, delegate, etc.), which perform work rather than report state.

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 three concrete when-to-use conditions: discover which local models exist, verify the backend is alive before bulk delegation, and triage a failed local_* tool. It effectively routes the agent to this tool as the precondition check for the other local_* siblings.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely non-obvious behavior: the file is read server-side so content does NOT enter Claude's context, and routing is automatic between a mechanical model (short inputs) and a long-context model (large documents). These are substantive operational traits not derivable from structured fields.

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

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

Front-loaded with the decision rule, then the mechanism, then the args block. The context-saving point is restated twice ('without spending Claude's context' / 'does NOT enter Claude's context'), which is mild redundancy, but the structure is clean and each section is useful.

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 an output schema present, the description need not describe the return value, and it covers everything else an agent needs: when to choose it, both input modes, the server-side read, routing, and per-parameter semantics.

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

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

Schema description coverage is 0%, so the description must carry the load and it does: it explains the text/path alternation, that focus makes the summary prioritize a topic and keep its concrete data verbatim, and that max_words caps summary length. All four parameters are given meaning beyond their bare names and defaults.

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 ('Summarizes text or the content of a file with a local model') and immediately distinguishes itself from the Read sibling by naming the exact conditions (>200 lines / >10 KB) where it should be preferred.

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 says 'PREFER this tool over reading the file with Read when the file is large ... and you only need a summary' – a named alternative plus the condition that selects it. It also states the two input modes (path vs text), so nothing about when-to-use is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial context beyond them: server-side file reading that keeps content out of Claude's context, format preservation, model auto-routing by length, and chunking at Markdown/paragraph boundaries that avoids truncated-output warnings. This is exactly the behavioral detail an agent needs to trust the result.

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 'PREFER...' routing rule, which is the highest-value information. However, the no-context-cost benefit is stated twice ('without spending Claude's context' and 'does not enter Claude's context'), and the Args block largely restates the prose.

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?

Even though an output schema exists, the description usefully explains the return contract (only the translation, complete and in order) and covers routing, chunking, and context isolation. For this complexity level nothing an agent needs to call 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?

Schema description coverage is 0%, so the description carries the burden, and it does explain all three parameters including that 'path' is read server-side and 'text' is the inline alternative. It stops short of stating what happens if both or neither are supplied, and gives no format notes for target_lang, so a small gap remains.

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+resource ('Translates text or the content of a file with a local model') and immediately scopes it as local/no-context-cost, which separates it from siblings like local_summarize and local_classify. The agent can identify the tool from the first sentence without opening the schema.

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

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

Explicitly routes usage: PREFER over Read when the file is large (>200 lines / >10 KB) and only the translation is needed, not literal content. It names the alternative tool (Read) and the condition that selects this one, and clarifies the 'path' vs 'text' choice.

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