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

With no annotations provided, the description carries the full burden of behavioral disclosure. It openly explains that lists refusing public-resolver queries return 'n/a' rather than a misleading 'clean', which is valuable honesty about result semantics. It does not mention other traits like rate limits or network dependency, but the n/a disclosure is significant and well beyond a basic restatement.

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, zero filler. The main action is front-loaded, and the crucial caveat about n/a results is delivered in a compact follow-up. Every sentence 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, no-output-schema tool, the description covers the essential operational aspects: what it checks, which lists it uses, and how to interpret one ambiguous result. It does not spell out the full return shape, but the n/a explanation and list of blocklists make the tool's behavior sufficiently predictable for correct invocation.

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%: the only parameter, 'ip', is described as 'IPv4 address' in the schema. The description adds no new meaning about the parameter beyond the schema's own description, so the baseline of 3 applies.

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 uses a specific verb ('Check'), a precise resource ('IPv4 address'), and enumerates the exact blocklists queried (Spamhaus ZEN, SpamCop, SORBS, Barracuda, s5h). This makes the tool's purpose unmistakable and clearly differentiates it from general DNS or IP tools among the siblings.

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 context is clear: use this tool to check an IPv4 address against spam/abuse blocklists. It does not explicitly name when not to use it or suggest an alternative, so it lacks the explicit exclusion guidance needed for a 5, but the intended use case is unambiguous.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavior: it uses DoH, returns every answer with its TTL, and distinguishes NXDOMAIN from a missing record type. It does not cover all edge cases, such as handling of unsupported types, but the core response semantics are clear.

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 no filler: the action is front-loaded, the accepted record types are compactly listed, and the output behavior is stated in a single clause. Every sentence 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 two-parameter lookup with no output schema, the description is sufficiently complete: it names the input, enumerates valid types, and describes both the success return (answers with TTL) and the no-answer distinction. An agent has enough to invoke it correctly and interpret results.

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 coverage is 100%, so the baseline is 3; the description adds value by enumerating the valid record types for the type parameter, which the schema does not. It reinforces the name parameter's role without duplicating the schema's hostname examples.

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 with a specific verb and resource: "Resolve a DNS name over DNS-over-HTTPS." It enumerates supported record types, which makes the tool's function clear, though it does not explicitly contrast itself with siblings like reverse_dns.

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 implied through the record-type list and the hostname example, but there is no explicit statement of when to choose this tool over alternatives like reverse_dns, dnsbl_check, or lookup_port. No exclusion criteria or recommended contexts are given.

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

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

With no annotations provided, the description carries the full behavioral burden. It clearly discloses accepted input formats, but it does not specify the output format, whether all representations are returned, or how invalid inputs are handled.

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 two concise sentences with no filler. The primary action is stated first, followed by the acceptable input scope, making it easy to parse quickly.

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 simple one-parameter conversion tool, the description covers the input contract well. However, since there is no output schema and no annotations, the lack of explicit return-format information leaves a meaningful gap for an agent trying to use the result.

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%, and the parameter description includes concrete examples for each accepted format. The description reinforces those formats but adds little beyond the schema, so the baseline score of 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?

States a specific verb ('Convert') with a clear resource ('IPv4 address') and enumerates the exact formats involved. It also differentiates itself from siblings like ipv6_normalize by explicitly limiting scope to IPv4.

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 implies when to use the tool: converting IPv4 addresses among the four listed formats. However, it does not explicitly state when not to use it or point to alternatives such as ipv6_normalize for IPv6 addresses.

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

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

With no annotations, the description carries full behavioral burden. It does disclose output behavior by mentioning the range display and protocol scope, but it does not cover edge cases like invalid IP/CIDR input, exact return format, or whether the operation is purely read-only.

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 a single, tightly-packed sentence: primary action first, secondary output second, and protocol coverage last. There is no filler or redundancy, and every clause contributes meaningful information.

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 simple two-parameter tool with fully documented schema, this description covers the core behavior and output sufficiently. It lacks only edge-case handling and precise return structure details, which is a minor gap given there is no output schema and the operation is straightforward.

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 coverage is 100%, so the schema already documents both params. The description adds no extra parameter-level detail beyond what is already present, such as format requirements or examples, so the baseline score of 3 applies.

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 clearly states the specific operation: checking whether an IP address is inside a CIDR block. It also names the secondary output (first-to-last range) and declares IPv4/IPv6 support, which distinguishes it from sibling tools like subnet_calc and ip_convert that serve different purposes.

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 usage context is implied by the description: use it when a membership test is needed. However, it gives no explicit guidance about when not to use it or how it compares to sibling alternatives such as subnet_calc, ip_convert, or ipv6_normalize.

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

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

