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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond them — that it opens an actual outbound connection to the target rather than reading cached data, and that it flags misconfigurations. It stops short of disclosing timeout, rate-limit, or failure behavior for unreachable hosts.

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 the outcome front-loaded and the supported ports trailing as a scoping note. The port list is largely duplicated from the schema, which is the only wasted space.

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?

With no output schema, the description carries the burden of explaining return values and does so by enumerating chain, expiry, protocol versions, cipher strength and misconfigurations. Remaining gaps are minor: no note on timeouts, unreachable hosts, or whether private/internal addresses are accepted.

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%, with host length limits and an enumerated port list already documented, so the baseline is 3. The description's port enumeration merely repeats the schema's const/anyOf values and adds no new meaning about the default or host restrictions.

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?

States a specific verb and resource ('makes live TLS connections to a host and reports the certificate chain, expiry, protocol versions, cipher strength') so the agent knows exactly what the tool produces. It does not explicitly name a sibling such as http_headers_check or smtp_test to route against, which keeps it short of a 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?

Usage is only implied: the mention of live TLS connections plus ports 443/8443/465/993/995 signals certificate inspection for HTTPS, SMTPS, IMAPS and POP3S endpoints. There is no explicit when-to-use, when-not-to-use, or named alternative among the many overlapping siblings.

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