Burs-IA Utils

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

Annotations already cover read-only, closed-world, idempotent and non-destructive, so the description's job is to add more — and it does: no network access, no stored state, deterministic output, plus concrete limits (64 KB input, 1 s per call, 1 MB result). The determinism and latency/size ceilings are operationally useful details absent from the annotations.

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

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

Front-loaded with the core purpose and organized under labeled sections (Cuándo / No para / Efectos / Límites), so scanning is easy. The full Spanish and English duplication roughly doubles length for no added information, which keeps it short of a 5.

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

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

A single-parameter, read-only validation tool with an output schema: the description covers scope, exclusions, determinism and resource limits, and the output schema carries the return shape. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: the value must be a 9-digit routing number validated with a 3-7-1 checksum, whereas the schema only says 'string up to 20 chars'. The only small gap is not explaining why maxLength is 20 when 9 digits are expected.

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 ('Valida un número de ruta ABA de EE. UU.') plus the algorithm (9 dígitos, checksum 3-7-1) and the extra output (distrito de la Reserva Federal). It also explicitly names the sibling it is not, iban-validate, so an agent can separate it from the other identifier validators without opening a schema.

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

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

The 'Cuándo' clause gives the triggering condition (verify format and check digit offline before using an identifier) and the 'No para' clause names the excluded case and the alternative tool (iban-validate). Both when-to-use and when-not-to-use are explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds value beyond them: deterministic output for identical input, no network access, no stored state, and concrete limits (64 KB input, 1 s per call, 1 MB result). It does not describe the shape of the returned match, though an output schema exists.

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 core sentences are front-loaded and efficient, but the definition is repeated three times (Spanish body, English body, and an identical inputSchema.description) plus a meta pointer '[EN completo / full EN: inputSchema.description]' that adds nothing. The generic artifact list in 'Cuando' is template filler that does not earn its place.

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

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

For a two-parameter, read-only parsing tool with an output schema, the description covers purpose, exclusion, determinism, resource limits and matching semantics. An agent has everything needed to select and 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 parameter types and bounds are already documented. The description nonetheless adds real semantics the schema lacks: that ordering follows q-value priority and that the matching against 'supported' is exact first, then by primary language — this tells the agent how the optional array actually affects the result.

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 opening sentence names a specific verb and resource: parses an Accept-Language header, sorts by q-value, and picks the best match from supported locales, with the exact-then-primary fallback rule spelled out. It also names the sibling it is not (http-headers-parse). The value is slightly diluted by the boilerplate 'Cuando' list of unrelated artifacts (URL, IP range, HTML document) that applies to the whole suite rather than this tool.

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

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

There is an explicit 'No para' clause naming http-headers-parse as the alternative for raw header blocks, which is real routing guidance. The positive 'Cuando' clause, however, is generic suite-wide boilerplate rather than conditions specific to this tool, so the agent gets one sharp exclusion but a fuzzy inclusion criterion.

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?

While annotations already declare readOnly/idempotent/non-destructive, the description adds context they don't carry: no network, no stored state, determinism guarantee, hard limits (64 KB input, 1 s per call, 1 MB result), and the specific leap-year rule for Feb 29 birthdays. This is substantive behavioral disclosure beyond 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?

Well front-loaded: purpose first, then when/not-for, then side effects, determinism, and limits. However, the Spanish and English blocks duplicate the same content and the trailing 'full EN: inputSchema.description' pointer is padding rather than information.

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

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

For a 2-parameter read-only computation with full schema coverage and an output schema, the description covers everything an agent needs: semantics, sibling disambiguation, edge cases, limits, and determinism. No gaps remain 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema doesn't: as_of is framed as a reference date that is required specifically for determinism, clarifying why both dates are mandatory. It does not add format detail beyond the schema's date/YYYY-MM-DD constraints.

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

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

The first sentence names a specific verb and resource and enumerates the exact outputs: age in years/months/days, days lived, and days until next birthday. It explicitly distinguishes itself from the sibling date-between, so an agent can route without opening either schema.

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

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

Uses explicit 'Cuándo'/'When' and 'No para'/'Not for' framing, naming the exact alternative (date-between) and the condition that selects it (exact date/timezone/calendar results vs. difference between two dates). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/openWorldHint=false/idempotentHint/destructiveHint, but the description adds genuinely new operational facts: no network access, no stored state, determinism, and concrete limits (64 KB input, 1 s per call, 1 MB result). Those limits are the kind of information an agent needs to avoid a failed call and are 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?

The purpose and limits are front-loaded and labeled (Cuándo / No para / Efectos secundarios / Determinista / Límites), which is good structure. However, the Spanish body is followed by a partial English restatement that then defers to '[EN completo / full EN: inputSchema.description]' — pure duplication of the schema description with no new content, which inflates length without adding signal.

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

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

With an output schema present, the description needn't describe return values, and it covers the remaining essentials: read-only nature, no network, determinism, and size/time limits. The only gap is the imprecise 'Cuándo' trigger, which could lead an agent to send an OpenAPI document or a receipt to this tool instead of the dedicated sibling.

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

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

There is a single required parameter with 100% schema description coverage plus an inline example, so the schema largely carries this dimension. The description adds some value by spelling out which fields inside the `card` object are meaningful and by capping the payload at 64 KB, but it does not say what happens for a structurally valid card with unknown extra fields (schema sets additionalProperties=false on the wrapper).

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

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

The description names a specific verb and resource (checks an A2A Agent Card JSON) and enumerates exactly what is inspected: name, description, https url, version, capabilities, default input/output modes, skills, provider and security hints. It also states the boundary 'Structural check only,' which tells an agent this is a lint-style tool, not a protocol conformance or runtime check, and it names the sibling it is not (mcp-tools-lint).

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 an explicit negative case ('No para: revisar definiciones de herramientas MCP (mcp-tools-lint)'), which is the most valuable routing signal here given how many similarly-named lint/validate siblings exist. The positive 'Cuándo' clause is weaker and muddled, sweeping in 'una lista de herramientas, un documento OpenAPI o un recibo' — inputs that actually route to openapi-summary, tool-definition-convert or recibo-verify, so the trigger condition slightly blurs the boundary it just drew.

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?

The description goes beyond the annotations by stating determinism, no network access (implying content must be pasted) and per-call time/result limits, which is real added value. But the '64 KB JSON input' limit contradicts the schema's own maxLength of 2 MB for html and 512 KB for llms_txt, so the stated boundary is untrustworthy.

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 definition restates the same content in Spanish and then again in the schema description, and one whole sentence (the 'Cuándo' clause) is off-topic and misleading. Front-loading is decent, but the redundancy and the misfit sentence dilute the useful parts.

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

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

For a read-only scorer with an output schema, the description covers inputs, behavioral limits and a sibling exclusion. It is incomplete because the usage guidance is wrong for this tool and the input-size limit conflicts with the schema, leaving the agent with inconsistent constraints.

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 every property already documents its type and whether it is optional, so the schema does the heavy lifting. The description adds only the semantic grouping of the three inputs (crawler access vs llms.txt validity vs metadata), which is marginal over the schema.

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

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

The opening sentence names a specific verb (scoring) and resource (AI-agent readiness of a site) and enumerates the evidence it uses: robots.txt, llms.txt, HTML, crawler access, JSON-LD. This is enough to separate it from llms-txt-lint, but the later 'Cuándo: hay que leer, convertir o revisar una descripción de agente, una lista de herramientas, un documento OpenAPI o un recibo' sentence describes a completely different kind of task and muddies what the tool actually does.

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

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

The 'No para: llms-txt-lint' exclusion is genuinely useful routing. However, the positive 'when to use' clause talks about reading/converting agent descriptions, tool lists, OpenAPI documents or receipts — text that appears copy-pasted from another tool and directly conflicts with the stated purpose, so an agent following it would call this tool for the wrong inputs.

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?

