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

No annotations are provided, so the description carries the full burden, yet it discloses almost nothing behavioral: not which headers are evaluated, whether redirects are followed, whether the endpoint is fetched over the network, or whether auth/rate limits apply. 'Audit' implies a passive read, but that is inference, not disclosure.

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?

One short sentence, front-loaded with the action and the object, with no filler whatsoever.

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 and no annotations, the description should at least sketch what an audit returns (which headers, pass/fail framing) or what a valid target looks like. For a simple one-parameter probe it is minimally sufficient but leaves real gaps.

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 0% for the single `url` parameter, so the description must compensate; it only implies the value should be an HTTP(S) endpoint via the phrase 'HTTP(S) endpoint'. It adds no format, scheme, or path guidance beyond that.

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 (audit) and resource (HTTP(S) response headers), which cleanly separates it from siblings like check_ssl (TLS/cert) and scan_ports (open ports). It doesn't explicitly name those siblings, so it stops 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?

There is no statement of when to use this versus check_ssl or scan_ports, no prerequisites, and no exclusions. The only usage signal is inferred from the tool name and the word 'audit'.

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 exist, so the description carries the full behavioral burden. It reveals what data is returned (validity, expiry, issuer, SANs, cipher) but says nothing about network reachability, timeout/failure behavior for unreachable hosts or invalid certs, or whether the call is strictly 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?

A single dense sentence with the resource and output fields front-loaded and no filler. It is terse to the point of being a fragment, but every word carries 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?

