crypto_checksum

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

Annotations (readOnlyHint, idempotentHint, etc.) are reinforced and expanded by the description: 'Runs locally on the input you provide: read-only, non-destructive, contacts no external service, and is rate-limited.' The return value structure is also disclosed. No contradictions.

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

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

Three sentences structured with title/purpose, algorithm list, usage guidance, behavioral notes, and return value summary. Front-loaded and concise; every sentence adds distinct value without redundancy.

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

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

For a tool with many algorithms and output format nuances, the description covers purpose, usage, behavior, and return format. Output schema exists and the description summarizes it. A minor gap: no explicit clarification of output format behavior for non-numeric algorithms, but the schema covers it. Overall sufficient for an agent.

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 detailed descriptions for each parameter (text, algorithms, outputFormat). The description adds high-level context (e.g., 'non-cryptographic' though including cryptographic hashes) but does not substantially augment schema-level parameter semantics beyond reinforcing the purpose. Baseline 3 is appropriate.

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

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

The description clearly states it computes non-cryptographic checksums and hashes over UTF-8 text, listing supported algorithms (CRC, Adler, Fletcher, FNV, SHA, etc.). It distinguishes from siblings by referencing crypto_hash for cryptographic digests and crypto_hash_identifier for detection, establishing a specific verb+resource with explicit differentiation.

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

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

The description provides explicit guidance: 'Use it when you need fast verification or legacy checksums; use crypto_hash for cryptographic file/text digests, or crypto_hash_identifier to detect an unknown hash's algorithm.' It also notes the tool is read-only, non-destructive, and rate-limited, giving clear context for when to invoke versus alternatives.

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