No annotations are provided, so the description carries the full burden. It discloses the three concrete outputs (expanded form, compressed form, address type) and scopes the operation to IPv6 normalization. It does not describe invalid-input handling or exact return structure, but for a pure formatting tool the core behavior is adequately transparent.

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 whole description is one focused sentence with no filler. The primary output is front-loaded, and every phrase carries meaningful information.

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-only formatting tool with no output schema, the description is largely complete: it enumerates the expected outputs and clarifies the input type. It could additionally describe error behavior or output layout, but that is a minor gap rather than a blocking 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?

There is a single required parameter 'address' with no schema description coverage, and the description adds the key semantic that it must be an IPv6 address. However, it does not specify allowed input formats (e.g., brackets, uppercase, IPv4-mapped), nor what happens for invalid addresses, so the compensation is partial.

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 ('Show') and a specific resource ('fully expanded form and correct RFC 5952 compressed form of an IPv6 address'), plus a third output category (address type). This clearly distinguishes it from siblings like ip_convert or subnet_calc by focusing specifically on IPv6 normalization and classification.

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 makes the usage context clear: use this tool when you need expanded or RFC 5952-compressed forms of an IPv6 address and its classification. It does not explicitly name alternatives or state when not to use it, so it does not reach the explicit-when-not/alternatives level.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the output fields (service, protocols, category, software, exposure verdict with reasoning, related ports), the supported input modes, and the limitation that it covers only the 100 ports documented by whatismynetip.com. This gives an agent a clear model of what to expect.

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 compact and front-loaded: it states the core question first, then summarizes return content, then gives usage examples and the optional detail flag. Every sentence contributes information, with no filler or repetition of the tool name.

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 that there is no output schema, the description compensates well by enumerating the response components and the verdict categories. It also explains both numeric and textual query modes. It could add a note about handling unknown ports or no matches, but overall it is sufficient for an agent to call the tool correctly.

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 coverage is 100%, so the baseline is 3. The description adds useful meaning by providing concrete query examples ('redis', 'wireguard') and clarifying that detail:true appends the long explainer and FAQ. This goes slightly beyond the schema's descriptions without being redundant.

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 with a specific purpose: 'What runs on a port and whether it is safe to expose.' It clearly identifies the resource (ports) and the kind of answer provided (service, protocols, exposure verdict), and it is distinct from all sibling tools like reverse_dns, dns_lookup, and mac_lookup.

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 gives concrete input guidance: provide a port number or search by service with examples like 'redis' or 'wireguard', and mentions the detail flag for extended output. It does not explicitly contrast with alternative tools, but the sibling tools serve clearly different purposes, so this is a minor gap.

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

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

With no annotations, the description carries the behavioral burden. It explicitly discloses that the lookup is bundled and works without network, notes the registry size, and mentions extra behavior around multicast, locally-administered bits, and privacy MACs. It doesn't cover error handling or output shape, but the core behavioral traits are well stated.

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 two compact sentences with no filler. Main behavior is front-loaded, and the registry/offline constraint plus secondary capabilities are conveyed efficiently.

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 simple one-parameter read-only lookup, the description is nearly complete: input is fully documented in the schema, and the description explains offline behavior, registry scope, and what the tool can tell the agent. A note about the exact return format would be nice, but it is not essential here.

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 input schema already documents all accepted MAC formats with 100% coverage. The description adds no additional parameter-level meaning beyond the overall lookup purpose, so the baseline 3 applies.

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?

Uses a specific verb ('Identify') with a clear resource ('vendor behind a MAC address'), then adds the registry source and secondary decoding behavior. This clearly differentiates it from the sibling DNS, IP, and subnet tools.

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 makes the intended use case obvious: look up a MAC address vendor, including offline capability. It doesn't name alternatives or exclusion criteria, but the sibling tools are unrelated and the context is unambiguous enough for an agent to decide when to call it.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so well. It transparently reveals that the tool makes external network calls to Cloudflare's trace endpoint and Team Cymru's ASN DNS, and explains why an outside observer is needed. This gives the agent important context about network dependence and external service usage without any contradictions.

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 two sentences with no wasted words. The first sentence front-loads the tool's output and core value, while the second sentence adds necessary behavioral context about external dependencies. Every phrase contributes meaning.

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 zero-parameter tool with no output schema, the description is complete: it enumerates all returned data fields, explains the mechanism, and implies the need for internet connectivity. An agent can decide to invoke the tool and know what to expect from the response.

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 input schema has zero parameters, and the baseline for zero-parameter tools is 4. The description reinforces that the tool operates on 'this machine' and requires no caller-supplied input, so an agent knows there are no arguments to configure.

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 exactly what the tool returns: the public IP address as seen from the internet, plus edge location, reverse DNS, ASN, organisation, and datacenter/VPN hint. It clearly identifies a specific resource and outcome, though it lacks an explicit verb like 'gets' or 'returns.' The subject matter also differentiates it from siblings like reverse_dns and dns_lookup, which focus on other DNS/IP lookups.

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 context is implied rather than stated: the description indicates this tool requires an outside observer and external network calls, so it should be used when an agent needs the machine's egress/public IP. However, it does not explicitly say when not to use it or name alternative tools for related needs, such as reverse_dns for a specific IP's PTR record.

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

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