With no annotations and no output schema, the description should cover failure modes, port behavior, and return structure. It lists the inspected fields, which partly substitutes for a return spec, but leaves an agent without guidance on connectivity requirements, errors, or parameter usage.

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 0%, so the description must explain host and port, yet neither parameter is mentioned. Only an indirect hint exists via "a host's TLS certificate"; the port default of 443 is left entirely to the schema with no guidance on when to override it.

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 (Inspect) and resource (host's TLS certificate) and enumerates the returned fields: validity, expiry, issuer, SANs, cipher. This clearly separates it from siblings like check_http_security_headers or scan_ports, though it doesn't name an alternative 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?

Usage is only implied by the name and the listed certificate fields; there is no statement of when to choose this over check_http_security_headers or scan_ports, and no prerequisites or exclusions 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?

No annotations are provided, so the description carries the full burden, yet it discloses nothing about side effects, output format (hex vs base64), or what happens when the algorithm list is omitted. The pure-computation nature is inferable from "compute ... of a string," but nothing confirms it or describes the result shape.

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?

A single front-loaded sentence with zero filler; the operation, input type, and supported algorithms all appear before anything else.

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 low-risk utility with no output schema and only two parameters, the description is roughly adequate to invoke it. It still omits the default algorithm set and the return format, which an agent needs to interpret 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 0%, so both parameters rely entirely on the description. The algorithm names in the description loosely map to the `algorithms` parameter, but the description never explains that parameter's behavior when null/defaulted, nor does it clarify the `text` input beyond "a string."

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 ("Compute cryptographic digests ... of a string") and enumerates the supported algorithms, which clearly separates it from identify_hash in the sibling list. It doesn't name that sibling explicitly, but the operation and input domain are unambiguous.

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 by the phrase "of a string," which signals this tool hashes literal text rather than files or streams, and the contrast with identify_hash is inferable. There is no explicit when-to-use/when-not or named alternative, so guidance is only implicit.

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 does useful work by disclosing the five supported schemes, which is real behavioral information, but it says nothing about error behavior on invalid input, whether decoding is best-effort, or what the caller receives.

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?

A single front-loaded sentence with no filler; the actionable information (verb + scheme list) arrives immediately. It is arguably over-compressed rather than padded, but 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?

This is a simple two-parameter, no-output-schema utility, and the description covers the core contract: decode text with one of five schemes. The main omission is that, absent an output schema, the description should say the tool returns the decoded string (and what happens when decoding fails), but for a low-risk pure transform this is a minor gap.

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 0% and the scheme parameter has no enum, so the description's list of five accepted values is the only place the valid domain is documented — meaningful compensation for the `scheme` parameter. The `text` parameter gets no explanation at all beyond the tool being about decoding, and it is not stated whether scheme is case-sensitive or free-form.

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 (decode) and resource (text) and enumerates the supported encodings, which immediately differentiates it from the sibling encode_text by direction. It never names encode_text explicitly, so an agent must infer the pairing from the verb alone.

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 strongly implied by the name and the scheme list — this is the tool to reach for when you have encoded input. However, there is no explicit statement of when to prefer it over encode_text, nor any prerequisite or input-form guidance (e.g., whether whitespace/padding must be preserved).

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 present, the description carries the full disclosure burden, yet it says nothing about failure modes (NXDOMAIN, SERVFAIL), network/timeout behavior, or rate limits. The only behavioral hint is the implicit read-only nature of a lookup, which is not 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?

A single front-loaded sentence with no filler; the action and scope arrive first and the record-type list adds concrete value rather than padding.

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 read tool with no output schema, the description covers the essentials of what is queried. It omits the default behavior when record_types is null and any indication of result shape or error conditions, which leaves gaps an agent would notice on first 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 coverage is 0%, so the description must compensate. It partially does: it enumerates the accepted record type values (A, AAAA, MX, NS, TXT, CNAME, SOA), which the schema leaves as an unconstrained string array, and ties them to the domain being resolved. It does not say what happens when record_types is omitted (schema default null) or what domain format is expected.

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?

Specific verb ('Resolve') plus resource ('DNS records') and an enumerated set of record types, so the agent knows exactly what comes back. It does not explicitly name reverse_dns as the inverse sibling, but the forward-lookup framing plus 'for a domain' makes the distinction reasonably evident.

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?

No statement of when to use this versus reverse_dns, whois_lookup, or enumerate_subdomains, and no prerequisites or exclusions. Usage is inferable from the name but not guided by the description.

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 disclosure burden, yet it says nothing about side-effect freedom, whether rot13 is reversible/symmetric, whether url encoding is full-percent or component-wise, or what the return value looks like. It only restates the operation.

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?

A single front-loaded sentence with zero filler; the scheme enumeration is the most useful content and comes first. It is terse enough that nothing is wasted, though brevity here borders on under-specification rather than elegance.

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 utility with no output schema, the description covers the input space reasonably but leaves the return format and the text parameter's expected content unstated. Adequate but with clear gaps given the absence of annotations.

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 0% and both parameters are bare strings, but the description does supply the otherwise-missing enumeration of valid scheme values (base64, base64url, hex, url, rot13), which is real added value. The text parameter still gets no semantics beyond its name, so it only partially compensates.

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 gives a specific verb (encode) plus a resource (text) and enumerates the supported schemes, so the tool's function is unambiguous. It does not name the obvious sibling decode_text, so it stops short of full differentiation.

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 by the verb and the scheme list; there is no explicit statement of when to reach for this tool versus decode_text, nor any guidance on how to pick among the five schemes. An agent can infer the intent but must guess at selection criteria.

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; it discloses the passive, CT-log-based nature, which is useful behavioral context. It omits limitations such as only covering domains with logged certificates, whether results are deduplicated, auth/rate limits, and output 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?

One front-loaded sentence with no filler. It states the action and source immediately.

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 no annotations, no output schema, and zero schema descriptions, the definition is under-specified. It does not explain return values, result completeness, or parameter expectations, leaving an agent to infer important details.

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 one parameter, 'domain', and schema description coverage is 0%, so the description should compensate. It never explains what domain value is expected (apex domain? wildcard? hostname?) or how it is used.

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 ('enumerate'), resource ('subdomains'), and data source ('public certificate transparency logs'), which differentiates it from active DNS siblings like dns_lookup. It does not explicitly name or compare against those siblings, so it stops 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?

No when-to-use or when-not-to-use guidance is given. The word 'passively' hints at context but does not tell an agent when to choose this over dns_lookup or other reconnaissance tools.

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 burden and does meaningful work: 'local-only, never logged' is a concrete, verifiable privacy guarantee that matters greatly for a credential-handling tool, and it names the two outputs (entropy estimate, weakness flags). It stops short of stating whether the password is persisted in any form or how scoring is computed.

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?

One sentence does all the work: action first, output second, safety caveat last. There is no filler and nothing important is buried.

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, non-destructive utility with no output schema, the description is nearly sufficient – it discloses both the return concept and the privacy posture. Minor remaining gap is that the exact response shape (score scale, list of weakness categories) is unspecified.

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 0%, so the single 'password' parameter is undocumented in the schema. The description compensates only implicitly – it says the password's entropy is estimated, which tells the agent what to supply, but adds no guidance on length, encoding, or whether raw or masked input is expected.

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 pairs specific verbs ('estimate entropy', 'flag common weaknesses') with a clear resource ('a password'), so the agent knows precisely what it returns. It is also implicitly distinguished from hash-oriented siblings like compute_hashes and identify_hash, though it never names them.

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 purpose implies when to call it – before accepting or setting a password – but the description gives no explicit when-to-use, when-not-to-use, or alternative (e.g., compute_hashes for hashing rather than strength scoring). Usage must be inferred from the tool name and stated purpose.

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 burden, but it does disclose useful behavior: the result is a guess based on length and pattern, i.e. a heuristic rather than a definitive determination. It does not mention that multiple algorithms can match, nor anything about auth/permissions or response shape.

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?

A single tight sentence with the resource and method front-loaded and no filler. Nothing wasted.

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 trivial one-parameter tool this is nearly adequate, but with no output schema and no annotations the description should say what it returns (single best guess vs. ranked candidates) and note ambiguity. That is the main missing piece.

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 one parameter with 0% schema description coverage, so the description must compensate; calling the input a 'hash string' does establish what 'value' means. It adds no format or length constraints beyond that, so it is only partially compensating.

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 ('guess/identify') and resource ('algorithm/format of a hash string'), which clearly separates it from compute_hashes (which produces hashes) and estimate_password_strength. It stops short of naming or explicitly contrasting those siblings, so a 4 rather than 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 agent must infer 'call this when you have a hash string of unknown type.' There is no explicit when-to-use, when-not, or reference to the nearest alternative (compute_hashes). Sibling context provides the only differentiation.

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; it does disclose the payload shape (description, CVSS score, references) and the upstream source (NVD), which signals freshness and provenance. It says nothing about NVD rate limits, API-key requirements, or behavior when a CVE ID does not exist.

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?

A single front-loaded sentence that spends its words on verb, resource, return fields, and data source. Nothing redundant or padded.

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 field list is a reasonable stand-in for return values. The missing pieces are the identifier format and not-found/error behavior, which matter because the schema documents neither.

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?

One required parameter with 0% schema description coverage, so the description must compensate. It clarifies that the parameter is an identifier rather than a keyword, but never states the expected format (e.g. CVE-YYYY-NNNN) or whether a bare number is accepted.

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?

Specific verb (fetch) and resource (CVE details) with the data source named (NVD) and the returned fields enumerated. It doesn't explicitly contrast itself with the sibling search_cves, leaving the ID-lookup vs. keyword-search distinction to inference from the name.

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 no when-to-use or when-not guidance and never mentions search_cves as the alternative for discovery. An agent that only has a vendor or product name gets no routing hint that this tool is the wrong choice.

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 burden. It does disclose the PTR mechanism, which usefully signals that answers may be missing for IPs without reverse zones, but it says nothing about timeout behavior, failure/empty results, or resolver specifics.

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?

A single tight sentence that front-loads the action and resource with zero filler. Every clause 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 one-parameter lookup with no output schema, the description is nearly sufficient; 'hostname(s)' usefully hints that multiple records may be returned. Only the absence of failure-mode or format notes keeps it from full completeness.

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?

Only one parameter with 0% schema coverage, so the description must compensate. Saying the input is 'an IP address' clarifies the expected format beyond the bare 'ip' string field, but gives no IPv4/IPv6 or formatting detail.

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 ('reverse-resolve') and resource ('IP address to hostname(s)') plus the mechanism (PTR record). This clearly distinguishes it from forward-looking siblings like dns_lookup, though it never names that sibling 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 reverse-vs-forward distinction is implied by 'reverse-resolve an IP address', so an agent can infer when to use it. However, there is no explicit 'use dns_lookup for hostnames' routing or any stated prerequisites, leaving guidance 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 exist, so the description carries the full burden; it does add the important safety/authorization precondition and the default of authorized=false. However, nothing is said about scan scope ('common' is undefined), whether the traffic is intrusive or detectable/logged, timeouts, rate limits, or what the result looks like.

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 short sentences, front-loaded with the purpose, with the precondition immediately after; nothing is padding. Minor awkwardness from the mid-sentence line break but no wasted content.

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?

The safety gate is covered, which is the most important gap for a security-scan tool with no annotations and no output schema. But an agent still lacks the operational picture: what 'common ports' means, how to pass `ports`, and what the response contains.

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 0%, so the description must compensate for all three parameters. It adds real meaning only for `authorized` (must be true only with confirmed permission); `host` gets no format guidance (IP vs hostname) and the `ports` parameter is never mentioned, with the text even implying a fixed 'common' set.

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?

A specific verb (check) and resource (open TCP ports) on a named target, clearly distinct from the DNS/SSL/CVE siblings. The only blur is 'common TCP ports' versus a `ports` parameter that implies arbitrary port lists.

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?

Explicitly states the precondition for use: call with authorized=True only after the user confirms ownership or written permission. It gives a clear when-to-use gate but never mentions alternatives such as check_ssl or other reconnaissance siblings when the agent's task is adjacent.

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 almost nothing: no rate-limit or API-key context for NVD, no pagination behavior, no result ordering, no indication of result volume. Only the mutability profile can be inferred from the word 'Search'.

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?

A single efficient sentence with the core action front-loaded and the example appended where it helps. It is not padded, but it is thin for a tool with two largely undocumented parameters.

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, so the description should say what a result looks like and how paging works, but it does neither. For a search tool with an undocumented pagination parameter and a same-domain sibling, this leaves the agent guessing.

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 0%, so the description must compensate. It clarifies that 'keyword' means a term like a product name, which is genuinely useful, but results_per_page is never mentioned and the keyword's matching semantics (substring, exact, CVE-ID form) remain undefined.

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?

Specific verb (Search) plus resource (NVD database for CVEs) with a concrete example of the keyword ('e.g. a product name'). However, it does not distinguish itself from the sibling tool lookup_cve, so an agent cannot tell from the description alone which of the two to pick.

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?

There is no statement of when to use this versus lookup_cve, which appears to be the sibling for direct CVE retrieval. No prerequisites, no exclusions, no note that this is keyword-based discovery rather than exact-ID lookup.

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 exist, so the description carries the full burden, yet it says nothing about rate limits, registry timeouts, redacted privacy fields, or what the response looks like. 'Public' is the only behavioral hint, which is not enough for a network-facing lookup tool.

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?

A single tight sentence with the resource and scope front-loaded and no filler. There is no wasted text, though the terseness contributes to the gaps elsewhere.

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 tool with no output schema, a single sentence is close to adequate, but the absence of annotations means the agent gets no signal about safety profile, response shape, or error behavior.

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 0% and the single parameter 'domain' has no description in the schema, but the prose phrase 'for a domain' at least identifies what the input is. It adds no format guidance (bare domain vs URL vs punycode), so it only partially compensates.

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 ('Look up') and resource ('public WHOIS registration data') scoped to a domain, so the agent knows exactly what comes back. It doesn't explicitly contrast itself with siblings like dns_lookup or reverse_dns, though the WHOIS resource is distinctive enough in practice.

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 word 'public' hints that privacy-redacted registrant data is what to expect, but there is no statement of when to prefer this over dns_lookup or check_ssl, and no mention of TLD support or failure cases.

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