Duo Data Utilities

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: it returns detected chains with a confidence note, a checksummed EVM form, and the exact failure reason, plus a payment/auth requirement ('$0.05 per successful call, paid over x402 (USDC on Base)') that the annotations do not convey.

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 purpose, then outputs, then pricing — a sensible ordering. The long chain enumeration is information-dense and earns its space, though it slightly crowds the sentence structure.

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 return values (detected chains, confidence, checksummed form, failure reason) and adds pricing/auth context. It never explains the meaning of the 'confidence note' or error shapes in detail, leaving a small gap for a 3-param tool with a paid, openWorld-flagged operation.

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. The `chain_id` EIP-1191 behavior and the `expect` enum are already fully documented in the schema; the description's encoding list is about capability, not parameter meaning, so it adds little beyond the structured fields.

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 pair ('Identify which blockchain an address belongs to and validate its encoding') and enumerates the exact chains and encodings covered (EIP-55, base58check, bech32/bech32m, SS58). An agent can immediately tell this is an address-format/checksum tool rather than a hash, geo, or id tool from the sibling 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?

Usage is implied by the purpose (feed it an address to detect/validate), but there is no explicit 'when to use this vs chain_selector' statement or any exclusion. The 'expect' restriction is only surfaced in the schema, not the description, so alternatives/conditions are 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 declare readOnlyHint and idempotentHint, so safety is already covered; the description goes beyond by disclosing cost and payment mechanics ('$0.05 per successful call, paid over x402 (USDC on Base)') and the normalisation pipeline. It stops short of describing failure behaviour for malformed signatures, which is the remaining behavioral gap.

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 core purpose, then normalisation, alternate mode, and pricing — each sentence carries distinct information with no filler. Slightly long at four sentences, but nothing is redundant enough to cut.

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, but the description enumerates the outputs (Keccak-256 hash, 4-byte selector, 32-byte topic), and all four parameters are fully documented in the schema. Cost, normalisation, and dual input modes are all covered; only error/invalid-input behaviour is unaddressed.

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; the description earns above baseline by explaining how the signature parameter is interpreted (parameter names stripped, uint expanded to uint256, tuples flattened) and by clarifying that data is the raw-hash alternative. That meaning is not recoverable from the schema descriptions alone.

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

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

States a specific verb and resource ('Compute the Keccak-256 hash of a Solidity function or event signature') and names the exact derived outputs (4-byte selector, 32-byte event topic). It also carves out a secondary mode ('Also hashes arbitrary text or hex bytes'), so an agent can distinguish it from generic hashing siblings like code_hash.

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 clear usage context: use it on signatures copied from source because normalisation guarantees the canonical selector, and use the data/encoding path for arbitrary text or hex. It does not explicitly state when not to use it or name an alternative sibling, but the mode selection (signature vs data) is well 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 cover the safe, read-only, idempotent nature. Beyond that, the description discloses the paid x402/USDC cost model, supported algorithm families, input/output encodings, HMAC key support, and the exact return payload contents, which is rich 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?

The description is a single dense paragraph, front-loads the core operation and algorithm support, then adds encoding details, return shape, and pricing. Every sentence carries information useful for selection or invocation.

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

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

For a six-parameter cryptographic tool with no output schema, the description explains the main return values: digest, input byte length, and algorithm identifier. It does not specify exact output field names or error payloads, but the agent has enough 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 100%, and all six parameters already have enum or constraint descriptions in the schema. The description restates the algorithm and encoding options but adds little syntactic or default detail 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 states a specific verb+resource: compute a cryptographic digest of supplied data. It enumerates supported algorithms, HMAC, input encodings, output encodings, and return contents, so the agent can identify exactly what the tool does 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 implies usage through a detailed capability list, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling tool competes for hashing, so the gap is modest but present.

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 cover safety (readOnly, idempotent, closed-world), and the description adds genuinely useful traits beyond them: the return payload (both forms, per-label breakdown, first rule violated) and an important cost/auth trait ($0.05 per successful call paid over x402 in USDC on Base). It doesn't discuss failure modes for malformed input or latency beyond the 'first rule violated' hint.

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 clause, followed by validation detail and then payment terms. The middle sentence enumerates many rules in a dense run-on, but every listed rule (length, hyphen positions, bidi) earns its place for a validator.

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 fills the gap by describing the return shape (both forms, per-label breakdown, first rule violated). It also covers the non-obvious invocation requirement (paid x402 call) and the semantics of strict mode, leaving nothing an agent needs to call it correctly unstated.

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 three parameters (domain, to, strict) are already documented in the schema, including enum values and the ß→ss mapping nuance. The description's mention of direction ('either direction', 'label by label') adds only marginal meaning over the schema, 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?

