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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real behavioral context: arbitrary precision via big-integer parsing, exactness beyond 2^53 where naive conversion fails, and tolerance of leading 0b/0x/0o prefixes. These are traits an agent cannot recover from the 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?

Three tight sentences, front-loaded with the core action and scope, then precision guarantees, then the prefix edge case. Every sentence carries information; nothing is redundant 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?

With no output schema, the description should ideally specify the return representation (a string in the target base), which it leaves unstated, and it says nothing about error behavior for out-of-range digits. All three required parameters are documented and the precision caveat is covered, so it is close to complete for a simple deterministic tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it by clarifying that 'value' may carry a 0b/0x/0o prefix that is ignored. It does not clarify the return type (string vs number) or behavior on invalid digits, so it falls short of fully complementing 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 (convert), a specific resource (integer string), and an explicit scope (bases 2-36), which is far more precise than the sibling name 'convert' alone. It does not explicitly contrast itself with the sibling 'convert', so sibling differentiation is only 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?

Usage is implied by the narrow purpose: use it when you need a base-to-base integer conversion. There is no explicit when-to-use/when-not guidance and no mention of how it relates to the nearby 'convert' or 'hash' siblings; an agent must infer the boundary.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes further by disclosing error semantics (cross-family requests fail loudly rather than returning nonsense) and the decimal-vs-binary convention for data units. It does not mention precision or rounding, which keeps it at 4 rather than 5.

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

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

Three sentences, front-loaded with purpose before the constraint, then the unit vocabulary. The long unit list is information-dense rather than padding, and 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 stateless, side-effect-free conversion with full annotation coverage, the definition gives everything needed to call it correctly. The only unmet detail is what the return value looks like (bare number vs object), which is not stated and no output schema exists to cover 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?

The schema descriptions are minimal ('Source unit', 'Target unit', 'Numeric value'), so the description carries real load by supplying the complete accepted vocabulary for from/to and disambiguating kb/mb/gb (1000) from kib/mib/gib (1024). This is meaningfully more than the 100%-covered schema provides.

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 (convert) plus the resource families (length, mass, time, data size) and then enumerates every supported unit, so an agent can tell at a glance that this is physical-unit conversion and not the sibling base_convert (numeric base conversion). No ambiguity about what it does.

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

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

Usage is implied by the purpose and the constraint that from/to must belong to the same family ('cross-family conversions are rejected'), but there is no explicit when-to-use statement and no routing guidance against the closely related base_convert sibling. Adequate but leaves the alternative-selection decision 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, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds useful behavioral detail beyond the annotations: negative amounts subtract and arithmetic is calendar-correct across month ends and leap years. It does not cover error handling or return format.

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, front-loaded sentences with no filler. The purpose, sign convention, and calendar behavior are stated efficiently.

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 date utility with full schema coverage and safety annotations, the description is largely complete. It omits any mention of the return format, which matters slightly since no output schema exists, but the core operation is clear.

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 100%, so the schema already documents each parameter. The description adds semantic meaning by clarifying that negative amounts subtract and that month/year arithmetic is calendar-correct, which is not fully conveyed by 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 (offset) and resource (ISO-8601 date) with the supported units. It does not differentiate from the sibling date_calc tool, 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?

The description explains what the tool does but gives no explicit guidance on when to choose it over alternatives like date_calc, nor any exclusions or prerequisites. Usage is only implied by the operation 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?

Annotations already establish the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description still adds real behavioral context beyond them: true calendar arithmetic rather than 30/365 approximations, and UTC-only math, both of which materially affect results.

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

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

Three tight sentences, all earning their place, with the core operation front-loaded and the caveats (calendar arithmetic, UTC) following immediately. No filler or repetition of the tool name.

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

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

No output schema exists, and the description is sufficient to call the tool correctly given the fully documented three-parameter schema. The one residual gap is whether the result is signed or absolute when 'to' precedes 'from', which the description never addresses.

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 100% so the baseline is 3, but the description goes past bare restatement by defining businessDays as Mon-Fri and confirming calendar-accurate handling of the 'months' and 'years' enum values. It does not clarify sign/direction semantics for from vs to.

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 computation (interval between two ISO-8601 dates) and enumerates the units returned, so the resource and operation are unambiguous. It does not explicitly name the sibling date_add or draw the boundary against it, so an agent must infer the distinction from the semantics 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?