With no annotations, the description carries the behavioral burden. It states the operation is a PTR lookup and that the result is the mapped name 'if any', which covers the core behavior. It does not disclose response format, error behavior for invalid IPs, or what happens when no PTR record exists.

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 a single focused sentence with no filler. It front-loads the core verb and adds useful scope details ('IPv4 or IPv6', 'if any') without wasting words.

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-only DNS utility with no output schema, the description covers the input domain and the general return value. The only gaps are explicit failure/response formatting details, which are minor given how simple the operation is.

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 provides only a bare 'ip' string with no description, and the description compensates by specifying that it accepts an IPv4 or IPv6 address and that the lookup maps that address to a name. It lacks format examples or edge-case constraints, but for a single simple parameter this is adequate.

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 operation ('PTR lookup') and clarifies the direction of the mapping ('what name the address maps back to'). This clearly distinguishes reverse_dns from sibling tools like dns_lookup, even without naming them explicitly.

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 implies this tool is for IP-to-name lookup rather than name-to-IP lookup, which is sufficient context given the sibling list. However, it does not explicitly state when to prefer this tool over dns_lookup or other alternatives, leaving usage decisions to inference.

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

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

No annotations are present, so the description carries the transparency burden. It discloses IPv4/IPv6 support and explicitly highlights correct /31 and /32 handling, which are meaningful edge-case behaviors. Its output list also makes clear this is a pure calculation with no side effects, though it does not state what happens on invalid input.

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 definition is exactly two sentences with no filler. The first sentence front-loads the purpose and expected outputs; the second concisely adds protocol support and special cases. Every phrase contributes information an agent needs.

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, low-complexity calculator with no annotations and no output schema, the description lists the outputs, accepted input forms, and important edge cases. It could strengthen by naming exact return field keys or invalid-input behavior, but an agent can select and invoke the tool correctly with the information provided.

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 coverage is 100% and the parameter description already gives examples of CIDR, dotted-mask, and IPv6 forms. The tool description reinforces this and adds edge-case context, but does not meaningfully extend the semantic meaning of the cidr parameter. Baseline 3 applies because the schema already documents the parameter well.

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 action ('work out a subnet') and the resource (CIDR or address/dotted mask), then enumerates concrete outputs (network, netmask, wildcard, broadcast, usable range, counts). This clearly dsistinguishes it from siblingtools such as ip_in_subent (membership check) and ip_convert (format conversion).

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 usage is implied by the operation ('work out a subnet'), so the agent can infer when to call it. However, the description does not explicitly mention alternatives or provide when-not-to-use guidance, even though sibling tools exist in the same domain. No routing language distinguishes it from ip_in_subnet or ipv6_normalize.

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

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

With no annotations provided, the description carries the behavioral burden and does this well by stating that it makes a live connection, reports the certificate actually served, and refuses private/reserved addresses. It does not discuss edge cases like timeouts or whether the connection performs full validation, but it discloses key operational behavior.

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 two sentences with no filler. The first sentence front-loads the tool's outputs, and the second sentence adds port and host constraints. Every clause adds useful information.

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?

There is no output schema and no annotations, yet the description fully enumerates the returned certificate data and the main input constraints. An agent can predict what the tool does, what it returns, and when it refuses to operate, making the definition complete for this complexity level.

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%: host and port are already documented in the schema. The description adds minor reinforcement ('Accepts a URL', 'Any port default 443') but does not materially expand parameter meaning beyond the schema.

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 ('Connect') and resource ('TLS certificate'), then enumerates exactly what it reports. It is clearly distinct from sibling network tools like dns_lookup, reverse_dns, or lookup_port because only this one inspects live TLS certificates.

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 makes the intended use clear: connect to a public host and inspect its served certificate. It also specifies that private or reserved addresses are refused, which helps the agent know when the tool will not work. It does not explicitly name alternative tools, but the context is sufficient for selection among the siblings.

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