check_mx

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds limited new behavioral context. It mentions 'Look up' and 'Identifies', consistent with read-only operation, but does not disclose potential rate limits or caching behavior explicitly.

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 three sentences, front-loaded with the main purpose. It is clear and to the point, with no unnecessary information. Minor improvement could be omitting 'Part of the scan_domain audit' if not needed.

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 three parameters and existence of output schema, the description adequately explains the tool's function and use cases. It does not need to detail return values due to output schema.

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 has 100% coverage with descriptions for all parameters. Description does not add additional meaning beyond the schema; the domain parameter is implied and format/force_refresh are explained in schema. 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 states 'Look up MX records for a domain' with specific verb and resource, and distinguishes from siblings by focusing on MX records and identifying email hosting providers. It clearly differentiates from other check_* tools which check different record types.

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?

Provides explicit usage scenarios: 'Use when asked which email provider hosts inbound mail for a domain, or to see MX record configuration.' It does not explicitly list when not to use, but the context of being part of scan_domain audit implies appropriate use.

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