Usage is implied by the phrasing 'interval between two ISO-8601 dates', which naturally contrasts with date_add's offset semantics. However, there is no explicit statement of when to prefer this tool over date_add, nor any prerequisites or exclusions, so guidance stops at implication.

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 readOnly, idempotent and non-destructive, so safety is covered. The description adds a genuinely useful trait beyond them: it refuses oversized input rather than hanging, and describes the per-line operation output plus added/removed/unchanged counts.

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

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

Three tight sentences, front-loaded with the core action and algorithm, then output shape, then the oversize failure mode. 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?

Despite having no output schema, the description fully specifies return contents (per-line equal/del/ins with line numbers plus counts) and the oversize behavior, so nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so a, b and maxLines are fully documented in the schema. The description only restates 'two texts' and the maxLines cap indirectly, adding no syntax or format detail beyond the schema; baseline 3 applies.

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 (compute a line-by-line diff between two texts) and even names the algorithm (LCS), which implicitly distinguishes it from sibling tools like similarity and fuzzy_match that do approximate matching.

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

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

No explicit when-to-use or when-not guidance, and no sibling is named. Usage is only implied: exact/reproducible diff contrasts with the fuzzy/approximate siblings, but the agent must infer this.

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 readOnly, idempotent, non-destructive, closed-world. The description adds genuinely new behavioral facts: that the result is deterministic and that matches are returned in descending score order. It stops short of stating result payload shape or big-haystack performance 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?

Three tight sentences, with the core operation front-loaded before the use-case list. No filler or repetition. Slightly over-compressed on the return-value side, but 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?

With no output schema, the description carries the burden of describing the return value, and it only says 'best matches in descending order' without stating whether results are bare strings or string/score pairs. With four parameters and no output schema, more precision about the response was warranted.

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 100%, so needle, haystack, topN and threshold are already documented in the schema; baseline is 3. The description clarifies that scoring is per-candidate against the query, but adds no format or edge-case detail (e.g. empty haystack, threshold semantics) beyond what the schema provides.

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 operation (score candidate strings against a query), the exact algorithm (Sorensen-Dice over character bigrams), and the output ordering. It is unambiguous about what the tool does. However, it makes no attempt to distinguish itself from the sibling tool 'similarity', which likely overlaps, 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?

It lists concrete use cases (deduplication, record linkage, typo-tolerant lookup, disambiguation), which implies when to use it. But it names no alternative and no exclusions, and conspicuously ignores the close sibling 'similarity', leaving the agent to guess which is appropriate.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the return shape (hex + base64 digests plus UTF-8 byte length), the default algorithm, and the HMAC mode triggered by hmacKey.

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

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

Three tight sentences: purpose first, output/options second, use cases last. No filler, and the most important information is front-loaded.

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 deterministic tool with no output schema, the description covers purpose, inputs, defaults and return format. An agent has everything needed to call it correctly and interpret the result.

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 100%, so the schema documents text, algo (with enum and default) and hmacKey, and the description merely restates these. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Compute a cryptographic hash of a UTF-8 string') and enumerates the algorithm set. No sibling tool performs hashing, so the scope is unambiguous within the tool set.

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 concrete use cases ('content fingerprints, deduplication and integrity checks'), which tells the agent when this tool is appropriate. It does not name alternatives or exclusions, but no sibling overlaps with hashing, so there is little to route against.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds batch-efficiency context but says nothing about the 200-path cap, what happens on unresolvable paths, or how results are keyed to inputs. Some added value, but not rich behavioral 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 sentences, zero waste, and the core capability is front-loaded ahead of the comparative guidance. Nothing redundant or padded.

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 batch resolver with no output schema, the return contract matters, and the description does not explain how results map back to the input paths, their ordering, or error handling for missing paths. The core purpose and when-to-use are complete, but the output/error behavior is a real gap.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, which sets the baseline at 3. The description conveys that paths are batch-resolved but adds no path syntax (JSONPath vs. dot notation) or ordering/alignment semantics beyond 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 and resource ('Resolve several paths against one JSON document') plus the batching scope 'in a single call.' It also names the sibling json_query, so an agent can distinguish it from the single-path query tool without opening either 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: use this 'when you need multiple fields' and frames it as cheaper than many json_query calls. The inverse condition (use json_query for a single field) is left implicit, and no exclusions or prerequisites are given, so it falls just short of a 5.

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

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real behavioral value: it separates `resolved` from `found` so absent-vs-null is distinguishable, and it enumerates specific failure modes (missing-key, out-of-range, not-an-array, not-an-object). It stops short of describing the overall response shape.

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 tightly packed sentences, front-loaded with the core action, then semantics, then error taxonomy. No filler and nothing repeated from 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?

