SSL Certificate Check

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

Beyond the annotations (readOnlyHint/openWorldHint/destructiveHint), the description discloses meaningful behavioral details: it measures 0.05-1.5 seconds, cuts each probe at 12 seconds, and openly states it does not build a chain of trust or check revocation. Mentioning the formalism 'TLS handshakes to a public host using openssl' also clarifies the internal mechanics. Nothing contradicts the annotations.

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 dense but not bloated; every sentence carries a distinct piece of insight — method, results, when to use, limitations, and performance. The use of a running list for outputs and limitations could be more lineated, but the front-loaded action and explicit 'It does ...' exclusions are efficient and immediately answer the core questions. Only the latency measurement, while useful, is somewhat secondary.

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 one parameter, full schema coverage, an output schema present, and correct annotations, this description effectively stands alone. It leaves little to infer in terms of scope, acceptable URLs, timing, and boundaries—it tells the agent that public hosts are expected, that the certificate is returned, and what is not covered. No essential piece of context is missing.

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?

The schema already describes the single `url` parameter in detail with a regex and coverage of 100%. The description adds genuine value by noting it only works against a 'public host' and clarifies that the submitted scheme is merely reported, not negotiated, and that the tool will connect to the explicit port or 443. This goes beyond the schema's literal description and helps the caller set expectations.

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 opens by naming the exact action ('Opens its own TLS handshakes to a public host with openssl') and the exact resource (the server's TLS protocol and certificate). It then enumerates the produced outputs — accepted TLS versions, protocol-support grade, and certificate details — and explicitly lists what the tool is not (not a browser trust decision, no revocation check, no cipher-suite inspection). Despite having no siblings, this is unambiguous and leaves no doubt about the tool's domain.

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 provides explicit usage criteria: 'Reach for it on padlock, HTTPS, "Not Secure" certificate-expiry and wrong-hostname questions' and its limitation 'does not verify every load-balanced node'. It also says when not to rely on it, e.g., it 'does not fetch the page or establish whether plain HTTP is actually served or redirected'. This is a precise when-and-when-not statement, which is even more helpful since no sibling tools exist to contrast.

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