Adds real context beyond the annotations: determinism, no network, no stored state, and concrete operational limits (64 KB JSON input, 1 s per call, 1 MB result). The read-only/idempotent statements duplicate readOnlyHint/idempotentHint, but the limits and offline/deterministic guarantees are genuinely new information.

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 opening Spanish sentence is well front-loaded, but the description then repeats itself in a full English block and ends with a truncated dangling fragment "[EN completo / full EN: inputSchema.description]", which is noise rather than signal. The bilingual duplication roughly doubles length for the same 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 one required parameter, full schema coverage, rich annotations, and an existing output schema, the description covers the remaining gaps (offline, deterministic, limits, sibling exclusion). The only shortfall is the over-broad "LatAm o España" scope claim, which slightly undercuts routing accuracy.

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 single `cbu` parameter is already documented with type, maxLength, and an example. The description still adds meaning by explaining what the input is decomposed into (3-digit bank + 4-digit branch + check digit, 13-digit account + check digit) and that only validation, not normalization, occurs.

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 ("Valida una CBU/CVU argentina de 22 dígitos") and even names the internal block/check-digit structure it verifies. It explicitly rules out the sibling ar-cuit-validate, so an agent can distinguish it without opening either schema.

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

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

Provides an explicit "Cuándo" trigger (offline check of a user-supplied account/document number before storing or using it) plus a "No para" exclusion naming ar-cuit-validate. However, the stated scope "LatAm o España" is broader than the tool's actual Argentina-only CBU/CVU check, which could misroute an agent holding an IBAN, Mexican CLABE, or Spanish DNI.

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 carry readOnly/idempotent/openWorld/destructive hints, so the bar is lower; the description nonetheless adds useful operational detail (no network, no stored state, deterministic output, 64 KB input / 1 s / 1 MB limits). Some of the safety wording restates what the annotations declare, keeping it just short of a 5.

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

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

Front-loaded with what the tool does, then when/not-for/effects/limits, one line each. The bilingual duplication with a pointer to the schema's EN text is slightly redundant but compact and well-structured.

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

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

An output schema exists, annotations cover safety, and the description fills the remaining gaps an agent needs: determinism, offline behavior, size/time limits, and the sibling it must not be confused with. Nothing material is missing for a single-param validator.

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 the single 'cuit' parameter is documented with type, length and an example. The description adds algorithm context (weights 5432765432) rather than input-format guidance, so it adds little beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource with technical specificity (11 digits, prefix type, mod-11 check digit with weights) and explicitly differentiates from the sibling ar-cbu-validate (22-digit CBU/CVU). An agent can select this over near neighbors without opening a schema.

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

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

Uses explicit 'Cuándo/When' and 'No para/Not for' sections, naming the exact alternative tool (ar-cbu-validate) and the condition that selects it. It also gives the concrete context (offline pre-storage check of user-supplied IDs).

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

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

Annotations already declare read-only, non-destructive, idempotent and closed-world, but the description adds real value beyond them: deterministic output, no stored state, and concrete limits (64 KB input, 1 s per call, 1 MB result). It does not repeat the annotation fields verbatim, so no contradiction.

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 core action is front-loaded and the labeled sections (Cuándo / No para / Efectos / Límites) make scanning easy. It is somewhat verbose and the full bilingual duplication doubles length, but every section carries information rather than padding.

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

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

For a two-parameter, deterministic utility, the description covers purpose, alternatives, side effects and resource limits, and an output schema exists so return values need not be explained. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema; the baseline is 3. The description's note that the last chunk may be shorter adds marginal semantic detail about the size parameter, but it doesn't explain formats or edge cases further.

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 ('Divide un arreglo en bloques de tamaño fijo') with the concrete purpose of batching, and explicitly names the sibling it is not (array-sort). An agent can distinguish it from other array tools 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?

Provides an explicit 'Not for' clause routing the agent to array-sort, which is strong. The positive 'Cuándo' guidance is broad ('transform, compare or check structured data exactly') and doesn't discriminate against other array siblings like array-flatten or array-group-by, 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/openWorld/idempotent/destructive, but the description goes beyond them with concrete limits (64 KB input, 1 s per call, 1 MB result) and determinism, which annotations cannot express. These are operationally important for an agent deciding whether to 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?

Content is dense and front-loaded: purpose first, then when/not-for, side effects, determinism, limits. The only cost is full bilingual duplication, which roughly doubles length without adding information.

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

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

An output schema exists, so return values needn't be explained; annotations cover safety; the description still supplies limits, determinism, and the sibling alternative. Nothing an agent needs to call correctly is missing.

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

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