With no output schema, the description must carry return semantics, and it does explain the resolved/found distinction and error types. It omits the field name/structure that actually carries the extracted value, which for a simple 2-parameter tool is a minor but real gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by showing a second path dialect (`$.items[3].name`), implying JSONPath-style prefixes are accepted where the schema example only shows dotted notation.

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 (extract) and resource (value from a JSON document by path) and gives concrete path syntax examples, so the operation is unambiguous. It does not, however, distinguish itself from the sibling json_pick, leaving the agent to guess which extraction tool fits.

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 when-to-use guidance and no mention of alternatives such as json_pick or json_validate, even though those siblings clearly overlap. Usage must be inferred entirely from the 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 readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description goes further by disclosing return behavior on both paths (parser message with computed line/column on failure, top-level shape on success) and the valid-empty-object edge case, which is genuine added 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?

Three short sentences, front-loaded with the core purpose, then failure behavior, then success behavior. No filler or restatement of the name.

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

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

There is no output schema, so the description carries the burden of explaining returns — and it does, covering both success and failure outputs plus an edge case. Combined with full schema coverage and annotation safety hints, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so both parameters are already documented by the schema, making 3 the baseline. The phrase 'top-level shape' in the description loosely corresponds to describeTopLevel but adds no format, default, or constraint detail beyond 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: 'Check whether a string is valid JSON', which is unambiguous about what the tool does. However, it does not differentiate itself from siblings like json_query or json_pick, which an agent might plausibly confuse with validation work.

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 use case (validation before parsing) but never states when to pick this over json_query or json_pick, nor any prerequisites or exclusions. Usage is inferable but not guided.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: auto-detection behavior ('most frequent candidate on the first line is chosen and reported back') and the RFC 4180 conformance guarantee. It doesn't mention behavior at row-cap truncation, which would be the last missing piece.

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

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

Three sentences, each earning its place: capability, auto-detection behavior, and the routing contrast. The most important distinguishing information (RFC 4180 and the anti-pattern warning) is front-loaded. 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 read-only, idempotent parse tool with no output schema, the description covers purpose, edge cases, auto-detection, and routing. The only gap is that it doesn't describe the shape of the returned header/rows structure, which matters somewhat since there's no output schema. Still, the RFC 4180 reference implies a standard table structure an agent can reason about.

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 100%, so all four parameters are already documented with defaults and ranges. The description reinforces auto-detection semantics for the delimiter parameter, which is genuinely useful added meaning, but does not add syntax or format detail for text, maxRows, or hasHeader. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (Parse) and resource (delimited text into header plus rows), and goes further by enumerating the exact edge cases handled (quoted fields, escaped quotes, embedded delimiters, embedded newlines, RFC 4180). This distinguishes it clearly from siblings like regex_extract or convert, which are the nearest overlap candidates.

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 use it versus the naive alternative: 'Use instead of splitting on commas, which breaks on any real CSV.' This names the anti-pattern and the reason, giving the agent a clear routing rule without needing to guess.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real value beyond them: it enumerates the specific hazards detected (nested quantifiers, overlapping alternation, backreferences under quantifiers, excessive wildcards) and explicitly states the pattern is not executed, which matters for safety-sensitive callers.

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

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

Three tight sentences, front-loaded with the purpose, then the detection scope, then the return shape. Every sentence 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?

With no output schema, the description correctly compensates by describing the return ('a risk level and the specific reasons'). It could go slightly further by naming the risk-level values or flagging that only heuristic static analysis is performed, but an agent has enough to call and interpret 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?

