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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the check spans two surfaces — a DNS TXT record and a remotely published policy file — which is meaningful context beyond annotations, but it doesn't say what happens when the record is missing or the policy fetch fails, nor how results are reported.

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?

One front-loaded sentence with the resource first and the inspected fields enumerated after a colon. Every clause carries information; there is no filler or restatement of the title.

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, annotation-rich, output-schema-less check tool, the description covers what is validated and against which aspects. Remaining gaps — behavior on missing records, whether a policy fetch is followed across redirects, and result shape — are modest for this complexity level.

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 `domain` parameter is documented with an example in the schema. The description adds only the implicit framing that the domain is the subject of the _mta-sts record, not any new syntax or format detail. Baseline 3 applies when the schema carries the parameter meaning.

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 (validate) and specific resources (_mta-sts DNS record and the published policy file), plus the exact aspects inspected: mode, MX patterns, max_age, TLS-RPT. This clearly separates it from check_dmarc/check_spf/check_bimi siblings. It stops short of naming a sibling for contrast, so a 4 rather than 5.

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 no when-to-use guidance, no prerequisites (e.g. domain must already publish MTA-STS), and no routing to alternatives such as check_email_authentication or check_bulk_sender_requirements for broader auth coverage. Usage is only inferable from the tool name and the object of validation.

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