States a precise verb+resource ('Convert internationalised domain names between Unicode and ASCII punycode'), plus the validation scope (IDNA2008 label rules) and direction control. It also distinguishes itself from the sibling code_url by noting that strict IDNA2008 'may reject names /v1/code/url displays'.

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 contextual signal for the strict parameter (non-transitional IDNA2008 vs. IDNA2003-compatible UTS 46, and how browsers/code_url differ), which effectively tells the agent when output will diverge from other tooling. It stops short of explicit when-not-to-use guidance or naming an alternative tool for a specific task.

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 read-only/idempotent/closed-world; the description adds the return shape, structural error reporting (missing part, invalid base64url, alg none), the hard non-verification boundary, and a payment prerequisite ($0.05 per successful call over x402 on Base) — none of which the annotations convey.

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 clause and every sentence carries information, including the pricing line. The opening sentence is long and list-heavy, but nothing is padding or repetition.

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 characterize returns and does so field-by-field, and it covers cost and failure modes. It stops short of detailing error payload shape or pagination/latency behavior, so it is strong but not exhaustive for the tool's complexity.

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, setting the baseline at 3. The description adds only a little semantic glue ('against a supplied or current instant', remaining lifetime) that partly restates the `at` parameter's own schema text.

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 (Decode) plus resource (JSON Web Token) with an explicit scope boundary ('without verifying it'), and it enumerates the outputs (header, claims, signature length, algorithm, time-claim view). An agent can distinguish this from a validation/verification tool immediately.

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 use context (structural inspection of claims and expiry state) and an explicit exclusion: 'do not use it to decide trust.' It does not name an alternative tool, but none among the code_*/id_* siblings performs JWT signature verification, so the guidance is effectively complete.

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-open-world behavior, so safety is covered. The description adds genuinely new operational context the annotations cannot carry: the x402 payment requirement and per-call price ($0.05 USDC on Base), plus what a failed range test returns (the reason). It omits any note about the cost applying only to successful calls vs attempts beyond the stated "per successful call".

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 the operation set before the return/pricing details. The first sentence is a long semicolon-separated list, but every clause maps to a distinct 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?

No output schema exists, and the description compensates by stating what comes back (parsed structure, comparison result, mismatch reason). The main gap is that the `sort` operation present in the enum and `versions` parameter is never mentioned in the description, leaving one mode unexplained.

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 beyond the schema by naming the supported range grammars (caret, tilde, hyphen, x-ranges, comparator sets) and giving an example (^1.2.0), which meaningfully clarifies the `range` parameter.

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 (semantic version) and enumerates the concrete operations: parse into major/minor/patch/prerelease/build, compare by precedence, and test range satisfaction. It is immediately distinguishable from every sibling (code_hash, code_jwt, code_url), none of which touch versioning.

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 clearly maps the three main use cases to intent ("compare two versions by precedence including prerelease ordering", "test whether a version satisfies a range expression"), which effectively tells the agent when to pick each mode. It stops short of explicit when-not guidance or naming alternatives, but with unrelated siblings there is little competition to disambiguate.

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/idempotent/openWorld; the description goes well beyond by disclosing the full returned field set, the canonicalisation rules applied (default port, dot-segments, percent-encoding), the non-strict WHATWG/UTS 46 handling of unicode_host, and the private-vs-ICANN suffix distinction. It even surfaces billing behavior ($0.05 per successful call via x402/USDC on Base), which annotations cannot 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?

It is front-loaded with the core action and outcome before the pricing tail, and every clause carries information. The return-field enumeration makes it a long single sentence, but no sentence is filler.

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

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

With no output schema, the description compensates by enumerating exactly what is returned, and it covers input forms, canonicalisation semantics, and cost. An agent has everything needed to call it 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 both 'url' and 'base' are already documented in the schema and the baseline is 3. The description adds nothing about how relative resolution via 'base' interacts with canonicalisation, so it neither compensates nor detracts.

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 set (parse, canonicalise, extract registrable domain) and the exact resource (URL), and states the concrete outcome: scheme, host, port, path, query, suffix, eTLD+1, subdomain. No sibling tool in this list does anything comparable, so the agent can distinguish it immediately.

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 motivating use case — 'the part an agent needs to decide whether two URLs belong to the same owner' — which tells the agent when this tool is the right one. It stops short of naming exclusions or alternative tools, but none of the siblings overlap, so the practical guidance is sufficient.

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/openWorld=false, but the description adds real behavioral context beyond them: the Vincenty algorithm with haversine fallback, the units returned, and notably the $0.05 per-call x402/USDC payment requirement, which an agent must know 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?

Two dense sentences that front-load the core capability and append units and pricing. Efficient with no filler, though the first sentence packs several capabilities together.

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 usefully states the units returned (metres, km, nm, miles) and enumerates all operations and the destination inputs. It stops short of mapping which params each op requires, but the 100%-covered schema fills that 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 schema already documents all nine parameters, including enums for op and method. The description reinforces op semantics and mentions bearing/distance for destination, but adds no syntax or meaning beyond the schema, so the baseline 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 precise verbs and resources: geodesic distance, initial/final bearing, midpoint, destination point, and cumulative path length. It is clearly a coordinate-math tool, distinguishable from geo_geohash, geo_pluscode, and geo_polygon siblings.

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 enumerates the four operations, which implicitly signals usage, but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. Selection among siblings 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 cover read-only, idempotent and closed-world behavior, so the description is not obligated to repeat safety traits. It goes beyond them by disclosing pricing and payment mechanics ('$0.05 per successful call, paid over x402 (USDC on Base)') and by describing the return payload (neighbouring cells, bounding box, centre, error bounds in metres), which the annotations cannot 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?

