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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context beyond annotations: it explains the data source (crt.sh), the passive nature of the discovery, the limitation (only hostnames in public TLS certificates, not all DNS records), and the reliability caveat (crt.sh is occasionally slow or unavailable). This is meaningful additional context.

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?

Two sentences with zero waste. The core purpose is front-loaded, the limitation is stated immediately, and the reliability caveat is a single short sentence. Every word earns its place.

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, read-only, idempotent tool with no output schema, the description is nearly complete. It explains the data source, the scope of results, and the reliability caveat. The only minor gap is that it doesn't describe the output format, but with no output schema and a simple single-parameter tool, this is a minor omission.

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 fully documents the single 'domain' parameter. The description reinforces the parameter's meaning by giving an example ('example.com') and explaining what the domain is used for. However, it doesn't add significant new semantic detail beyond the schema, so the 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 a specific verb ('discovers'), a specific resource ('subdomains'), and a specific method ('from Certificate Transparency logs via crt.sh'). It also explicitly distinguishes itself from DNS record enumeration by noting it finds hostnames in public TLS certificates, not every DNS record. This clearly differentiates it from the sibling dns_lookup tool.

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 clearly implies when to use this tool: when passive subdomain discovery from certificate transparency is desired, and explicitly notes it is not a full DNS enumeration tool. It doesn't name alternative tools explicitly, but the contrast with 'not every DNS record' and the sibling dns_lookup provides clear context. It also warns about crt.sh availability, which helps an agent decide whether to use it.

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