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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only extraction, but does not disclose whether URL input is fetched over the network, whether JavaScript is executed, whether authentication or rate limits apply, or what safety considerations exist. The output schema covers return values, but key behavioral traits are absent.

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 front-loaded sentence with no wasted words. The purpose and accepted input forms are stated efficiently, and there is no redundant restatement 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?

The tool is simple, has one required parameter, and has an output schema, so the description's coverage of purpose and input forms is enough to attempt a call. However, with no annotations and no schema descriptions for the parameter, missing behavioral context such as network fetching or execution semantics leaves a clear completeness 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% for the single 'source' parameter. The description partially compensates by clarifying that source can be pasted JavaScript content or a URL, which is meaningful beyond the bare string schema. It still lacks format details such as URL scheme expectations, size limits, or 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 states a specific verb, 'Extract,' and names three concrete resource types: secrets, endpoints, and parameters. It also scopes the input to JavaScript, which clearly separates it from the DNS, WHOIS, CVE, HTTP, port-scan, and scope siblings. It does not explicitly name any alternative tool, so sibling differentiation is implicit rather than stated.

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 parenthetical 'pasted content or a URL' implies the tool is for JavaScript analysis from either raw input or a fetched script. However, it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance, leaving the agent to infer usage from the 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?

No annotations, so the description carries the burden; 'Fetch' implies a read-only operation but authorization needs, rate limits, whether data is live from NVD or cached, and error behavior for an unknown ID are all unstated. It does add that the response contains 'full details and references', which is useful context beyond the name.

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, and the example is embedded efficiently. It could be tightened only marginally.

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?

An output schema exists and the tool has one simple required parameter, so little description is strictly needed. Still, for a lookup tool the agent has no information about failure modes or upstream source, which is a noticeable 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 coverage is 0% for the single cve_id parameter, but the inline example 'CVE-2024-3094' conveys the expected format, which is genuine added meaning. It does not address case sensitivity, normalization, or validation behavior on malformed IDs.

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 (Fetch) and resource (full details and references for a specific CVE id), which clearly separates it from a search-style operation. It does not explicitly name the sibling cve_search, so differentiation is inferred rather than asserted.

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?

Use is implied by 'specific CVE id', which contrasts with the list-oriented cve_search sibling, but the description never says when to prefer this over cve_search or what to do when the ID is unknown. No explicit exclusions or prerequisites 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, the description carries the full behavioral burden; it discloses the data source (NVD), that results are 'recent', and that min_cvss filters results. It omits rate-limit behavior, the definition of 'recent', and pagination/limit semantics, leaving meaningful gaps for a search 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 front-loaded sentence with no wasted words; the scope (NVD, recent, keyword) and filter (min CVSS) are stated immediately. It is appropriately sized, though its brevity edges into under-specification rather than pure conciseness.

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?

An output schema exists, so return values need not be explained, and the description supplies the source, keyword, and CVSS filter. However, without annotations, undefined 'recent', undocumented limit behavior, and no differentiation from cve_lookup leave the definition only minimally complete.

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 explains keyword and min_cvss only superficially and never mentions the limit parameter, its default of 20, or whether a maximum 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?

States a specific verb and resource: search the NVD for recent CVEs by keyword, with a CVSS filter. This is clear on its own, but it never distinguishes itself from the sibling cve_lookup, which an agent could easily confuse with this tool.

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 guidance on when to use this versus cve_lookup, whether the NVD API key is required, or what 'recent' means. The only implied usage is keyword-based CVE search, and alternatives are not mentioned.

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 disclosure burden; it does state the transport (DNS-over-HTTPS), which is genuinely useful context. However, it never states that the operation is read-only, whether lookups are rate-limited or logged, or how NXDOMAIN/timeouts are surfaced.

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, front-loaded with the verb and fully informative about record coverage and transport. No waste, though the parenthetical transport note is the only secondary detail.

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?

An output schema exists, so return values need not be explained. Missing is what an agent needs to call correctly: whether all listed record types are always fetched or a subset returned, and how failures are reported for a low-complexity but network-dependent lookup.

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 (domain) with 0% schema description coverage, so the description should clarify accepted format (bare domain vs FQDN, trailing dot, IDN/punycode) but does not. The enumerated record types at least suggest no type selector is needed, but the parameter itself remains undescribed.

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?

Names a specific verb (Resolve) and resource (DNS records for a domain) and enumerates the supported record types, which is enough for an agent to know exactly what it does. It does not differentiate itself from siblings like whois or recon_subdomains, but the operation is distinct enough by 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?

No guidance on when to use this versus whois, recon_subdomains, or http_probe, and no exclusions or prerequisites. The agent must infer that this is the tool for raw DNS record resolution from the name alone.

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 behavioral burden. It usefully discloses that this is an active probe requiring scope, but it does not explain how scope is verified, whether the probe is intrusive, or what operational constraints apply.

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 short, front-loaded, and has no wasted text. Both the core action and the scope precondition are stated compactly.

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?

An output schema exists, so return values need not be explained. However, for an active probing tool with no annotations, the description should more fully explain the scope requirement and its relationship to scope_status.

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 only parameter is an undescribed `url` string. The description implies the parameter is the target URL, but adds no format, scheme, redirect, or validation semantics beyond that bare implication.

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 and resource: fetch a URL and report status, key headers, and detected technologies. That is clear, but it does not distinguish this tool from overlapping siblings such as security_headers or port_scan.

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 phrase "[active — needs scope]" hints at a prerequisite, but the description does not explain when to choose this tool over security_headers, port_scan, or scope_status. There is no explicit when-to-use or when-not-to-use guidance.

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 burden; it does disclose that this is an active scan requiring scope authorization, which is real behavioral context beyond the schema. It omits rate limits, timeouts, detection risk, and expected duration for a network-scanning 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?