Two dense sentences with the operation defined first, followed by the return shape and then the payment constraint; nothing is padded. It is slightly packed with parenthetical detail, but every clause carries information an 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?

With no output schema, the description steps in to explain return values (bounding box, centre, error bounds, neighbouring cells), and annotations already carry the safety profile. Pricing, defaults and the encode/decode branch are all covered, leaving nothing essential missing 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 100%, so op, lat, lon, geohash and precision are already fully documented with ranges, defaults and accepted values. The description restates the encode/decode duality and precision but adds no syntax or format detail beyond the schema, so the baseline of 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 specific verbs and resources ('Encode a WGS-84 latitude and longitude to a geohash', 'decode a geohash back to its bounding box, centre point and error bounds'), which clearly separates it from siblings like geo_pluscode and geo_distance. An agent knows exactly what the 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?

It gives a concrete use case ('proximity search over a geohash-indexed store without a spatial database'), which implies when the encode+neighbour path is appropriate. It never names an alternative tool or states an explicit when-not condition, so selection against geo_distance or geo_pluscode 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 cover safety (readOnly, idempotent, not open-world), and the description adds material beyond them: a per-call price of $0.05 settled over x402 (USDC on Base), plus the shape of the result ('code length, precision in metres and validity'). It does not address failure modes or invalid-input behavior, so it stops 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?

Three dense sentences, front-loaded with the core encode/decode purpose before the less obvious shorten/recover modes and the pricing tail. Every sentence carries distinct information; nothing is redundant with 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 compensates by naming the returned fields (code length, precision in metres, validity), and it discloses the payment model. It leaves some ambiguity about which ops return which fields and about invalid-code handling, so it is strong but not 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it ties length to a 'chosen' precision, and explains that ref_lat/ref_lon act as the reference coordinate for shorten/recover, clarifying the relationship between the coordinate and code params across ops.

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 set: encode coordinates to an Open Location Code, decode a code to bounding box and centre, shorten against a reference, and recover a shortened code. This clearly separates it from siblings like geo_geohash and geo_distance without needing their 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?

The description explains what each op does and notes shorten/recover reflect 'how plus codes are normally exchanged in text', which implies usage, but it never states when to pick this tool over a sibling (e.g., geohash) or when each op is inappropriate. Usage is implied rather than prescribed.

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

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

Annotations already cover read-only, idempotent and closed-world behavior, but the description adds genuinely new behavioral facts: a paid x402/USDC-on-Base billing model at $0.05 per successful call, and the important distinction that containment is planar while area/length are geodesic on WGS-84. Hole handling and the Feature-wrapping input form are also disclosed. It stops short of describing response shape or error behavior.

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

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

Two dense sentences, front-loaded with the capability list before the billing note, with no filler. It is slightly run-on packed, but every clause carries operational content.

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 read-only/idempotent annotations and no output schema, the description carries the return-shape burden and largely does so by enumerating the six computed values, plus input-type and geodesic/planar semantics. It is close to complete for a 4-parameter, single-purpose geometry 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 the schema lacks: area is 'signed' and expressed in square metres, length is geodesic, and containment handling is planar with hole handling on the geometry. Those unit and semantic details are not present in the schema text.

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 operations performed (containment, bbox, centroid, signed area, perimeter, winding) on a specific resource (a caller-supplied GeoJSON geometry), so an agent knows precisely what it does. It never names or contrasts against geo_distance/geo_geohash/geo_pluscode, so the sibling differentiation that would make this a 5 is absent.

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 only implied: the ops parameter and 'Default all' tell the agent what a call looks like, but there is no statement of when to prefer this tool over geo_distance or geo_pluscode, and no prerequisites or exclusions. An agent can infer the domain but is not routed.

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 a safe, idempotent read (readOnlyHint, idempotentHint, openWorldHint false). The description adds genuinely new behavior: it is structural validation only with no product database lookup, it enumerates what is returned, and it discloses a per-call cost and payment rail. Error behavior on malformed input is the only notable omission.

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 identifier list and return summary are front-loaded, and the closing note on database scope and pricing is compact. Three sentences carry distinct payloads with no filler, though the opening enumeration of formats is somewhat dense.

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

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

With no output schema, the description carries the return-value burden and does so by naming the check-digit verdict, computed digit, prefix boundary, and GTIN-14 conversion. Input constraints (8/12/13/14/18 digits, spaces/hyphens) are covered by the schema, so the only residual gap is failure-mode behavior for invalid codes.

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 enum values for op and to are already fully documented. The description adds incremental meaning by explaining that checkdigit derives a missing final digit from a partial code, but this only reframes what the schema already states. 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?