Schema coverage is 100%, so both parameters are documented structurally. The phrase 'or of a key's value' clarifies what `by` does beyond the schema's own description, but the gain over the schema is marginal (no dotted-path semantics, ordering interaction, or edge-case notes added).

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 action: counts occurrences of each distinct value (or a key's value), sorted descending. Explicitly distinguishes from the sibling array-group-by, so an agent can choose between them without opening schemas.

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

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

Gives an explicit 'When' (structured data that must be transformed, compared, or checked exactly) and an explicit 'Not for' pointing to array-group-by with the differentiator (returning groups and counts). This is textbook when/when-not/alternative guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds non-redundant operational context: hard limits (64 KB input, 1 s per call, 1 MB result), deterministic output, and that first-occurrence order is preserved. It does not add anything contradictory; determinism partly restates idempotentHint, which keeps it just short of 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?

Content is front-loaded and well segmented (purpose, when, not-for, side effects, determinism, limits), but the entire block is duplicated in Spanish and English, roughly doubling length with zero added information. The English half alone would merit a 5; the duplication is pure structural cost.

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 2-parameter, read-only array tool with an output schema, the description covers everything the agent needs: purpose, sibling boundary, purity guarantees, determinism, and hard size/time limits. Output formatting is covered by the output schema, so its absence from the description is not a gap.

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

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

Schema coverage is 100%, so the baseline would be 3. The description earns above baseline by explaining the comparison semantics that the schema cannot: default is deep equality via canonical JSON, while `by` switches to key-based comparison — that meaningfully disambiguates the optional `by` parameter, though it adds no new information about the `items` shape.

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 ("Elimina elementos duplicados") plus the two comparison modes (deep equality / by key) and the retention rule (keeps first occurrence, preserves order). It explicitly contrasts itself with the nearest sibling, dedupe-similar, so an agent can select between them without opening either schema.

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

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

Uses an explicit "Cuándo:/When:" clause naming the data shapes it is meant for (JSON, CSV, YAML, XML, arrays) and an explicit "No para:/Not for:" clause routing near-duplicate string grouping to dedupe-similar. Both the include and the exclude condition are stated, which is the top of the scale.

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

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

Beyond annotations (read-only, idempotent, non-destructive, closed-world), it states no side effects, no network, no stored state, deterministic output, and hard limits: 64 KB input, 1 s per call, 1 MB result. These are operationally useful disclosures and do not contradict the annotations.

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

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

The description is front-loaded and structured into purpose, usage, side effects, determinism, and limits. It loses some conciseness by repeating the same information in Spanish and English, though each block remains readable.

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

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

With annotations covering safety semantics and an output schema present, the description supplies the remaining operational context: scope, exclusions, determinism, side effects, and execution limits. Nothing essential for correct invocation 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 all eight parameters. The description lists operators and aggregates, but these largely mirror schema enums and field descriptions; it adds little syntax or edge-case guidance beyond 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?

The description opens with a specific verb sequence—filter, group, and aggregate—over an array of objects, and explicitly contrasts itself with array-group-by. This lets an agent identify the tool precisely versus sibling array utilities 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 'Cuándo' for structured data transformations and an explicit 'No para' pointing to array-group-by for key-based grouping and counts. The alternative condition is clear enough to route between 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 read-only, non-destructive, idempotent, and closed-world behavior. The description adds useful context beyond annotations: no network access, no stored state, deterministic output, and concrete limits (64 KB input, 1 s per call, 1 MB result).

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

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

The content is front-loaded and clearly segmented into purpose, when to use, when not to use, side effects, determinism, and limits. It is longer than strictly necessary because the same information is provided in both Spanish and English, but the structure is efficient and every section is useful.

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

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

Given that an output schema exists and the input schema is fully covered, the description provides everything else an agent needs: use cases, exclusions, side-effect profile, determinism, and operational limits. There is no significant missing context 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 coverage is 100%, so the schema already documents both parameters, including depth defaults and constraints. The description adds some useful semantics such as defaulting to full flattening, but does not need to explain parameters further and largely leaves this to the schema.

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

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

States a specific verb and resource: flattens nested arrays to a given depth. It also clearly distinguishes itself from json-flatten-paths by naming the sibling and the exact behavior it does not implement.

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

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

Explicitly gives the 'when' context (transforming, comparing, or checking structured data such as JSON, CSV, YAML, XML, arrays) and a 'not for' case that routes the agent to json-flatten-paths. This is actionable guidance without ambiguity.

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?

Adds real behavioral context beyond the annotations: the null bucket for missing keys, determinism, and concrete operational limits (64 KB input, 1 s per call, 1 MB result) that the annotations do not carry. Some sentences (read-only, no network, no stored state) merely restate readOnlyHint/openWorldHint, but the limits and null-handling are genuine additions and nothing conflicts with the declared hints.

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

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

Front-loaded and well-structured: purpose, when/not-for, side effects, determinism, and limits in labeled clauses. The bilingual duplication doubles the token cost with identical content, which is defensible for a Spanish-titled tool but is still redundancy rather than efficiency.

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

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

An output schema covers return values, the annotations cover safety and idempotency, and the description fills the remaining gaps an agent needs: which sibling to prefer, what happens to missing keys, size/time bounds that could cause failure, and determinism. Nothing material is left unspecified.

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 the schema already documents `by` as a dotted-path key and `items` as a required array, so the description is largely restating structured data. It does clarify that a missing path yields a "null" group, which is the only semantics added beyond the schema — 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 and resource (groups objects by the value of a key) plus the exact output shape (object of arrays plus group counts) and the edge case (missing keys fall under "null"). It also explicitly names the sibling array-count-by as the thing it is not, so an agent can distinguish the two without opening either schema.

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

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

Provides an explicit "Cuándo/When" clause and a hard exclusion ("No para: contar las apariciones… array-count-by"), which is more than most definitions offer. The positive when-to-use clause is broad enough to apply to many array tools, so it stops short of a full 5, but the routing to the alternative is unambiguous.

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?

The description's side-effect, determinism, and no-network statements align with the annotations (readOnlyHint, idempotentHint, openWorldHint=false) rather than contradicting them. It adds genuinely new operational context the annotations do not carry: 64 KB input cap, 1 s per call, and 1 MB result cap, which are important for planning large batches.

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 cleanly labeled (When / Not for / Side effects / Deterministic / Limits), so an agent can scan for the relevant clause. The full bilingual duplication roughly doubles the length, which is a deliberate accessibility trade-off but not free.

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

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

For a 3-parameter pure transform with an output schema, the definition covers scope, alternative routing, safety profile, determinism, and hard resource limits. Nothing an agent needs to invoke it correctly is missing, and return-value shape is rightly left to the output 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 coverage is 100%, so the baseline would be 3, but the description adds behavior the schema only implies: missing values become null or are dropped, which explains the effect of drop_missing rather than just its type. Dotted-path keys are reinforced in prose, though no extra format or escaping rules are given.

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

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

States a specific verb and resource: extracts the value at a key (dotted path) from every object in an array, including null/drop semantics for missing keys. It explicitly contrasts itself with array-group-by, so an agent can distinguish it from the other array-* siblings without opening a schema.

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

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

Contains explicit 'Cuándo/When' guidance (transform, compare, or check structured data exactly) and an explicit 'No para/Not for' clause naming the alternative tool array-group-by and the exact behavior that belongs to it. No inference is required to pick between them.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the description only needs incremental detail — and it delivers: hard limits (64 KB JSON input, 1 s per call, 1 MB result), determinism, and the deep-equality/order-preservation semantics of the comparison. A 4 rather than 5 because it does not say what happens when a limit is exceeded (truncation vs. error).

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 operation list and organized into labeled clauses (When / Not for / Side effects / Deterministic / Limits), which is easy to scan. Slightly penalized for full Spanish/English duplication, which doubles length for the same 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?

An output schema exists, so return values need no prose. The description covers the operation set, comparison semantics, safety profile, determinism, and resource limits — everything needed to invoke correctly and predict behavior.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: elements are compared by deep equality, output order follows first-seen order, and difference is directional (a−b). That last point matters because the enum alone lists 'difference' without stating orientation.

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, enumerates the four supported operations (union, intersection, difference, symmetric difference), and specifies deep equality plus first-seen order preservation. It explicitly names the sibling array-dedupe as the thing it is not, so an agent can separate the two without opening schemas.

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

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

Has explicit 'Cuándo/When' and 'No para/Not for' clauses, and names the alternative tool (array-dedupe) with the condition that selects it. Nothing about when to reach for this versus a sibling is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and idempotentHint=false, so safety is covered structurally. The description adds genuinely new behavioral context beyond that: secure randomness, non-determinism unless a seed is supplied, and hard limits (64 KB input, 1 s runtime, 1 MB result) -- useful operational facts an agent cannot read from the annotations.

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

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

The content is front-loaded and cleanly sectioned (Cuándo / No para / Efectos secundarios / Límites), so nothing is buried. However, the full Spanish text is repeated verbatim in English, roughly doubling length without adding information.

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

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

Given an output schema exists (no need to describe return values), full parameter coverage, and complete annotations, the description still supplies the missing pieces an agent needs: randomness/determinism behavior and size/time limits. Nothing material is absent 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 coverage is 100%, so the baseline is 3, but the description goes further: it explains that supplying a seed makes output reproducible and that sample_size means 'k elements without replacement' -- semantics the terse schema descriptions ('Return only k items') do not convey. That added meaning justifies exceeding 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: shuffles an array via Fisher-Yates or draws a k-item sample without replacement. It explicitly contrasts with array-sort ('No para: ordenar un arreglo...'), so an agent can distinguish it from the nearest sibling without opening either schema.

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

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

Provides an explicit 'Cuándo' section describing the triggering context (transforming/comparing/checking structured data like JSON, CSV, YAML, XML, arrays) and an explicit 'No para' exclusion pointing at array-sort. Both the positive and negative selection conditions are stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further with concrete operational limits (64 KB input, 1 s per call, 1 MB result), determinism guarantee, and no-state/no-network confirmation. These are useful traits an agent cannot derive from the annotations alone.

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 verb and behavior, and each sentence (when, not-for, side effects, determinism, limits) earns its place. However, the full ES/EN duplication roughly doubles the length for the same content, which slightly hurts conciseness.

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

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

Output schema and annotations handle return format and safety profile, while the description covers scope, limits, ordering semantics, and determinism. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic value beyond the schema: the 'stable' guarantee, 'numbers before strings', and 'locale-aware natural string comparison' clarify sort behavior. It doesn't add much on the `by`/`order` parameters themselves, which the schema already documents.

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 (sorts), resource (array of values or objects), and distinguishing behavior (stable, ascending/descending, numbers before strings, locale-aware natural comparison). It explicitly names the sibling it is not for (lines-sort), so the agent can tell it apart without opening either schema.

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

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

Explicit 'When' clause lists the concrete data shapes (JSON, CSV, YAML, XML, arrays) suited for it, and an explicit 'Not for' clause routes line-collation tasks to lines-sort. Both the positive and negative selection conditions are stated.

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/openWorldHint/idempotent/destructive, so the "side effects: none" sentence largely repeats structured data. The description does add genuinely new behavioral context: the z shorthand and delimiter tolerance, determinism, and hard limits (64 KB input, 1 s per call, 1 MB result) that the agent cannot infer 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?

Each individual language version is tight and front-loaded, but the full text is duplicated verbatim in Spanish and English, roughly doubling the token cost for a simple two-parameter codec. Nothing is wasted within a language, yet the overall payload is larger than necessary.

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

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

An output schema exists, so return values need no explanation. With purpose, exclusion, determinism, side-effect profile, and concrete size/time limits all present, an agent has everything required to call this correctly and to predict failure modes.

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 baseline is 3. The description goes slightly beyond the schema by explaining accepted Ascii85 variants (delimiters optional, z shorthand), which matters for formatting the `ascii85` argument, though it says nothing about `output_encoding` beyond what the enum already documents.

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 ("Decodifica Ascii85") and immediately qualifies the accepted input forms ("con o sin <~ ~>", z shorthand). It explicitly names the inverse sibling ascii85-encode, so an agent can distinguish the two without opening a schema.

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

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

Has an explicit "Cuándo/When" and a "No para/Not for" that routes encoding work to ascii85-encode. The only blemish is that the When clause says bytes must be converted "to or from" this encoding, which momentarily implies both directions; the Not-for line resolves it, so the guidance is clear but not perfectly airtight.

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?

Goes well beyond the annotations by disclosing concrete limits (64 KB JSON input, 1 s per call, 1 MB output), determinism, and the 'z for zero groups' variant behavior — all operationally relevant. The 'no side effects / no network / no stored state' sentence largely restates readOnlyHint, openWorldHint and destructiveHint, which keeps this from 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?

Each language version is tightly front-loaded (variant first, then when/not-for, then side effects, limits), which is good structure. However, the description duplicates the entire content verbatim in Spanish and English, roughly doubling length without adding information.

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

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

For a pure-function encoder with an output schema and full annotation coverage, everything needed to invoke it correctly is present: variant semantics, delimiter behavior, input limits and determinism. Return values are covered by the output schema, so no gap remains.

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 data, delimiters and input_encoding are already fully documented in the schema, making 3 the baseline. The description adds only the meaning of the <~ ~> wrapper and the Adobe/z behavior, and says nothing about when to pick input_encoding=hex versus utf8.

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 plus the exact variant: 'Codifica bytes en Ascii85 (variante Adobe)' and in EN clarifies 'Adobe/btoa variant, z for zero groups'. The agent can immediately distinguish it from ascii85-decode and from base64/hex siblings because both the resource and the flavor of Ascii85 are 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?

Gives an explicit 'Cuándo' (convert bytes/text to or from this encoding, exactly) and an explicit 'No para: decodificar Ascii85 (ascii85-decode)' that names the alternative tool. The only flaw is the phrase 'o desde ella' (or from it), which hints at round-tripping and slightly muddies the otherwise clean encode-vs-decode boundary.

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

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

Annotations already declare read-only, non-open-world, idempotent, and non-destructive behavior. The description adds important context beyond annotations: no network, no stored state, deterministic output, and concrete limits of 64 KB input, 1 second per call, and 1 MB result.

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

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

The content is front-loaded and every major section is useful, but the description is duplicated in Spanish and English and ends with an odd pointer to inputSchema.description. The bilingual repetition makes it longer than necessary for a tool whose schema already carries detailed parameter documentation.

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

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

The tool has an output schema, complete parameter descriptions, and rich annotations; the description still supplies the remaining context an agent needs: purpose, alternatives, determinism, side effects, and execution limits. Nothing essential for correct invocation 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?

The input schema has 100% description coverage for all seven parameters, including defaults, ranges, and enums. The description usefully names the backoff strategies and jitter modes, but it mostly restates schema-level semantics rather than adding parameter-specific detail beyond it.

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

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

The description states a specific verb and resource: computes retry delays for exponential, linear, or constant backoff, with cap and optional jitter, plus cumulative wait. It explicitly distinguishes itself from the sibling retry-after-parse, so an agent can route correctly without opening either schema.

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

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

It provides explicit when-to-use guidance for an agent loop needing exact, repeatable bookkeeping results. It also names the specific alternative, retry-after-parse, and states when not to use this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so restating 'read-only, no network, no stored state' adds little. The genuinely new information is the parsing tolerance (case-insensitive, padding and spaces optional), determinism and the operational limits (64 KB input, 1 s, 1 MB result), which are useful but the description spends half its behavioral budget duplicating annotation content.

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 action, then When / Not for / Side effects / Deterministic / Limits in a scannable pattern. It is however presented twice, in Spanish and English, which roughly doubles length without adding information for an English-reading agent.

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

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

For a two-parameter decoder with an output schema already defining return values, the description covers direction, alternatives, tolerance rules and hard limits. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so both parameters are documented structurally and the 3 baseline applies. The description adds meaning the schema lacks: that the input is parsed case-insensitively with optional padding and spaces, and that output_encoding governs how decoded bytes are rendered.

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 (decode RFC 4648 Base32) plus the concrete output targets (UTF-8 text, hex, base64). It also names the sibling it is not (base32-encode), so an agent can distinguish it without opening either schema.

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

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

Explicit 'When' clause and explicit 'Not for' exclusion pointing at base32-encode as the alternative, covering both directions of conversion. Routing guidance is complete with no inference required.

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, openWorldHint=false and destructiveHint=false, yet the description still adds real value: it spells out no side effects, no network, no stored state, determinism, and concrete limits (64 KB input, 1 s per call, 1 MB result) that 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?

Front-loaded with the core statement and cleanly structured with When / Not for / Side effects / Deterministic / Limits labels. The full Spanish-then-English duplication doubles the length, which is a real cost even though each language block is disciplined.

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 small pure-function tool with an output schema, full annotation coverage and 100% parameter documentation, nothing an agent needs to invoke it correctly is missing; limits and determinism round out the operational picture.

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 would be 3, but the description adds meaning: it clarifies the RFC 4648 alphabet (A-Z, 2-7) and that the input may be text or hex bytes, which maps to the input_encoding enum, plus optional padding. It does not, however, discuss when to pick utf8 vs hex or padding=false.

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: encodes text or hex bytes as RFC 4648 Base32 (A-Z, 2-7) with optional padding, plus a concrete use case (TOTP secrets). It explicitly names the sibling it is not (base32-decode), so an agent can distinguish it without opening either schema.

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

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

Provides explicit routing: 'Not for: decoding RFC 4648 Base32 (base32-decode)' and a 'When:' clause about exact conversion. The only flaw is the reciprocal phrase 'convert to or from this encoding', which slightly blurs the encode-only boundary that the exclusion then corrects.

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?

Goes well beyond annotations by disclosing the 4-byte double-SHA-256 checksum verification, that the first byte is interpreted as version, determinism of output, and hard limits (64 KB JSON input, 1 s per call, 1 MB result). Read-only/no-network/no-stored-state is stated but is already covered by readOnlyHint and openWorldHint, so the added limits carry the score.

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?

Each language version is front-loaded and efficiently structured with labeled When/Not-for/Side-effects/Limits. However the full text is duplicated in Spanish and English, roughly doubling length without adding information; a tighter single-language-plus-gloss would score higher.

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

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

An output schema exists so return shape needn't be explained, yet the description still notes payload plus version byte. With limits, determinism, and the encode alternative all covered, 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 coverage is 100% with a single documented required parameter including an example, so the schema already does the work. The description adds nothing parameter-specific (e.g. no note on whitespace, length limits below the 4096-char schema cap, or what an invalid checksum yields), 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+resource (decode Base58Check, verify checksum, return payload and version byte) and names the sibling it is not (base58check-encode). An agent can distinguish it from base58-decode and base58check-encode without opening either schema.

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

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

Explicit "Cuándo" and "No para" sections, with base58check-encode named as the alternative. Minor deduction: the When clause says bytes/text must be converted "a esta codificación, o desde ella", which half-describes the encode direction and muddies the boundary versus base58check-encode and base58-decode.

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, and the description reinforces them while adding genuinely new context: determinism, the 64 KB input cap, 1 s per-call budget and 1 MB result cap. It stops short of describing the output shape, but an output schema exists, so this is close to complete.

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?

Information is front-loaded—algorithm first, then when/not-for, then side effects and limits—and every sentence carries content. The cost is that the entire block is duplicated in Spanish and English, roughly doubling length for a single-language reader.

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 one-parameter deterministic encoder with an output schema, this covers everything an agent needs: algorithm, when to use, the sibling alternative, safety profile, determinism and operational limits. Nothing material is left to inference.

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

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

Schema coverage is 100% and the schema already documents payload_hex, its pattern, max length and the 'including version byte' nuance. The description's note about 'including any version byte' adds emphasis but no new syntax or format information, 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 specific verb and resource plus the exact algorithm (append 4 bytes of double SHA-256, then Base58), so the agent knows precisely which transformation happens. It also distinguishes itself from base58check-decode and, implicitly, from plain base58-encode by naming the checksum step.

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?

Explicit 'Cuándo' plus an explicit 'No para' clause naming base58check-decode as the alternative for decoding/verifying checksums. Both the use case and the exclusion route the agent unambiguously.

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?

The annotations already declare read-only, idempotent, non-destructive behavior, and the description adds concrete operational details: no network access, no stored state, deterministic output, and specific limits (64 KB JSON input, 1 s per call, 1 MB result). These details materially help an agent invoke the tool safely and predictably.

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 information is organized with labeled sections and is front-loaded with the purpose. It is somewhat longer than necessary because the Spanish and English versions duplicate the same content, but the structure remains clear and useful.

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

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

The tool has an output schema and rich annotations, so the description need not explain return values or safety basics. It covers the important limits and side effects, though it could be slightly more complete by mentioning Base58Check as a neighboring alternative.

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 useful input-format context by specifying the Bitcoin Base58 alphabet and names the output encodings, but most parameter meaning is already fully documented in the schema.

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

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

The description states a specific verb and resource: decode Base58 using the Bitcoin alphabet into hex, UTF-8 text, or base64. It explicitly distinguishes itself from the sibling base58-encode tool, so an agent can identify the operation 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 an explicit exclusion (not for encoding; use base58-encode) and a general usage context. However, the Spanish/English phrasing 'a esta codificación, o desde ella' / 'to or from this encoding' is slightly ambiguous for a decode-only tool, and it does not mention the related base58check-decode alternative.

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, openWorldHint=false and destructiveHint=false, so the safety profile is largely covered by structured data. The description still adds useful non-redundant context: determinism, no network/stored state, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result). That is solid but mostly restates what the hints imply, so it sits below the top band.

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?