One compact sentence plus a bracketed qualifier; the technique and default behavior are front-loaded. The bracketed tag is slightly cryptic but earns its place by flagging the active/scope constraint.

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?

An output schema exists, so return values needn't be explained. But for an active scanning tool with zero annotation coverage, the missing scope-check mechanics and port-format guidance leave gaps an agent must guess at.

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, and it only partially does: it clarifies that 'ports' defaults to common ports. It gives no format guidance for the ports array (ranges? list of ints?) and no host format 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?

States a specific technique, target, and outcome: 'TCP-connect scan a host for open ports'. This is clearly distinguishable from siblings like http_probe or dns_lookup, though it doesn't explicitly contrast with 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?

'[active — needs scope]' implies a prerequisite check (likely scope_status) and flags this as an active probe, which is useful routing signal. However, it doesn't state when to choose this over http_probe or what 'needs scope' operationally means for the agent.

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 does disclose the meaningful trait that enumeration is passive and derived from CT logs, so no traffic touches the target. It omits the corollary limits (results only include names with logged certificates, no auth/rate-limit notes), which a recon agent would want.

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 the method and scope stated up front and no filler. Every phrase (passively, sub-domains, Certificate Transparency) 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?

An output schema exists, so return values need not be explained, and the tool takes a single required parameter, which keeps the burden low. The description covers purpose and method adequately, though it leaves the input format and coverage limitations unstated.

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 required parameter with 0% schema description coverage, so the description must compensate. 'Of a domain' weakly signals that the input is the parent/apex domain rather than a hostname, but it does not specify format (bare apex vs. URL vs. wildcard) or whether subdomains of subdomains are 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?

The description states a specific verb (enumerate), a specific resource (sub-domains of a domain), and the data source (Certificate Transparency logs). This implicitly separates it from the active-resolution sibling dns_lookup via 'passively,' but no sibling is named 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: 'passively' hints that this is a non-intrusive first step that complements active tools like dns_lookup or http_probe. There is no explicit when-to-use, when-not, or named alternative.

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 of behavioral disclosure. It implies a read-only status check but does not state permissions, side effects, or what 'active tools' means, leaving significant behavioral gaps.

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, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's core purpose.

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 tool is simple: zero parameters and an output schema exists, so the description need not explain return values. It is nearly complete for invocation, though the term 'active tools' remains slightly ambiguous without 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?

The tool takes zero parameters, so parameter semantics require no description. The baseline score for zero-parameter tools is 4.

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 ('Report') and a clear resource ('whether an authorization scope is configured for active tools'). It is distinct from the sibling tools, which are reconnaissance and scanning utilities, but it does not explicitly differentiate itself from 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 description gives no explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions. Usage is only implied by the phrase 'active 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, the description carries the full burden, and it does disclose two meaningful traits: the scan is 'active' (it sends requests to the target) and it requires scope authorization. It says nothing about rate limits, failure modes, or whether the target must be owned, so a mutation-adjacent active tool remains partially opaque.

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 compact fragments, front-loaded with the purpose before the bracketed qualifier; nothing is wasted. The bracket notation is terse to the point of ambiguity, which keeps it just under top marks.

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?

An output schema exists, so return values needn't be explained, and the active/scope caveat covers the main behavioral risk. However, with zero annotation coverage and zero parameter documentation, the definition leaves an agent guessing about URL format and what 'needs scope' concretely requires.

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 required 'url' parameter is undocumented. 'A site's' only loosely implies the parameter is a site URL, with no guidance on whether a scheme, path, or bare hostname is expected, so the description does not compensate for the schema gap.

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 ('Audit a site's HTTP security headers') plus the output shape ('grade them A–F'), which is enough to separate it from siblings like http_probe or port_scan. It stops short of naming an alternative explicitly, so it is clear but not maximally differentiated.

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 '[active — needs scope]' tag implies this is an active scan that requires an in-scope target, which is a useful usage condition, but it is cryptic and never states when to prefer this over http_probe or what happens if scope is missing. Usage is implied rather than spelled out.

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, so the description carries the full burden. It helpfully discloses the protocol (RDAP), which implies read-only and gives a hint about data source/coverage, but says nothing about rate limits, TLD/registrar coverage gaps, or behavior for unregistered or non-RDAP domains.

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 tight sentence with the resource and expected output fields front-loaded; no wasted 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?

The tool is simple and an output schema exists, so return values needn't be explained. What's missing is minor but real: input format for the domain and failure behavior for unregistered/unsupported domains.

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% with no description of the single 'domain' parameter. The description does not clarify whether the input should be a bare apex domain, a subdomain, or a URL, which is a real ambiguity for lookup tools.

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 ('domain registration data') with parenthetical examples of the fields returned (registrar, dates, nameservers). This is distinguishable from siblings like dns_lookup or recon_subdomains by resource type, though no sibling is explicitly named.

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: call it when you need registration/ownership data. There is no statement of when not to use it or how it relates to dns_lookup (which covers DNS records, a related but different need).

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