States a specific verb (validate/convert) and the exact resource class (GS1 identifiers) with an enumerated list of supported formats (GTIN-8/12/13/14, GLN, SSCC). This clearly separates it from siblings like id_national and id_security, which cover different identifier domains.

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 conveys when each mode applies (validate vs compute a missing check digit vs convert to GTIN-14), which gives clear context. However, it never explicitly routes the agent away from alternatives such as id_national or id_security, so selection among sibling identifier tools 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 establish read-only, idempotent, closed-world behavior, yet the description adds substantial extra context: it performs no registry lookup, stores no personal data, costs $0.05 per successful call, and is paid over x402 (USDC on Base). These are meaningful operational facts not derivable from the annotations or schema.

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

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

Three tightly packed sentences with no filler: purpose first, coverage list second, scope/limitations and pricing last. Every sentence carries information an 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 three-parameter validation tool with full schema coverage and clear annotations, the description supplies the remaining essentials: covered countries, identifier types, the structural-only limitation, and the payment model. No output schema exists, but a boolean-style validation result is self-evident from 'validate ... against checksum rule'.

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 already 100%, so the baseline is 3, but the description adds genuine value for the 'kind' parameter by enumerating which identifier types each country supports (BSN, NIF/NIE/CIF, codice fiscale, SIREN/SIRET, etc.). This helps the agent map country to a valid kind beyond the schema's generic hint.

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 (validate) and resource (national identity, tax or company registration number) and scopes it to a country's official checksum rule. The enumeration of 23 countries and example identifier types clearly distinguishes it from sibling validators like id_gs1 and id_security.

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 clarifies context with 'Structure and check digit only — no registry lookup,' which implicitly tells the agent when this tool is appropriate and when it is not. It does not name a specific alternative tool for registry lookups, so it stops short of explicit routing.

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 annotations already declaring readOnly/idempotent/closed-world, the description still adds material behavioral context: it discloses the return payload (verdict, computed correct character, country prefix, NSIN) and the transaction model ($0.05 per successful call, paid over x402 in USDC on Base). Cost and payment mechanism are behaviors an agent cannot infer from annotations.

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

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

Front-loads the core purpose, then the return values, then the build branch, then scope limits and price. Every sentence carries distinct 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?

No output schema exists, so the description must carry return semantics – and it does, enumerating verdict, corrected check character, country prefix and NSIN. Combined with the cost disclosure and scope limit, 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 100%, so the schema already documents op, value, country and nsin. The description does add the semantic relationship of the build-isin branch (country code + 9-character NSIN), but per the baseline rule with full coverage this remains a 3.

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 specific verbs (validate, build) against named identifier standards (ISIN ISO 6166, CUSIP, SEDOL, FIGI), so the resource is unambiguous. An agent can immediately tell this apart from sibling identifier tools like id_gs1 and id_national.

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?

"Format and checksum only, no security master lookup" clearly delimits the scope of use, telling the agent this is a syntactic validation, not a data retrieval. It does not explicitly name alternative sibling tools, but the domain boundary is clear enough to route correctly.

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 closed-world behavior. The description adds substantial context beyond that: exact-sum guarantee, deterministic remainder distribution, CLDR minor-unit handling for zero- and three-decimal currencies, and a clear price/payment model of $0.05 per successful call over x402.

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 core operation, then layers in remainder behavior, currency nuance, and pricing. It is dense but each sentence adds useful context; only minor tightening would improve it.

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 format. It explains the allocation behavior and exact-sum property but does not state how the shares are returned. Otherwise it is complete enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that the remainder rule is deterministic and named, and by clarifying CLDR minor-unit handling for currencies, which is not captured in the parameter descriptions.

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

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

The description states a specific verb-plus-resource operation: split a money amount into shares using equal parts or ratios. It distinguishes itself from all siblings by being an allocation tool, not a numeric conversion, stats, or formatting utility.

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

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

The description implies when to use the tool by explaining the two allocation modes, equal parts or ratios, and the remainder rules. However, it does not explicitly state when to prefer this tool over any alternative or name a when-not condition.

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 closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: arbitrary precision beyond 2^53, digit validation against the source base, the exact shape of the returned data, and a non-trivial pricing/payment requirement ($0.05 via x402 USDC on Base). The payment model is important operational context an agent should know 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?

Three tight sentences, front-loaded with the core operation and precision guarantee, followed by input acceptance rules and the return overview. The pricing sentence is brief and earns its place given it is a paid call.

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 single-purpose conversion tool with no output schema, the description fully covers what an agent needs: input forms accepted, precision behavior, validation, return contents (target base, decimal, bit length, digit count), and the cost/payment mechanism. Nothing material is left unstated.

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 are already documented in the schema, making 3 the baseline. The description reinforces that a sign and 0x/0b/0o prefixes are accepted and that output includes decimal plus bit length and digit count, but adds no syntax or format detail 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?