There is a single parameter and the schema already documents it fully (100% coverage: 'Regular expression source to analyse'). The description adds no syntax or format guidance beyond that, so baseline 3 applies.

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 verb and resource ('statically analyse a regular expression') and states the exact problem domain (catastrophic backtracking / ReDoS). It is easily distinguished from the sibling regex_extract, which extracts rather than analyses.

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

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

Usage is implied by the nature of the tool — you use it to vet a pattern for ReDoS risk — and 'The pattern is not executed' hints it is a safe pre-flight check. However, it never states when to prefer this over alternatives or when analysis is unnecessary, so guidance remains 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?

With readOnlyHint, idempotentHint and destructiveHint=false already declared, the safety profile is covered. The description goes further by disclosing operational behavior the annotations cannot: iteration and match counts are hard-capped, a worker thread is terminated on budget expiry against pathological patterns, and a ReDoS risk assessment is returned. These are real behavioral traits beyond structured data.

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

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

Three sentences, no filler, and the primary capability is front-loaded before the safety and response details. Tight and well-ordered, though the middle sentence about caps could be folded into the parameter documentation.

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 carries the return-value burden and does so by naming the match index, capture groups and named groups. It also covers failure-mode behavior with the cap and deadline narrative. The only real gap is the absent routing versus regex_analyze.

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 100%, so all five parameters (text, pattern, flags, budgetMs, maxMatches) are already documented in the schema, including defaults and the worker-termination semantics for budgetMs. The description adds only a general note about match capping, which the schema already states for maxMatches, so it earns the baseline rather than more.

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 (apply a regex, return every match) and even enumerates the return shape: match index, numbered capture groups, named groups. This is far more than a restatement of the name. It does not, however, distinguish itself from the sibling regex_analyze, which is the closest competing tool.

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

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

There is no explicit when-to-use guidance and no mention of the sibling regex_analyze, which appears to be the nearest alternative for regex work. An agent must infer from context alone whether it should extract matches or analyze the pattern.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds meaningful value beyond them: the 0-1 output scale and its interpretation (0 = no shared character bigrams, 1 = identical) tell the agent how to read the result, which the annotations do not. Determinism partly restates idempotentHint.

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

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

Two tight sentences, front-loaded with the algorithm and resource and followed by the range interpretation. Every clause carries information; nothing is redundant.

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-argument pure function with no output schema, the description is nearly sufficient because it defines the return semantics. Minor gaps remain: no note on case sensitivity, unicode/bigram normalization, or empty-string edge cases.

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 parameters are bare 'a' and 'b', but the description compensates partially by stating both inputs are strings ('two strings'). It does not state which argument is the reference vs. the candidate, whether order matters, or empty-string behavior, so it only partly fills the gap.

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 the exact algorithm (Sorensen-Dice), the resource (two strings), and the output scale, so an agent knows precisely what computation it performs. It does not explicitly distinguish itself from the nearest siblings fuzzy_match or diff_text, which is the only thing keeping it from 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?

Usage is implied rather than stated: 'of two strings' and 'one deterministic comparison' suggest a single pairwise similarity check, but there is no explicit guidance on when to pick this over fuzzy_match or diff_text, nor any exclusions or preconditions. Adequate but leaves the sibling-routing decision 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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful context beyond that: Unicode-aware word segmentation and the exactness guarantee, which are important behavioral traits for a counting tool.

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

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

Two sentences, front-loaded with the full metric list and then the key behavioral guarantee and usage cue. Every phrase carries useful information with no redundancy.

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

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

With annotations covering safety and schema covering inputs, the description's enumeration of computed metrics compensates for the absence of an output schema. It is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description does not add any parameter-specific detail beyond what the schema provides, such as the meaning of topN or its default. Baseline 3 is appropriate.

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 the specific operation (exact text statistics) and enumerates the exact metrics returned, which clearly distinguishes it from siblings like diff_text, hash, or regex tools. An agent can immediately understand what the tool computes.

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 a clear usage condition: 'Use whenever a count must be exact.' This tells the agent when the tool is appropriate, though it does not name alternatives or explicitly state when not to use it.

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