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

No annotations are supplied, so the description carries the full behavioral burden. It does add genuinely useful context by labeling this a 'Live network check', implying latency and external dependency, and by listing output fields in the absence of an output schema. However, it says nothing about failure modes (DNS failure, TLS handshake error, timeout), rate limits, or what happens with self-signed/invalid certificates — significant gaps for a tool with zero annotation coverage.

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 lead sentence is well front-loaded and dense with useful specifics, and the second sentence efficiently flags the live-network nature. But the final sentence is truncated mid-word ('certifi'), leaving an incomplete instruction that reads as a defect rather than concision.

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 one-parameter read tool with no output schema, the description covers what is fetched and that it hits the network live, which is close to sufficient. It is still incomplete on error behavior and lacks disambiguation from check_ssl_certificate, and the truncated final sentence leaves the stated purpose unfinished.

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?

There is a single parameter whose schema description ('Hostname to check') already covers it at 100% coverage, so the baseline is 3. The description adds no format guidance, such as whether a bare hostname, FQDN, or host:port is accepted, and the schema's additionalProperties:true is left unexplained.

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 names a specific verb and resource ('Fetch a host's TLS certificate') and enumerates the returned fields (issuer, subject, validity dates, days remaining, SAN list), so the agent knows exactly what the tool produces. It does not differentiate from the sibling check_ssl_certificate, which appears to be an overlapping tool, so it falls 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 through a single, truncated clause ('Use to catch an expiring certifi'), which signals certificate-expiry monitoring but is cut off mid-word. There is no statement of when not to use it, and no routing to the near-identical sibling check_ssl_certificate despite the obvious ambiguity.

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