States a specific verb and resource ('Convert an integer between any two numeric bases 2 to 36') and immediately scopes it with the arbitrary-precision guarantee. This distinguishes it cleanly from sibling numeric tools like num_stats, num_words, and num_allocate, which operate on very different resources.

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 inputs are accepted and what the output contains, implying the usage context, but never states when to choose this tool versus a sibling or when it is inappropriate. No explicit alternatives or exclusions are named. Adequate but with a clear routing gap.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: the pricing model ($0.05 per successful call over x402 USDC on Base), ddof semantics distinguishing sample vs population forms, and the reproducibility guarantee for percentile interpolation. It omits output format/pagination details, but for a deterministic pure-computation tool this is rich 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?

A single dense but well-ordered sentence front-loads the core purpose and the computed statistics, then layers ddof behavior, interpolation, and pricing. It is long but every clause carries information; minor density could be improved by splitting the parenthetical ddof explanation.

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 enumerating returned fields, which it does comprehensively (including the *_population variants and quartiles). Combined with ddof, method, limits, and pricing, an agent has everything needed to call 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 100%, so the schema already documents ddof, method, values, and percentiles; baseline is 3. The description reinforces ddof's default sample form and the always-population fields, and emphasizes the named interpolation method's purpose, but adds no syntax or format detail the schema 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?

States a specific verb+resource ('Descriptive statistics for a supplied numeric array') and enumerates exactly what is computed (count, mean, median, mode, variance, stddev, quartiles, IQR, skewness, kurtosis, percentiles). It is unambiguous against numeric siblings like num_radix or num_allocate, which serve entirely different purposes.

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

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

The phrase 'in one call' implies the tool consolidates statistics that would otherwise require multiple computations, giving implied context. However, no sibling tool performs statistics, so there is no alternative to route to, and the description states no when-not-to-use conditions or input constraints (e.g. minimum array length).

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 read-only, idempotent, closed-world safety profile, so the bar is lower, and the description adds real value on top: negatives and values up to 10^15 are handled, currency form yields grammatical agreement plus correct minor-unit name/count, and it discloses a billing mechanism ($0.05 per successful call via x402/USDC on Base) — an auth/payment constraint the agent cannot see elsewhere.

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 dense paragraph with no filler; capabilities are front-loaded (languages, forms) before constraints and pricing. Slightly long sentences but every clause carries information an 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 stateless formatting tool with no output schema and full schema coverage, the description covers scope, limits, locale/form constraints and even cost. The only gap is that it never sketches the shape of the returned string, which is minor since no output schema is claimed.

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 tying the currency parameter to grammatical agreement/minor-unit behavior and by revealing that ordinal form is only valid for en, nl, de and fr — a restriction absent from the enum definition itself.

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?

Starts with a precise verb+resource ('Spell a number out in words') and enumerates the 12 supported locales and the cardinal/currency/year/ordinal forms. It is immediately distinguishable from siblings like num_radix, num_allocate and num_stats, which operate on numbers but not natural-language rendering.

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

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

The description gives strong context on applicable forms and constraints (currency form needs the ISO 4217 code; ordinal only exists for four languages) but never states when to pick this tool over a sibling or what to do when the language/form combination is unsupported. Usage is implied rather than routed.

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, closed-world), so the bar is lower, and the description adds genuine value beyond them: the dataset scope ('every airport worldwide that holds a three-letter IATA code and scheduled service'), the explicit exclusion of time zones, what the response contains (matched code type, distance in km), and a per-call price paid over x402 — details nowhere in 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 sentences, front-loaded with the core lookup purpose, followed by scope, return semantics, an exclusion, and pricing. Dense but well-ordered; nearly every clause carries information, though the long first sentence could be split.

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 compensates by describing return contents (name, city, country, region code, coordinates, elevation, distance) and the matched code type, and it flags the time-zone omission and pricing. For a 5-param read-only reference tool this is close to complete, missing only pagination/tie-breaking behavior on proximity results.

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 all five parameters including formats, ranges, and the near-dependency. The description adds only loose prose implying code-vs-near selection and does not contribute syntax or edge-case meaning beyond the schema, so the baseline of 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 and resource — look up an airport by IATA/ICAO code — and clearly enumerates the two modes (code lookup vs. proximity search) plus the fields returned. It is unambiguous about what the tool does, but it never names a sibling (e.g., geo_distance or ref_country) to differentiate itself explicitly.

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 presents the two usage patterns (lookup by code, or search by coordinate and radius), which implies when each mode applies, but gives no explicit guidance on when to choose this tool over alternatives, nor any exclusions beyond the schema's 'Only with near' constraints.

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 safety (readOnly, idempotent, not open-world). The description adds key behavioral facts beyond them: pricing ($0.05 per successful call, paid over x402 USDC on Base), case- and accent-insensitive name matching, and explicit exclusion of ISO 3166-2 subdivisions.

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 verb and resource. Each of the four sentences earns its place: purpose and returns, name-matching behavior, scope limitation, and price. No filler or 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?

