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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses the weighted check-digit scheme, the supported layouts, and the important non-standard behavior that a mismatched digit returns HTTP 200 with valid:false. It also clarifies the limitation of the check, which goes beyond the minimal input schema without contradicting any 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 compact yet informative, front-loading the core purpose before explaining formats and edge-case behavior. Every sentence contributes either task definition, input format, or important result behavior. It could trim a slight repetition of the 'not identity proof' point, but it remains 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?

The description covers the tool's input constraints (TD3 and TD1 line lengths), the algorithm context, and the notable valid:false response behavior. Since there is no output schema, it does partially explain the return behavior, though a more complete statement about the full result structure would be helpful. Overall, an agent can infer how and when to use the tool from the text.

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 the MRZ string parameter. The description repeats the TD3/TD1 format details but adds the practical note that TD3 is typical for passports and TD1 for ID cards. This confirms the parameter meaning without offering substantial new semantics 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?

The description opens with a specific verb and resource: 'Parses ICAO 9303 TD1/TD3 MRZ and verifies check digits.' It clearly distinguishes itself from the broader validator sibling set by naming the exact standard and formats, and it explicitly clarifies that it is a format check, not identity proof.

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

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

The description gives clear context for when to use the tool: to parse TD3 or TD1 MRZ strings and verify ICAO check digits. It also provides a notable exclusion by stating it is not identity proof and does not confirm issuance or holder identity, which helps an agent avoid overusing it, though it does not explicitly point to an alternative tool.

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