Content is front-loaded and every clause is substantive (when/not-for/limits), but the entire description is duplicated in Spanish and English, roughly doubling length for an agent that only needs one. The redundancy costs efficiency even though 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?

Return values are covered by an existing output schema, and the description supplies the remaining context an agent needs: determinism, size/time/output limits, and the leading-zero edge case. Nothing material 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% and both parameters (data, input_encoding) are documented in the schema, so the baseline is 3. The description adds only the rough input size bound (2 KB) and the notion of text-vs-bytes, but does not explain the utf8/hex switch or its default beyond what the schema already says.

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 (encode bytes to Base58 with the Bitcoin alphabet) and adds a distinguishing behavioral detail: leading zero bytes become leading 1s. It names the sibling it is not (base58-decode) and is easily separated from base58check-encode and the other base-N encoders.

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?

Explicit 'When:' clause (convert bytes/text to this encoding exactly) and explicit 'Not for:' clause routing decoding to base58-decode. Alternatives and the exclusion condition are both stated, leaving nothing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds genuinely new behavior: invalid characters are rejected, padding is optional, whitespace is ignored, plus concrete limits (64 KB JSON input, 1 s per call, 1 MB result). That is exactly the kind of constraint an agent cannot get from the annotation block.

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 verb and resource, then clearly labeled Cuándo / No para / Efectos / Determinista / Límites sections that each carry distinct information. Cost is the full bilingual duplication, and 'Determinista' largely repeats the idempotentHint annotation.

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

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