Covers inputs, return values (important since no output schema exists), matching semantics, scope, and cost. It omits edge cases such as behavior with multiple name matches or combining code and name, leaving minor gaps for a 3-parameter lookup 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% and the schema already defines code, name, and include. The description restates accepted code formats and return fields but adds no new syntax or constraints beyond what the schema provides, so the 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 ('Look up') and resource ('country or territory'), plus exactly what is returned. The scope note 'Country level only: ISO 3166-2 subdivisions are not included' distinguishes it from subdivision tools, but no sibling tool like ref_currency or ref_nuts is named.

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

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

No guidance on when to use this tool versus alternatives such as ref_currency or ref_nuts. The description only explains what the tool does, not when it is the right choice.

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

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

Annotations already cover read-only, closed-world, idempotent behavior, so the bar is lower. The description adds material context the annotations do not: a per-call price of $0.05 and the x402/USDC-on-Base payment requirement, plus the reassurance that no exchange-rate data is returned.

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 lookup and return contents, then the rounding rationale, then scope and price. Each sentence carries information, though the price/payment sentence could be tighter. No filler or restating of the title.

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 return-value burden and does so by enumerating the returned fields, plus noting the cash-rounding use case and payment model. The one gap is that it never mentions the country-based lookup path offered by the 'country' parameter, which an agent would otherwise have to discover from the schema.

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 all three parameters, which sets the baseline at 3. The description adds nothing about the 'country' selector or the 'include' values (territories, historic) beyond what the schema states, so it does not exceed the baseline.

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 ('look up a currency by ISO 4217 code') and enumerates exactly what facts are returned (alphabetic/numeric codes, name, minor-unit exponent, cash denomination, territories). It also explicitly carves out what it is NOT ('never an exchange rate'), which cleanly separates it from any FX-style sibling.

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

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

Gives clear usage context ('what a caller needs to render or settle a price') and an explicit exclusion ('never an exchange rate'), so an agent knows when this rather than a rate tool applies. It stops short of naming a concrete alternative tool or stating when to prefer the country-based lookup over the code-based one.

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 closed-world, so the safety profile is covered. The description goes beyond structured data by disclosing the cost model ($0.05 per successful call over x402/USDC on Base), the exact classification edition (NUTS 2024), and the returned fields including typologies — 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-loaded with the core action, then capability scope, then returns, then pricing — a sensible order. Three dense sentences with little waste, though the mid-sentence enumeration of capabilities is somewhat packed.

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 summarizes what comes back (Latin-script and local names, country, level, typologies) and adds cost and coverage details. Only minor gaps remain, e.g. behavior on no-match or how many regions exist per level.

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 real meaning: it maps level numbers to their human labels (country, major region, basic region, small region) and names the hierarchy directions (parents/children) that the 'include' parameter controls, which the schema only lists as bare tokens.

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 ('Look up a NUTS statistical region of the European Union') and enumerates the three operating modes: resolve a code, walk up/down the hierarchy, or search by name. This clearly distinguishes it from siblings like ref_country, ref_airport and ref_currency.

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 makes the mode selection clear (code lookup vs. hierarchy walk vs. name search) and states the coverage scope, giving the agent enough context to pick it over siblings. It does not, however, state any when-not conditions or name alternative tools for overlapping needs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower, and the description adds meaningful behavioral context beyond them: a per-call price ($0.05) and the x402/USDC-on-Base payment mechanism, plus the pre-comparison normalisation pipeline. It does not state rate limits, failure behavior on over-length input, or whether the 512-char cap is enforced pre- or post-folding.

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 clause and the long enumeration is dense but informative rather than redundant. Slightly heavy for two sentences, and the pricing/payment sentence could arguably be a separate line, but nothing is wasted.

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 the return shape, and it does so by listing exactly which measures come back, including phonetic keys for each string. Pricing and payment are disclosed. Minor gaps remain on error handling and whether `only` filters affect the returned object structure, but the agent has enough to call 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 coverage is 100%, so the baseline is 3, and the description earns a bump by enumerating the measure names (Levenshtein, Damerau-Levenshtein, Jaro, Jaro-Winkler, LCS, Dice bigrams, Soundex, Metaphone, NYSIIS) – effectively the valid domain for the `only` parameter, which the schema leaves as an opaque “comma-separated measure names.” It also explains what folding does semantically, though it omits the `punct` fold the schema lists.

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?

Names a specific verb and resource (“compare two strings”) and enumerates the exact measures returned, so an agent knows this is the string-similarity tool and not a slug/transliterate/unicode sibling. The scope (every standard similarity measure in one call) 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?

Usage is implied by the description – you call it when you need to compare two strings – but it gives no explicit when-not-to-use guidance, no alternatives among the text_* siblings, and no mention of batching or when to prefer one measure. Nothing is misleading, but routing guidance is thin.

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 and idempotent behavior, yet the description adds substantial context beyond them: deterministic transformation steps (NFD decomposition, transliteration of umlauts/Scandinavian/Turkish/ligatures, separator collapsing, word-boundary truncation), the return shape ('slug plus what was removed'), and a per-call price paid via x402. Pricing and return disclosure are real value-adds not present in annotations.

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

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

