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 structured data. The description still adds genuine value beyond that: determinism guarantees, no network/no stored state, and concrete limits (1 s per call, result up to 1 MB). However the stated 'JSON input up to 64 KB' conflicts with the schema's maxLength of 1,048,576 (1 MB), an inconsistency that could mislead an agent sizing its input.

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-structured with labelled sections (Cuándo / No para / Efectos / Límites), but the entire block is duplicated verbatim in Spanish and English, roughly doubling length for no informational gain. For a two-parameter checksum tool, half the text would suffice.

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, the annotations are rich, and both parameters are fully documented in the schema, so the description covers the remaining needs: determinism, side effects, and resource limits. The only completeness defect is the unresolved 64 KB vs. 1 MB input-size ambiguity, which an agent may need to resolve 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 description coverage is 100% and the schema already documents both `data` (with an example) and the `input_encoding` enum with its default. The description adds nothing about parameter syntax, encoding choices, or how encoding affects the checksum, so the baseline 3 applies — the schema is doing all the work here.

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

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

The description names the exact algorithm (CRC-32C, Castagnoli polynomial), its real-world provenance (iSCSI, ext4, SCTP, gRPC) and explicitly states it is non-cryptographic. It also names the sibling it is not (checksum-crc32), so an agent can distinguish it from the eight other checksum tools in one read.

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' clause covers the positive selection criteria (fast non-cryptographic checksum for error detection, sharding, hash tables) and an explicit 'No para' clause directs the agent to checksum-crc32 for the plain CRC-32 case. This is the textbook when/when-not/alternative structure.

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