For a two-parameter pure function with an output schema and full annotation coverage, the description covers input tolerance, error rejection, size/time limits and side-effect freedom — everything needed to invoke it correctly. Return-value shape is correctly left to the output 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 coverage is 100%, so baseline is 3, but the description adds semantics the schema lacks: whitespace in the input is ignored and out-of-alphabet characters are rejected, which tells the agent how leniently to clean input before calling. It also confirms the three output encodings, though the Spanish half omits the 'base64' output option.

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: decodes standard or URL-safe Base64 into UTF-8 text, hex or base64, and explicitly names base64-encode as the thing it is not. It does not address the very close sibling base64url-decode, so the agent still has to infer when this tool versus that one applies.

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 an explicit 'Cuándo' and 'No para' pair with a named alternative (base64-encode), which most siblings lack. However the 'when' clause is muddled ('convertir bytes o texto a esta codificación, o desde ella'), describing both directions for a one-directional tool, and never mentions base64url-decode or ascii85/base32/base58 decode siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description still adds real information: no network access, no stored state, deterministic output, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result). Those limits and the determinism guarantee are exactly the operational facts an agent needs and cannot get from the annotations.

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

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

Front-loaded with the action, then labelled sections (When / Not for / Side effects / Deterministic / Limits), so scanning is easy. It is however duplicated verbatim across Spanish and English, roughly doubling length for a two-parameter tool, even if every individual sentence carries 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 an output schema present and rich annotations, the description needs only the operational envelope — and it supplies it: accepted input forms, RFC variant, determinism, absence of side effects, and size/time ceilings. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema coverage is 100%, so the enum values and default are already documented; the description adds only that text is interpreted as UTF-8. The EN text says 'hex/base64 bytes' as valid input while the schema enum permits only utf8 and hex, which mildly misleads about what 'data' may contain.

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 (encode text/bytes to standard Base64, RFC 4648 §4, with padding) and immediately names the sibling it is not (base64-decode), plus the URL-safe variant is implicitly excluded by 'Base64 estándar'. An agent can distinguish it from base64url-encode and base64-decode 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?

Explicit 'Cuándo' and 'No para' clauses with a named alternative (base64-decode), which is stronger than most definitions. The one flaw is the 'o desde ella' / 'to or from this encoding' phrasing, which suggests decoding is also in scope and sits awkwardly against the explicit 'No para: decodificar Base64' exclusion.

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, openWorldHint=false, idempotentHint, and destructiveHint=false. The description adds useful behavior beyond those annotations: deterministic output, no network or stored state, optional padding handling, and explicit input/time/result limits. It does not cover invalid-input behavior, but the added operational constraints are substantial.

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 content is well-structured and front-loads purpose, usage, side effects, and limits. However, the full description is duplicated in Spanish and English, which doubles the length without adding new information for an agent and works against conciseness.

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

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

Given the output schema, full parameter schema coverage, and rich annotations, the description supplies everything else an agent needs: purpose, alternative routing, determinism, side effects, and operational limits. No critical invocation guidance 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 both parameters. The description adds meaningful semantics beyond the schema, notably RFC 4648 §5 and optional padding for the input, plus the available output encodings. This is useful but not strictly necessary given the complete schema.

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

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

The description states a specific verb and resource: decoding URL-safe Base64 to UTF-8, hex, or base64. It distinguishes itself from the sibling encoder by explicitly naming base64url-encode as the not-for alternative. An agent can identify the tool's purpose 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 provides explicit when-to-use guidance ('bytes or text have to be converted to or from this encoding exactly') and explicit when-not-to-use guidance, naming the sibling alternative base64url-encode. The routing condition between encode and decode is unambiguous.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety recap is redundant. The description earns credit for the operational limits not in structured fields: 64 KB JSON input, 1 s per call, 1 MB output ceiling, plus explicit determinism.

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 definition, then labeled sections for when/not-for/side effects/limits, which is easy to scan. It is however fully duplicated in Spanish and English, roughly doubling length without adding information for a single reader.

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

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

With an output schema present the description needn't explain return values, and annotations plus full schema coverage handle safety and parameters. Determinism and size/time limits close the remaining gaps an agent would need before calling.

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% with an enum on input_encoding and defaults documented, so the schema carries parameter semantics fully. The description only loosely gestures at bytes-vs-text, adding no format or validation detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource with the exact variant (URL-safe Base64, RFC 4648 §5, no padding, JWT usage), which is exactly what distinguishes it from sibling base64-encode. An agent can route between the base64 family without opening schemas.

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

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

Explicitly names when to use it and names the excluded alternative (base64url-decode) in a labeled 'Not for' clause. Minor internal noise: 'convertir bytes o texto a esta codificación, o desde ella' ('or from it') blurs the boundary the next sentence draws, but the exclusion is clear enough to act on.

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, destructiveHint=false and openWorldHint=false, so the description's 'no side effects, deterministic' lines largely restate them. It does add genuinely new behavioral context: the security caveat that Basic auth is base64, not encryption, and requires HTTPS, plus concrete limits (64 KB input, 1 s per call, 1 MB result). Those additions are real but modest for a pure-function tool.

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

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