Front-loaded with the core purpose, then the transformation pipeline, then options, return value and price. Dense but every clause carries information; only the enumeration of specific letter classes is slightly 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?

With five parameters, no output schema, and annotations covering only the safety profile, the description supplies the missing return contract ('slug plus what was removed') and the payment requirement. Defaults and validation bounds live in the schema, so this is nearly complete 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 100%, so the schema already documents max, case, lang, text and separator fully. The description only restates the option categories ('separator character, maximum length and case preservation') and nods at locale-sensitive folding via the umlaut/Turkish example, adding little beyond the structured fields.

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 (turn text into a URL-safe slug) and details the exact transformations performed. It is clearly distinguishable from siblings like text_transliterate and text_unicode because it commits to producing a slug rather than raw normalization.

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 use case is implied by the transformation description but there is no explicit when-to-use or when-not-to-use guidance, and no sibling (e.g. text_transliterate, text_unicode) is named as an alternative. An agent must infer the boundary 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 declare readOnly, idempotent, and closed-world behavior. The description adds substantial context beyond that: exact return fields, unsupported-script error behavior, and pricing/payment details over x402.

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 action and standards, followed by return values, error behavior, and pricing. Every sentence adds information without 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?

Given a 4-parameter tool with rich schema coverage, annotations, and no output schema, the description covers purpose, supported standards, return contents, error behavior, and payment. Nothing essential is missing 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 100%, so the schema already documents all parameters. The description adds useful semantic distinction between the standards, including ISO 9's one-to-one diacritic behavior and BGN/PCGN's Russian-system scope.

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 (transliterate), source and target scripts (Cyrillic to Latin), and the named standards (ISO 9:1995, BGN/PCGN). An agent can immediately distinguish this from text_slug, text_similarity, and text_unicode.

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

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

Provides clear context: Cyrillic only, with explicit rejection of other scripts via UNSUPPORTED_VALUE. It also explains the two standard choices, but does not explicitly route the agent away from or toward sibling text tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: a per-call price ($0.05 via x402/USDC on Base) and the shape of suspicious-character output (code points, names, imitated ASCII). It stops short of describing pagination or how the 256-entry cap is surfaced.

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 verb and resource, and the three sentences each carry information. The em-dash enumeration of confusable examples is dense but justified; the trailing pricing sentence is logically last but reads slightly bolted-on.

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 return-value burden and does so adequately, explaining per-character detail fields. Combined with annotations covering the read-only nature and the stated cost and caps, an agent has nearly everything needed, missing only explicit routing guidance versus siblings.

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 baseline is 3; the schema already documents form, text and detail with their enums. The description modestly enriches this by spelling out what each normalisation form means in practice and clarifying that 'full' detail returns per-code-point records, though it adds no format syntax beyond what the schema states.

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 (analyse) plus resource (a string at the Unicode level), and it enumerates the exact operations: normalisation forms, script listing, and confusable/homoglyph flagging. An agent can distinguish this from text_similarity, text_slug, and text_transliterate 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?

The use cases are strongly implied (detecting Cyrillic а in Latin words, zero-width joiners, bidirectional overrides), which tells the agent what scenario this serves. However, it never states when to prefer this over sibling tools like text_transliterate or text_similarity, and gives no exclusions or prerequisites.

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 annotations covering the safe-read/idempotent profile, the description still adds substantial non-obvious context: the paid-invocation model ($0.05 per successful call over x402/USDC on Base) and the return payload (result date, day count, first 1,000 skipped dates with reasons). These are behavioral facts an agent cannot infer from annotations or schema.

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

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

Three sentences, front-loaded with the operation set, then the calendar-flexibility rationale, then the return shape and price. No filler sentences and no restating of the title.

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 7-parameter tool with no output schema, the description covers operations, calendar semantics, and the return payload, and even discloses the payment requirement. An agent has everything needed to decide to call it and to interpret results.

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 the schema does not: it motivates the weekday-mask design (Friday-Saturday and Sunday-only weeks) and the explicit holiday list so callers understand why holidays are an argument rather than a table lookup.

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?

Names the specific resource (business-day arithmetic) and both operations (add/subtract N working days, count days between dates), plus the distinguishing detail of a caller-supplied calendar. This clearly separates it from sibling time_calendar and time_rrule.

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?

Explains the two operating modes and the conditions that govern them (op=add vs op=count, mask-driven weekends, explicit holiday list), and gives a rationale for why the answer is stable. It never states when to prefer a sibling tool instead, so it stops 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 cover the safety profile (readOnly, idempotent, not openWorld), so the description's added value is the non-obvious operational facts it discloses: runtime-provided calendar support, the algorithm being named in every response, and a per-call price of $0.05 paid over x402 in USDC on Base. Cost/payment requirements are exactly the kind of thing an agent must know before invoking and would not learn from the schema.

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

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

Two tight sentences that front-load the conversion capability and appendix capabilities (Easter), then close with the billing fact. Nothing is padded, though the long enum-style calendar list makes the first sentence dense.

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

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

