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

With no annotations, the description takes full responsibility for transparency. It explicitly states that every check is a pure function of its input and deliberately does not fetch URLs or run code, which informs the agent about side-effect-free behavior. This is clear and sufficient, though it could have elaborated on error responses or return formats.

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 somewhat verbose but necessary to enumerate all supported check types and their specific requirements. It is organized as a list within a sentence, making it easy to scan. The inclusion of negative constraints ('will NOT fetch a URL') adds clarity without excessive length.

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 tool's complexity (multiple check types, optional parameters), the description provides sufficient context for an agent to call it correctly: it lists all check types, hints at required inputs for special cases, and states limitations. It could mention error handling or output format, but the core usage is well covered.

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

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

The schema provides only names and types, but the description adds crucial meaning: 'check' specifies the type of validation, 'input' is the data to validate, and for 'ed25519' it explicitly notes that 'public_key' and 'signature' are also sent. This covers the main parameters, though 'input' semantics vary by check type and could be more detailed.

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 the tool's purpose as performing various validation checks, enumerating each check type and its meaning (e.g., 'json' for parsing, 'sha256' for hash verification). It explicitly distinguishes itself from sibling tools by emphasizing it is a pure function with no side effects like URL fetching or code execution.

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

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

The description implies when to use the tool by listing the check types and required inputs for special cases (e.g., 'ed25519' needs public_key and signature). It also states what the tool will NOT do (fetch URLs, run code), which helps prevent misuse. However, it does not explicitly name alternative tools for cases where a different action would be more appropriate, but the list of check types serves as a clear usage guide.

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