Purpose is front-loaded and the security caveat is well placed, but the entire body is duplicated in Spanish and English, roughly doubling length for zero added information. The trailing '[EN completo / full EN: inputSchema.description]' pointer is noise that points at text the agent already has.

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

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

An output schema exists, so return values need not be explained, and both params are covered by the schema. Purpose, security posture, determinism, and resource limits are all stated, which is ample for a two-string pure function. The remaining gap is that the 'When' section is generic boilerplate rather than describing real usage scenarios.

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 fully documented and the no-colon username constraint lives in the pattern. The description adds the RFC 7617/UTF-8 framing, which affects how the output is encoded, but no additional per-parameter meaning. Baseline 3 applies when the schema does the heavy lifting.

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

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

Names a specific verb and resource — 'Builds an HTTP Basic Authorization header value from a username and password (RFC 7617, UTF-8)' — so an agent knows exactly what it produces. Sibling differentiation is thin: the only named alternative is jwt-sign-hmac, which is far from the nearest neighbors (base64-encode, url-build), and the 'When' clause lists unrelated 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 'When:' clause is boilerplate that does not describe this tool's use case — it talks about parsing URLs, IP ranges, and HTML/Markdown documents, which this tool does not do. The only real routing signal is 'Not for: signing a JWT with an HMAC secret (jwt-sign-hmac)', which is accurate but points at a distant sibling. An agent gets no guidance on when a Basic header is the right thing versus e.g. base64-encode.

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, destructiveHint=false and openWorldHint=false, so the description's 'read-only, no network, no stored state' largely restates them. What it genuinely adds beyond structured data are concrete operational limits (64 KB JSON input, 1 s per call, 1 MB result) and the determinism guarantee, which are useful for call planning.

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 structure is excellent — purpose first, then When / Not for / Side effects / Deterministic / Limits — and every sentence carries information. The only cost is full duplication in Spanish and English, which roughly doubles length for a single-parameter 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?

An output schema exists, so return values need not be explained, and the description still adds limits, determinism, side-effect profile and the sibling alternative. For a one-parameter decoder, nothing an agent needs to call it correctly is missing.

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

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

With a single parameter at 100% schema description coverage, the schema already documents the input fully (type, maxLength 1023, example). The description adds no syntax, casing, or edge-case guidance (e.g., handling of uppercase or mixed-case strings) 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?

The EN text states a specific verb and resource ('Decodes a Bech32 or Bech32m string'), plus the extra behaviors of variant detection and the returned fields (prefix, 5-bit words, 8-bit data). It explicitly names the sibling it is not (bech32-encode), so an agent can distinguish the two without opening schemas.

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

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

There is an explicit 'When' block, a 'Not for' block and a named alternative (bech32-encode), which is more than most definitions offer. However, the 'When' line says the tool applies when bytes or text must be converted 'to or from this encoding', which overlaps with the encoding direction it just excluded — a small internal ambiguity about directionality.

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, openWorldHint=false and destructiveHint=false, so restating 'read-only, no network' is largely redundant. What genuinely adds value is the operational limit set — 64 KB JSON input, 1 s per call, 1 MB result — which no annotation or schema field conveys and which an agent needs to avoid failed calls.

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 labelled structure (When / Not for / Side effects / Deterministic / Limits) is well front-loaded and easy to scan. But the entire block is duplicated in Spanish and English, roughly doubling length with zero informational gain for the calling agent, which dilutes the useful 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 an output schema present and annotations covering the safety profile, the description need not explain return values; it still covers purpose, routing, limits and determinism. The only residual gap is the contradictory 'to or from this encoding' phrasing on an encode-only tool.

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

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

Schema description coverage is 100% and all three parameters (hrp, variant, data_hex) are fully documented with patterns, bounds, enum and default in the schema itself. The description adds only the conceptual framing of hrp as a 'human-readable prefix' and the byte-width conversion, 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 and resource (encode hex bytes plus a human-readable part) into Bech32/Bech32m, names both BIP-173 and BIP-350, and even describes the transformation (8-bit bytes to 5-bit groups). It is unambiguously distinguishable from bech32-decode and from the many other base32/base58/base64 encoders in the sibling list.

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?

Explicit 'When:' and 'Not for: decoding ... (bech32-decode)' clauses route the agent correctly and name the alternative sibling. However, the 'When' clause also says 'to or from this encoding' ('o desde ella'), which blurs the very boundary the 'Not for' sentence draws, since decoding is exactly what it says not to use this tool for.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes further by adding operational limits (64 KB input, 1 s per call, 1 MB result), the power digit cap (≤10,000 digits), and a determinism guarantee. These are concrete constraints an agent cannot infer 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?

Content is front-loaded with purpose, then when/not-for, then side effects and limits — a logical order with no filler sentences. However, the entire block is duplicated in Spanish and English, which roughly doubles length for identical information.

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

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

An output schema exists, so return values need no prose. With limits, determinism, side-effect disclosure, sibling routing, and 100% param coverage all present, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, establishing a baseline of 3, but the description adds real semantic value: it clarifies that 'divide' returns floor quotient and remainder, and that power results are bounded at 10,000 digits. The a/b/operation parameters themselves are not elaborated beyond the schema, so not a full 5.

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

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

States a specific verb and resource ('Realiza aritmética exacta de enteros grandes') and enumerates the supported operations (add, subtract, multiply, divide, power, compare). It explicitly names the sibling it is not (expression-evaluate), so an agent can distinguish it without opening schemas.

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

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

Provides an explicit 'When:' condition (result must be exact/reproducible, not estimated) and an explicit 'Not for:' exclusion pointing to expression-evaluate. Both the selection and deselection criteria are stated outright.

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, destructiveHint=false and openWorldHint=false, so the read-only/no-network/deterministic statements largely restate structured data. The description does add value beyond them: explicit operational limits (64 KB JSON input, 1 s per call, 1 MB result) and the guarantee that rounded shares still sum to the total charged. It does not clarify what happens when round_up_to forces shares above the total, which leaves one behavioral edge case open.

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?

Structure is excellent: purpose first, then labeled When / Not for / Side effects / Deterministic / Limits sections that are easy to scan. The cost is full bilingual duplication of essentially identical content, which roughly doubles token length for no informational gain.

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

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

An output schema exists, so return values need not be described, and the essential routing, safety and limit information is present. The remaining gap is the unresolved edge case of how round_up_to interacts with the 'shares sum to total' promise, which matters for a tool whose whole point is exactness.

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 total, people, currency, tip_base, round_up_to and tip_percent. The description adds only marginal semantics — that the tip is computed on pre-tax or total (mapping to tip_base) and that rounding applies per share — and never mentions currency or the interaction between round_up_to and the sum-to-total guarantee.

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 (split a bill among people) plus the two defining behaviors: optional tip and per-share rounding that keeps shares summing to the charged total. It explicitly names the sibling it is not (money-allocate), so an agent can route between them without opening either schema.

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

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

The 'Cuándo / When' clause names the trigger condition (money, tax or financial-math results that must be exact and reproducible), and the 'No para / Not for' clause names the concrete alternative tool (money-allocate) with the distinguishing criterion (parts must add up exactly). Both use and exclusion are spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds operationally useful context beyond them: no side effects, no stored state, determinism, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result). These are things the 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-loaded with purpose, then when/not-for, side effects, determinism, and limits in a clean order. The full text is duplicated in Spanish and English, which doubles length for the same content, though the structure itself is tight.

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

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

With an output schema present, annotations covering the safety profile, and both parameters documented in schema plus description, an agent has everything needed to invoke this correctly. The only omission (base64 output) is already visible in the enum.

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%, but the description adds real meaning the schema does not: spaces are optional in the bit string and length must be a multiple of 8. Minor gap: it says output is 'text UTF-8 or hex' while the schema enum also permits base64, so the output_encoding option is under-described.

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 ('Convierte bits 0/1 a texto UTF-8') and explicitly names the sibling it is not: binary-encode. An agent can distinguish the two directions of the binary conversion without opening either schema.

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

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

