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

With no annotations, the description carries the full burden and does well: it discloses that the tool is called once, that the agent then runs an editing loop itself, that rules are deduped by note id, and that it returns both a ready-to-paste 'checklist' string and structured 'rules'. It does not mention side effects, permissions, or idempotency, so it is not fully exhaustive.

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 tool's purpose, then uses a clean numbered list for the workflow loop. Each sentence adds useful information, and there is no filler or redundant restatement.

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

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

An output schema exists, so return values need not be explained in depth, and the description covers the workflow well. However, input semantics are largely missing: task_type values and per_dim meaning are not documented despite 0% schema coverage. Sibling routing is also not addressed, leaving meaningful gaps 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% for two parameters, so the description must compensate. It only indirectly implies that 'task_type' selects a task-type rule_pack; 'per_dim' (default 8) is never explained. This leaves both parameters substantially under-specified.

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 and resource: 'Build the full multi-dimensional checklist for deep Persian editing.' It also notes the tool combines a task-type rule_pack with five editorial dimensions, which helps distinguish it from the sibling rule_pack. However, it does not explicitly name when to choose it over rule_pack or smart_rules, so it falls short of a full 5.

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

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

Usage is clearly described: 'any agent calls this once, then runs the deep-edit loop itself' followed by a four-step editing loop with a max pass count. This gives strong context for how to use the tool. It still lacks explicit exclusions or a direct comparison to alternatives like rule_pack and smart_rules.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: determinism ('Deterministic change ledger') and trust-independence ('without trusting the model's own account'). However, it says nothing about whether this is read-only, whether it recomputes or reads stored state, or any cost/limits.

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, front-loaded sentences that waste little space. Some phrasing is conceptual ('change ledger', 'trusting the model's own account') rather than operational, but it is not verbose.

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

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

An output schema exists, so return values need not be explained, and the tool itself is simple. The remaining gap is the absence of any parameter or behavioral grounding for a tool with zero annotation and zero schema-description coverage, leaving the definition adequate but not fully self-sufficient.

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 schema documents nothing about before_text or after_text, and the description does not compensate by explaining what these inputs are or how they should be supplied. Names are self-evident, but the description adds no meaning beyond them.

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

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

The description makes clear this produces a word-level diff between two texts ('Word-level diff with context', 'every span the pipeline changed'). The verb 'produce a diff' is implied rather than stated outright, and it never explicitly ties itself to the before_text/after_text inputs, but combined with the name and title the function is 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?

It hints at a use case ('Lets any human audit exactly what the system did to the text') but gives no explicit when-to-use condition and does not distinguish itself from related siblings like verify_regression or mechanical_pass. An agent must infer when to reach for 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?

With no annotations present, the description carries the full burden. It partially compensates by implying a read-only, informational operation (a 'map' of the vault) and describing the returned structure, but it never explicitly states read-only safety, side effects, or cost, leaving the agent to guess.

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

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

A single front-loaded sentence with no wasted words, appropriately sized for a no-argument tool. It reads as a noun phrase rather than a full statement, but nothing needs to be trimmed.

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?

Complexity is low, there are no parameters, and an output schema exists so return values need not be explained. What is missing is usage context (when to call it) and any read-only reassurance, which are the only remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is also 100%.

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 names a specific resource (the vault's section tree) and its payload (numbered sections with note counts), which is more informative than the bare title. It lacks an explicit verb, and it never contrasts itself with siblings like search or read_note, so an agent gets the 'what' but not the differentiation.

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?

There is no guidance on when to reach for this tool versus search, read_note, or reindex, and no prerequisites or exclusions are stated. The agent must infer that it is an orienting/overview call purely from the word 'map'.

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 exist, so the description carries the full burden, and it does most of the work: deterministic non-judgmental behavior, ambiguity flagged rather than guessed, and the meaning of the output fields `remaining` and `clean`. It does not state whether the corrected text is returned (vs. mutated in place), idempotency, or failure behavior on empty/non-Persian input, which keeps it short of a 5.

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

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

Front-loads the purpose in one line, then the verification contract, then usage. The parenthetical list of fix categories is dense but each item is concrete and earns its space; no filler sentences.

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

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

An output schema exists, so return values need not be spelled out, yet the description still explains the semantics of `remaining` and `clean`, which is the right kind of added value. The only mild gap is not saying explicitly that the corrected text is part of the result, but the output schema covers that.

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?

One parameter (`text`) with 0% schema description coverage, so the description must compensate. Reading the prose makes it obvious the input is the Persian text to normalize, but no format, length, or encoding expectations are stated. Baseline 3 for a minimal single-param 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?

States a precise verb+resource: a deterministic mechanical fix plus verification gate for Persian text. It also draws its own boundary ('fixes what needs no judgment', 'never guessed'), which lets an agent distinguish it from judgment-based siblings such as ruling or rule_pack without opening a schema.

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

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

Explicitly prescribes placement: 'Use it as the first step (so the LLM works on a clean base) and as the final gate (so nothing ships with mechanical errors).' That is both when-to-use and the workflow position, with the rationale for each.

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. 'Full note' usefully signals that complete content (not a snippet) is returned, but it omits what happens when the note is missing, how max_chars truncates output, and any permission requirements. An output schema exists, which lightens the return-value burden.

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, front-loading the verb and resource while embedding the id-provenance hint in a parenthetical. Every element 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 simple two-parameter read tool with an output schema, the description covers the core contract. The remaining gap is max_chars truncation semantics and error/not-found behavior, which are minor for this tool class.

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

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

Schema description coverage is 0%, so the description must compensate. It explains note_id's provenance ('as returned by search'), which adds genuine value, but says nothing about max_chars (default 6000) or its truncation behavior — half the parameters remain undocumented.

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

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

States a specific verb ('Read') and resource ('a full note from the vault'), and the phrase 'full note' implicitly distinguishes it from the sibling search tool that returns summaries. It stops short of explicitly naming search as the alternative, so it isn't quite a 5.

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

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

The clause 'by its id (as returned by search)' implies the workflow — ids come from search — which is useful context for when to reach for this tool. However, there is no explicit when-to-use vs when-not guidance or routing to 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?

With no annotations, the description carries the full behavioral burden and does establish this as a maintenance write. However, it does not disclose cost or duration of a rebuild, whether it is safe to run concurrently with edits, or whether it must be called manually versus happening automatically.

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 short sentence with the action front-loaded and the trigger condition parenthetically attached. Every word earns its place 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 no-argument tool with an output schema, the description covers what it does and when to run it, so return values need not be explained. The only real gap is operational context such as runtime or concurrency behavior.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are missing.

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 ('Rebuild the search index'), so the action is unambiguous. It does not compare itself against sibling tools like search or map_vault, but its purpose is distinct enough to stand 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?

Gives a clear trigger condition: run after notes are added or edited. It stops short of naming alternatives or stating when not to run it, but the when-to-use cue is explicit.

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

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

With no annotations, the description carries the burden and does so reasonably: it discloses the internal process (runs seed queries through the vault), a filtering rule (keeps only status=verified notes), and the output shape («عنوان: حکم کوتاه»). It omits any explicit read-only statement, rate limits, or behavior when no verified notes match, but for a read-lookup tool this is solid 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?

Purpose is front-loaded in the first line, then mechanics and pipeline placement follow in distinct blocks; the long enum list is necessary because the schema lacks it. No filler sentences, though the pipeline reference adds little for an agent that has no pipeline 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?

For a two-param tool with an output schema and no annotations, the definition covers purpose, input values, filtering logic, and result format adequately. The main gap is the absence of any routing guidance toward the several closely-named rule siblings, which the agent would otherwise have to guess between.

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 declares no enum, so the description's enumerated task_type list is essential and fully compensates; it also explains the fallback for unrecognized values (free-form search query). max_rules is clarified via 'returns up to max_rules items', though its integer/default nature is left to 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 ('Build the compact checklist for a Persian writing task') and pins its place in a pipeline, so the agent knows it produces a checklist rather than a search result. It does not explicitly distinguish itself from rule-flavored siblings like deep_rules or smart_rules; 'compact' hints at the distinction but never names the alternatives.

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 real context ('step 2-3 of the «حالت کامل» pipeline') and enumerates valid task_type values, which implies when to reach for it. However it never states when NOT to use it, nor points to deep_rules/smart_rules/ruling as alternatives for a different depth or purpose.

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 behavioral burden. It usefully discloses that this is a composite read operation (search the vault, select the 'best note', return its ruling and note id), but 'best note' is an undisclosed selection heuristic, and there is no mention of permissions, failure behavior when nothing matches, or rate limits.

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

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

Three short sentences, purpose front-loaded, with no filler. The only minor redundancy is restating 'short ruling' twice and the parenthetical Persian glosses, which are useful but lengthen the middle sentence.

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

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

An output schema exists, so return-value detail is not required, and the description's mention of the note id is a bonus. However, for a tool sitting among nine similar retrieval/rule siblings with zero annotation coverage and an undocumented parameter, the absence of disambiguation and edge-case behavior leaves meaningful 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% for the single 'query' parameter, so the description must compensate. 'For a question/doubt' does convey that the input is a natural-language editorial question rather than a keyword, which adds some meaning, but no format, length, or example guidance is given.

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 ('Get the vault's short editorial ruling for a question/doubt') and even sketches the internal mechanism (search the vault, take the best note, return the ruling plus note id). It is clear what the tool produces, though it does not distinguish itself from adjacent rule-oriented siblings such as deep_rules, smart_rules, or rule_pack.

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 one concrete usage context: 'Use this as the virtual editor's verdict before finalizing Persian text.' That is a real when-to-use cue, but there are no exclusions and no named alternatives among the ten siblings (search, deep_rules, smart_rules, rule_pack), so the agent must infer the boundaries itself.

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 behavioral burden. It does disclose return behavior ('ranked notes with snippets'), which is useful, but says nothing about read-only safety, authentication, rate limits, or whether results are scoped to the vault only.

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 with zero waste, front-loading the scope of the search before the return format. Nothing needs trimming.

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

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

An output schema exists, so return values need not be explained, and the tool is simple with only two parameters. However, with 0% schema description coverage and no usage guidance, the description leaves real gaps 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% and the description adds no meaning for either parameter. It does not explain what 'query' accepts (natural language, keywords, Persian text) or how 'top_k' affects ranking or the default of 5.

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 (Search) and a scoped resource (Masoud's Persian writing/editing vault), which is enough to distinguish it from siblings like read_note or map_vault. It does not explicitly name an alternative, but the action is 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?

There is no guidance on when to use this versus read_note, map_vault, or the rule-related siblings. The agent must infer that search is for discovery and read_note for direct retrieval.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses the scan signals (long sentences, Arabic chars, ZWNJ, Latin punctuation, etc.), that rules are ordered by signal weight, that each rule carries a `why` field, and that Layer 1 is always the task-type rule_pack. It omits any note on cost/latency, determinism, or whether re-running yields identical output, so it falls just short of a 5.

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

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

It is front-loaded with a one-line summary before the detail, and the sentence count is proportionate. The parenthetical signal list ('bureaucratic fossils', 'cliches, repetition, ...') is slightly decorative but does carry real information about what gets scanned.

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

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

An output schema exists, so return values need not be explained, and the description adequately covers the tool's adaptive behavior, ordering, and the `why` evidence field for a moderate-complexity tool. The gap is the required `task_type` parameter, whose accepted values remain undefined anywhere, which matters because it determines Layer 1.

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

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

Schema description coverage is 0% and the description never explains the three parameters. `task_type` is required and evidently drives the Layer 1 rule_pack, but no valid values or semantics are given; `max_rules` (default 60) is never mentioned at all. Only `text` is loosely implied to be the Persian text that gets diagnosed.

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 concrete two-stage action (diagnose Persian text, then build a tailored deep-edit checklist) and explicitly positions itself against the sibling `deep_rules` ('Smarter than deep_rules: instead of a fixed checklist...'). An agent can tell what this produces and how it differs from the fixed-checklist alternative without opening any 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?

It makes the selection condition against `deep_rules` fairly clear: use this when you want rules pulled for the risk signals actually present rather than a fixed checklist. It also states the intended workflow ('any agent runs the edit -> review loop itself'). However it never states explicit when-not conditions or names other siblings (e.g. `rule_pack`, `mechanical_pass`) as alternatives, so routing is implied rather than spelled out.

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. It usefully discloses that the check is deterministic ('Pure diagnose() comparison, no LLM') and what it emits (resolved/remaining lists plus a boolean pass), which implies a read-only, side-effect-free operation. However, it never explicitly states there are no writes, what permissions are needed, or cost/latency characteristics.

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

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

Front-loaded with the core rule, then method, then return shape. Three short blocks with minimal waste; the closing metaphor is slightly rhetorical but does communicate the all-or-nothing gate semantics.

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 spelled out, and the description still summarizes them. For a 2-parameter tool with no nesting or enums, the remaining gap is positional guidance relative to siblings, which is minor.

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. The sentence 'every problem signal diagnosed in the input text must be gone in the output text' does convey the before/after relationship of the two required parameters, but it does not name them or specify accepted formats, length, or empty-input behavior.

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 ('verify_regression') and defines the operation precisely as a diagnose() comparison between before_text and after_text problem signals. It is clear what the tool does, but it never distinguishes itself from siblings that sound similar (diff_report, mechanical_pass), so it falls short of a 5.

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

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

Framing it as 'the pipeline's proof of work' and an 'objective regression gate' implies it belongs at the end of a fix pipeline, but there is no explicit when-to-use, when-not-to-use, or named alternative among the 11 siblings. Usage must be inferred.

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