With five optional parameters, full schema coverage and no output schema, the definition covers both operations, both target sets and the payment model. It stops short of describing error behavior (e.g. invalid dates, out-of-range years) or the response shape, which it partially compensates for by stating the algorithm is named in every response.

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 real meaning the schema does not: it explains that 'islamic' is the tabular civil calendar while 'islamic-umalqura' is a distinct variant, and that Easter has both Gregorian and Julian (western/eastern) reckonings. It also discloses the response will name the algorithm used, which contextualizes the conversion 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 concrete verb (convert) and resource (Gregorian dates vs. other calendar systems and back), and enumerates the exact target calendars (Islamic tabular vs. Umm al-Qura, Hebrew, Japanese era, ROC, Buddhist, Persian) plus a second capability (Easter in Gregorian and Julian reckonings). No sibling tool overlaps this domain, so the scope is unambiguous on its own.

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 capability statement: use it to convert dates between calendar systems or to compute Easter. There is no explicit when-to-use/when-not guidance and no pointer to adjacent time tools (time_zone, time_business-days), though none of them appear to overlap, so the omission is minor rather than harmful.

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 openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond them: the empty-list-instead-of-error contract for non-DST zones and the $0.05 x402/USDC payment requirement, both of which materially affect invocation.

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 purpose and return shape, and each clause carries information (offsets, jump direction, DST state, next transition, empty-list behavior, price). The pricing sentence is somewhat tangential to selection but is genuinely useful for a paid tool.

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 takes on return-value disclosure and does so thoroughly (transition instants, offsets, jump direction, current state, next transition). It also covers the payment model, so an agent has everything needed to call 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 coverage is 100%, so the schema already documents zone, from, and years including accepted formats and defaults. The description adds essentially no syntax or format detail beyond the schema, so the baseline of 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 (List) and resource (daylight-saving transitions) with explicit output content: shift instants, before/after offsets, and jump direction. An agent can distinguish this from siblings like time_zone or time_calendar 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?

Usage is implied by the scoping ('over a date range', 'from a given instant') but there is no explicit when-to-use guidance or routing to/away from alternatives such as time_zone. The empty-list edge case is stated, but no conditions for choosing this tool over siblings are given.

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 cover the safety profile (readOnly, idempotent, closed-world), and the description adds substantial extra context: return shape (local wall-clock plus UTC instants), the DST gap flag, the evaluation ceiling that causes rejection, and a per-call price paid via x402. These are behavioral traits an agent cannot infer from annotations or schema.

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

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

Five dense sentences, front-loaded with purpose before inputs, limits, and cost. Every sentence carries information, though the enumeration of RRULE parts is slightly list-heavy rather than 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?

With no output schema, the description compensates by describing the return format (local + UTC pairs, gap flag) and the failure mode (evaluation limit). Combined with the pricing disclosure, an agent has everything needed to call this 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by enumerating the supported RRULE components (FREQ, INTERVAL, COUNT, UNTIL, BYDAY, BYMONTHDAY, BYMONTH, BYSETPOS, WKST) and by noting the 200-occurrence cap on count. It omits any explanation of the 'after' parameter, keeping it out of 5 territory.

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

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

The description opens with a precise verb+resource: 'Expand an RFC 5545 recurrence rule into concrete occurrence timestamps.' This clearly separates it from siblings like time_calendar, time_dst, and time_business-days, which handle different temporal concerns.

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 states inputs (RRULE + DTSTART + zone + optional EXDATE/RDATE) and operational limits (max 200 occurrences, rejection above 50,000 candidate evaluations), which tells the agent when the call will succeed. It never names an alternative sibling or an explicit when-not-to-use condition, so it falls 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 declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: explicit handling of ambiguous/skipped DST-boundary times, the exact set of returned values, and a per-call price with the x402/USDC payment mechanism. That payment requirement is a real operational prerequisite not in any structured field.

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 conversion and output inventory, then the DST-edge caveat, then pricing last. Dense but every sentence carries information; the two-direction phrasing is slightly repetitive of the parameter semantics but not wasteful.

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 enumerates the return fields (local date/time, offset in two formats, abbreviation, DST flag, ISO week date, day of year) and warns about DST boundary ambiguity. It is nearly sufficient for correct invocation; only sibling routing against time_dst 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 the schema already documents zone, local, instant and the ambiguous enum, including defaults and mutual exclusivity. The description's mention of ambiguous/skipped local-time handling adds conceptual context but no syntax or format detail beyond the schema, so the 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?

It states a precise bidirectional operation on a specific resource: convert an instant to wall-clock time in an IANA zone, or the reverse. The returned fields are enumerated concretely. It does not differentiate itself from the sibling time_dst, which overlaps on the DST/offset territory.

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 only implied through the mutually-exclusive local/instant modes; there is no explicit when-to-use-this-vs-time_dst or when-not guidance. An agent must infer that this tool stays within a single named zone rather than doing multi-zone DST lookups.

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