Provides an explicit 'Cuándo' section describing the situation that selects this tool, plus a 'No para' clause naming binary-encode as the alternative for the opposite direction. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description nonetheless adds real context beyond them: no network, no stored state, determinism, and concrete limits (64 KB input, 1 s, 1 MB result). The only blemish is that the stated 64 KB input limit does not match the schema's maxLength of 16384 chars, a mild internal inconsistency rather than an annotation contradiction.

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, then labeled sections (When / Not for / Side effects / Deterministic / Limits) that scan well. The full Spanish-plus-English duplication roughly doubles the length for identical content, which costs a point against strict conciseness.

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-parameter, read-only, output-schema-backed tool, nothing an agent needs is missing: purpose, routing, side effects, determinism and hard limits are all stated, and return values are covered by the output 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% with a single required 'text' string, so the schema already carries parameter meaning. The description adds only the implicit notion that the text is UTF-8, which is baseline-level value — the 3 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 a specific verb and resource ('Convierte texto UTF-8 a bytes binarios de 8 bits separados por espacios') and explicitly names the sibling it is not for ('binary-decode'). An agent can distinguish it from the many other encoders in the sibling list 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?

Uses explicit 'Cuándo'/'When' and 'No para'/'Not for' clauses naming the alternative (binary-decode) and the condition that selects it. This is the when-to-use / when-not / alternative pattern at full strength.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds concrete context on top: no network access, no stored state, deterministic output, and hard limits (64 KB JSON input, 1 s per call, 1 MB result). It also scopes the check to syntax and checksum only, which prevents an agent from assuming semantic/on-chain validation.

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 purpose, then labeled sections for conditions, exclusions, side effects and limits, so an agent can skim. It loses a point because the body is duplicated verbatim in the inputSchema description and closes with a dangling pointer ('[EN completo / full EN: inputSchema.description]') that adds no information.

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

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

An output schema exists so return values need not be explained, annotations cover the safety profile, and the description supplies the remaining operational context: offline nature, determinism, and size/time limits. Nothing an agent needs in order to call this correctly is missing.

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

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

With one parameter and 100% schema coverage, the schema already documents the field, but the description adds real semantic meaning by defining which address grammars are accepted and that validation stops at syntax plus checksum. It does not restate the maxLength, but the accepted-format detail is more useful than that.

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 (validate a Bitcoin address) and enumerates the exact address families and encodings covered: Base58Check P2PKH/P2SH and Bech32/Bech32m SegWit with BIP-173/350 rules. It also names the sibling it is not (solana-address-validate), so an agent can route without opening either schema.

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

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

The 'Cuándo' line gives the triggering condition (offline verification of format and check digit before using an identifier) and the 'No para' line explicitly excludes the Solana public-key case with the alternative tool named. This is the full when/when-not/alternative triad.

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, openWorldHint=false, idempotentHint and destructiveHint=false, so 'no side effects / deterministic' largely restates structured data. However the description adds genuinely new behavioral facts not in annotations or schema: 64 KB input cap, 1 s per-call latency budget, and 1 MB result ceiling.

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 and well ordered: purpose, when, when-not, side effects, determinism, limits. It loses a point for the duplicated Spanish/English halves that repeat the same facts and the dangling meta-note '[EN completo / full EN: inputSchema.description]', which is noise rather than guidance.

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 rich annotations, a full output schema and 100% schema coverage, the remaining burden is limits and boundaries — and those are all stated (input size, latency, result size, determinism, no network). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds marginal meaning by noting k1 and b are tunable and that tokens are accent-insensitive, but it never explains what k1/b control or how k relates to the returned list beyond a passing mention of 'los k mejores' in the negative example.

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 (rank), resource (documents for a query), and algorithm (Okapi BM25 with tunable k1/b), plus the accent-insensitive tokenization detail that distinguishes it from generic sorters. It explicitly names the sibling it is not (vector-top-k), so an agent can route without opening either schema.

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

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

Gives an explicit 'Cuándo' block with concrete agent-loop scenarios (tokens, costs, retries, chunking, JSON clean-up) and an explicit 'No para' block naming vector-top-k as the alternative for cosine-similarity ranking. Both the positive and negative selection conditions are stated.

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, openWorldHint=false and destructiveHint=false, and the description reinforces this with 'sin red, sin estado guardado' and a determinism guarantee. The added value is in the concrete limits (64 KB input, 1 s per call, 1 MB result), which no annotation or schema field expresses.

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 content is front-loaded and each fact is useful, but the same text is delivered twice (a full Spanish block followed by an equivalent English block) and then a third time lives in inputSchema.description, referenced by a pointer sentence. Roughly half the description is duplication, which dilutes an otherwise tight definition.

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 one-parameter validator with an output schema and full annotations, nothing an agent needs is missing: accepted formats, check-digit semantics, offline/deterministic behavior, resource limits, and the sibling to use for CPF are all stated.

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 single param is documented with an example and maxLength, so the schema carries the baseline. The description still adds real meaning: it tells the agent the alphanumeric format is accepted (letters valued as ASCII − 48) and that output is formatted as 11.222.333/0001-81, which the schema only hints at via one example.

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 ('Valida un CNPJ brasileño') and immediately scopes it to the alphanumeric format from July 2026 with both mod-11 check digits. It explicitly names the sibling it is not (br-cpf-validate), so an agent can separate the two Brazilian document validators without opening a schema.

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

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

Gives explicit 'Cuándo' and 'No para' clauses plus the named alternative br-cpf-validate, which is exactly the routing information an agent needs. The trigger phrasing ('documento o número de cuenta de LatAm o España') is looser than the tool's actual scope — a CNPJ is a Brazilian company registry number, not a generic LatAm account number — which could pull in slightly wrong calls.

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, openWorldHint=false and destructiveHint=false, so the safety profile is pre-covered. The description nonetheless adds real context beyond them: determinism, no network/stored state, and operational limits (64 KB input, 1 s per call, 1 MB result) that no annotation conveys.

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 Spanish block is tightly structured with explicit labels (Cuándo, No para, Efectos secundarios, Determinista, Límites), so it is front-loaded and scannable. The full English duplicate plus the identical text repeated in inputSchema.description is some redundancy, but it does not obscure the key information.

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

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

An output schema exists, so return-value details are unnecessary in the description. Between the algorithm, the negative case, the side-effect profile and the resource limits, an agent has everything needed to decide and 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?

With one parameter at 100% schema coverage, the baseline is 3. The description still adds meaning beyond the schema's bare 'up to 20 chars': the 11-digit plus two-check-digit structure and the expected formatted output '529.982.247-25', which tells the agent what accepted input looks like.

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

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

The description names a specific verb and resource ('Valida un CPF brasileño'), specifies the algorithm (11 digits, two mod-11 check digits), the rejection rule (repeated digits) and the formatting behavior. It also explicitly distinguishes itself from the sibling br-cnpj-validate, so an agent can tell the two apart without opening a schema.

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

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

It has an explicit 'Cuándo' clause (checking a user-supplied LatAm/Spanish ID offline before storing or using it) and an explicit 'No para' clause routing Brazilian CNPJ checks to br-cnpj-validate. When-to-use, when-not, and the alternative are all stated outright.

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, destructiveHint=false and openWorldHint=false, but the description adds real beyond-schema facts: format only and it never claims a payment, deterministic output for identical input, no network or stored state, and concrete limits (64 KB input, 1 s per call, 1 MB result). Only the read-only/no-side-effect restatement is redundant with the annotations.

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

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

Front-loaded with the core verb statement, but it pads with a mismatched 'Cuándo' sentence about rounding/rates, then repeats the whole definition as a truncated EN block ending in a meta-reference '[EN completo / full EN: inputSchema.description]'. Those notches cost space without adding decision value.

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 12 optional parameters, an output schema, and full annotation coverage, the definition still supplies what matters: build-vs-parse mode via action, key-or-URL choice, no-payment guarantee, determinism, and hard size/time limits. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does add the useful semantic point that key and dynamic URL are alternatives ('llave o URL dinámica'), but the schema already says 'instead of key' on url, so marginal value is small.

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 pair and resource: builds a Pix BR Code (EMVCo TLV with GUI br.gov.bcb.pix, key or dynamic URL, amount, txid, CRC16) or parses/checks one, per Banco Central do Brasil manuals. It explicitly names the sibling it is not for (emvco-qr-parse), so an agent can discriminate without opening a schema.

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

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

'No para: leer un payload QR EMVCo de comercio (emvco-qr-parse)' gives an explicit exclusion plus the alternative tool, which is the strongest part. The positive 'Cuándo' clause, however, talks about money/tax/financial-math exactness, which reads as boilerplate from a math toolkit and does not actually describe the Pix-BR-Code use case.

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/openWorld=false/idempotent/non-destructive, so the safety profile is covered; the description adds value with determinism (same input, same output) and hard operational limits (64 KB input, 1 s per call, 1 MB result) that no annotation conveys. The "no stored state, no network" note partly restates annotations but reinforces the pure-function model. It does not discuss error behavior for invalid dates or oversized holiday lists.

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 purpose is front-loaded and every clause is substantive, but the content is delivered twice (ES and EN) and the English text is repeated again in the schema description, roughly tripling the reading cost. The "Not for" sentence also echoes the purpose verbatim before getting to the differentiator (Colombian holidays).

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?

Return values are covered by the output schema, and the description supplies the remaining pieces an agent needs: scope, sibling exclusion, determinism and resource limits. Only minor gaps remain (error semantics for malformed dates, whether holidays may fall on weekend days).

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%, with per-property descriptions for date, days, weekend (0=Sun…6=Sat, default [0,6]) and holidays (up to 2000 entries), so the schema already carries full parameter meaning. The description only broadens this to "configurable weekend days and given holidays" without adding format or interaction detail, which is the expected baseline-3 case.

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 (add/subtract N working days to a date) and immediately specifies scope: skips configurable weekend days and supplied holidays. It also names the sibling it is not (co-business-days-add with Colombian holidays), so an agent can separate the generic tool from the localized one 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?

Explicit "When" clause ties use to contexts demanding exact calendar arithmetic (offset drift, DST, month ends, leap years), and a "Not for" clause points to co-business-days-add. It does not mention other adjacent siblings such as business-days-between or date-add, so routing is clear but not exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substance: no side effects, no network, no stored state, deterministic output, and hard limits (64 KB input, 1 s per call, 1 MB result). That is exactly the extra context annotations cannot carry.

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 and each block is useful, but the full definition is duplicated in Spanish and English, and the ES 'No para' sentence is garbled ('contar días hábiles... en Colombia' reads as if it were the purpose). A truncated artifact ('[EN completo / full EN: inputSchema.description]') also appears inline.

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

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

Output schema exists and all five parameters are documented, plus limits and determinism are stated, so an agent has enough to call it correctly. The confusing bilingual 'No para' phrasing and duplicated EN block are the only gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns more by explaining the counting convention (default counts days after start through end; inclusive counts both ends), which clarifies the `inclusive` flag beyond the schema's 'Count the start date too'.

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 ('Cuenta días hábiles entre dos fechas') plus the exclusion scope (configurable weekends and holidays). It also names the sibling it is not, so an agent can separate it from co-business-days-between without opening either schema.

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

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

Explicit 'Cuándo' and 'No para' sections, with the alternative co-business-days-between named for the Colombian case. The positive condition ('a date, time-zone or calendar result has to be exact') is somewhat generic and does not distinguish it from date-between or business-days-add, 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 declare readOnly, idempotent, non-destructive and no open-world access, and the description largely echoes that. It does add value beyond annotations: determinism ('same input, same output') and concrete limits (64 KB input, 1 s per call, 1 MB result).

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

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

Purpose is front-loaded and clear, but the 'Cuándo' enumeration (URL, token, version, IP range, HTML, Markdown, agent-readiness file) is irrelevant boilerplate that adds noise rather than helping select this tool. It sits alongside useful side-effect and limit statements.

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

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

A single-param read-only tool with an output schema (so return values needn't be explained), determinism, no-side-effect and limit disclosures. Nothing essential for correct invocation is missing; only the noisy 'Cuándo' clause detracts.

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?

Only one parameter with 100% schema description coverage, so the schema already documents the header value, format and length. The description adds no syntax or format detail beyond what the schema states, 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 specific verb and resource: parses a Cache-Control header into directives and summarizes shared/private cacheability. It names the exact sibling it replaces (http-headers-parse), so an agent can distinguish it without opening either schema.

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

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

Provides an explicit 'No para' exclusion routing the agent to http-headers-parse for raw header blocks, which is genuinely useful. However the 'Cuándo' clause is boilerplate listing URLs, tokens, IP ranges, HTML/Markdown docs that has little to do with Cache-Control parsing, diluting the guidance.

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

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

Goes well beyond the annotations by stating no side effects (no network, no stored state), determinism, and hard limits (64 KB input, 1 s, 1 MB output). These are operational constraints an agent cannot derive from readOnlyHint/idempotentHint alone, so the extra context is genuinely valuable.

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 cleanly sectioned into When / Not for / Side effects / Limits. Both Spanish and English versions are given, which is slightly redundant but each line carries distinct information.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description still covers side effects, determinism and execution limits. For a small pure-function calendar tool this leaves no material gap for correct invocation.

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

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

Schema description coverage is 100%, so year, month and week_start (with enum and default) are already fully documented. The description only echoes the week-start choice and the ISO week numbering, adding no format or edge-case semantics beyond the schema. 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 and resource ('Devuelve un mes como cuadrícula de semanas') plus the distinguishing features (ISO week numbers) and explicitly names the sibling it is not, month-info. An agent can distinguish it from date-iso-week, month-info and calendar siblings without opening a schema.

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

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

Uses explicit 'Cuándo' and 'No para' sections, naming the alternative (month-info) and the condition that selects this tool (date/timezone results that must be exact). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, yet the description still adds non-obvious facts: nothing is stored, it does not prove the card exists, no network access, deterministic output, and explicit limits (64 KB input, 1 s, 1 MB result). That is exactly the context annotations cannot 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 the core action, then clearly labeled sections (Cuándo / No para / Efectos / Determinista / Límites). The parallel ES and EN blocks plus the schema description repeating the same English text make it longer than strictly necessary, but every sentence carries information.

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

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

For a one-parameter, read-only tool with an output schema, everything an agent needs is present: input expectation, what the result is masked, the no-storage/no-existence-proof caveat, determinism, and operational limits. No return-value explanation is required given the output 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?

With 100% schema coverage and a single well-documented parameter (with an example including spaces), the baseline is 3. The description adds only the framing that matching is done on the IIN prefix and that output is masked, which is marginal beyond the schema.

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

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

States a specific verb and resource ('Detecta la franquicia de una tarjeta por su prefijo'), enumerates the brands covered, and clarifies that length + Luhn are checked and only a masked number is returned. An agent can distinguish this from a pure checksum tool without opening the schema.

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

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

Explicitly gives a 'Cuándo' (offline format/check-digit verification before using an identifier) and routes to a named alternative ('No para ... luhn-validate'). The Luhn boundary is slightly muddy because the tool itself performs Luhn, so the agent has to infer the difference is scope (brand + length + mask vs. bare checksum), but the when/when-not structure is 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 already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the side-effect sentence largely restates structured data. What it adds beyond that is genuinely new: hard limits (64 KB input, 1 s per call, 1 MB result) and the determinism/Unicode-preservation guarantees, which help an agent size its calls.

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 action, then labeled When / Not for / Side effects / Deterministic / Limits, which is easy to scan. It is duplicated in Spanish and English, roughly doubling length, but each labeled clause carries distinct information.

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

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

An output schema exists so return shape needs no explanation, and the description covers the remaining gaps an agent would care about: splitting rules, Unicode handling, determinism, and size/time limits. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% with a single required 'text' parameter documented in-schema, so the baseline is 3. The description adds transformation semantics (how words are split) rather than anything about the parameter itself, so no reason to score higher.

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 ('Convierte texto o un identificador a camelCase') plus the exact word-splitting rule (spaces, punctuation, camelCase/acronym boundaries, Unicode preserved). It also names the sibling case-pascal as the thing it is not, so an agent can separate it from the other nine case-* tools without opening a schema.

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

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

Explicit 'Cuándo' context (exact transformation/comparison/measurement rather than approximation) and an explicit 'No para' exclusion that names the alternative tool (case-pascal). The routing decision is fully determined by the description.

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