ScanMalware.com URL Scanner

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the threshold default (0.7) and clarifies that exclude_exact_matches 'drops identical copies' — useful semantics, but no mention of result ranking, scoring semantics, or result volume 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 dense sentence covering purpose and all three optional params, plus a short use-case sentence. Front-loaded and free of filler, though the parameter clauses are packed into a single run-on sentence.

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 has an output schema, so return values need not be described, and annotations cover the safety profile. The description supplies purpose, the key parameter behaviors and a use case, leaving only minor gaps (threshold scale, limit default) for a read-only similarity search.

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 carry the load and largely does: it explains content_sha256 as the file's content hash, threshold as a similarity floor with default 0.7, limit as a cap on results, and exclude_exact_matches as dropping identical copies. It omits the limit default (10) and the direction/scale of the threshold, so it is strong but not exhaustive.

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+resource ('Find JavaScript files similar to the file with this content SHA-256'), which distinguishes it from hash-exact siblings like search_js_fingerprint_by_sha256. However, it never names or contrasts with the near-identical siblings get_jsfingerprint_similar or search_js_fingerprint_by_fuzzy_hash, leaving the agent to infer the difference.

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 closing sentence 'Useful for finding modified versions of a known script' gives an implied use case, which is more than nothing. But there is no when-not guidance, no mention of the fuzzy-hash or normalized-hash alternatives, and no prerequisite stating the file must already be indexed.

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?

Annotations already declare this a safe, idempotent, read-only operation, so the safety profile is covered. The description adds genuinely useful context beyond the annotations: the eventual-consistency/latency window ('a few minutes... returns not found until then') and the semantic caveat that it can disagree with the scanner verdict. That is meaningful added value, though still not a full behavioral picture.

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?

Three dense sentences with the payload description first, then timing, then the parameter definition. The field enumeration carries real meaning (including the LEGITIMATE to CONFIRMED_SCAM range) rather than padding, and nothing is 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?

An output schema exists, so return-value shape need not be re-explained, yet the description still usefully names the fields. With annotations covering safety and the description covering timing, disagreement semantics, and the lone parameter, an agent has everything needed to call this 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 description coverage is 0%, so the schema alone does not explain the single parameter. The description compensates by defining scan_id as the UUID of a ScanMalware scan, establishing both format and referenced entity.

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 (Get) and resource (the AI analysis of one scan) and enumerates exactly what it returns: classification, scam type, risk score, confidence, impersonated brand, evidence. That detail clearly sets it apart from get_scan_result/get_scan_summary in practice, but it never names an alternative, so sibling differentiation is implicit rather than explicit.

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?

Provides clear context about when the result is meaningful: the analysis is produced a few minutes after the scan completes and returns not-found until then. It also warns that it can disagree with the scanner's own verdict, but offers no explicit when-not or named alternative for getting the scanner verdict instead.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only that results include status, success flag and timing, which is return-shape detail rather than a behavioral trait like auth needs or rate limits. With annotations carrying most of the burden, a 3 is appropriate.

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?

Three tight sentences: purpose first, then the fields returned, then the motivating use case, then the parameter clarification. No filler and no repetition of title or structured fields.

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 described, and the description still covers purpose, use case and parameter format. Its only gap is not routing the agent away from look-alike siblings such as get_analyzer_stats or search_analyzer_high_risk.

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 scan_id parameter is undocumented in the schema, and the description compensates by stating it is the UUID of a ScanMalware scan. That supplies format and referent meaning beyond the bare string type, which is exactly what the low coverage requires.

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 (list) and resource (analysis modules for one scan), with examples of what a module is and what each row contains. It contrasts implicitly with aggregate siblings like get_analyzer_stats by scoping to 'one scan', but never names an alternative explicitly, keeping it 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?

Provides a concrete use case: 'Useful for checking why a result is missing.' That is clear context for when to reach for this tool rather than a scan-summary or stats endpoint. However, it names no alternatives and gives no exclusions, so it stops short of the 5 bar.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the aggregation scope (platform-wide rather than per-scan), which is genuine behavioral context, but says nothing about auth, rate limits, or freshness of the counts.

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 with no filler; the resource and its output content are front-loaded, and the scoping caveat follows immediately. 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?

An output schema exists and no parameters are required, so the description need not explain return values; annotations carry the safety profile. It is essentially complete, with only the mild redundancy between 'platform-wide' and 'not a particular scan' keeping it from a 5.

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 per the rubric the baseline is 4. There is nothing for the description to clarify beyond the empty 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?

Names a specific verb and resource ('Get platform-wide statistics for the scan analysis modules') and even spells out what the statistics contain ('the modules and their run counts'). The final clause distinguishes it from scan-scoped siblings like get_analyzer_results.

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?

'Describes the service, not a particular scan' gives a clear selection condition that separates this aggregate tool from the many per-scan siblings. It stops short of naming a specific alternative (e.g., get_analyzer_results) or an explicit when-not-to-use case, so it is context without exclusions.

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?

The annotations already declare this as a read-only, idempotent, non-destructive, open-world operation, so the safety profile is covered. The description adds the returned content categories, but says nothing about authentication needs, caching, rate limits, or any other operational behavior beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that names the resource and lists the return categories with no filler. 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?

For a simple, zero-parameter metadata endpoint with rich annotations and a dedicated output schema, the description is sufficient. It tells the agent what categories of information will be returned without needing to explain output structure or safety behavior, which are covered elsewhere.

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 no parameters, so there is no parameter documentation burden. The baseline for a zero-parameter tool is 4, and the description appropriately avoids repeating schema details.

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 ('Get') and resource ('ScanMalware API' root), then enumerates the exact fields returned: name, version, status, endpoints, and features. This makes the tool's scope clear, though it does not explicitly distinguish itself from related metadata endpoints like get_health or get_platform_stats.

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 states what the tool returns but gives no indication of when to use it versus alternatives. There is no mention of prerequisites, discovery workflows, or the sibling tools it might overlap with, leaving the agent to infer usage entirely.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'detected flag' return cue and the phishing-kit interpretation context, but nothing about rate limits, permissions, or failure modes.

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?

Three short sentences, front-loaded with what is returned and followed by the domain rationale and the parameter note. Little waste, though the phishing-kit sentence is more flavor than operational 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 needn't be spelled out, and annotations cover the read-only/idempotent profile. For a single-parameter getter the description is sufficiently complete; only explicit routing versus sibling scan getters is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the only parameter is titled just 'Scan Id', so the description carries the burden – and it does, stating scan_id is the UUID of a ScanMalware scan. That meaningfully clarifies expected input format beyond the bare schema title.

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: retrieve bot-protection and CAPTCHA services detected on a scanned page, with a concrete example (Cloudflare Turnstile) and a detected flag. The scope is distinct from sibling getters like get_technologies_by_scan or get_favicon, though it never names those alternatives 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 implied by the phishing-kit rationale (these services hide kits from scanners), which hints at when an analyst would care. There is no explicit when-to-use/when-not guidance and no named alternative among the many sibling scan getters.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only the domain meaning of 'capabilities' (detection content size); it says nothing extra about rate limits, auth, or day-boundary behavior that annotations don't already imply.

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 naming the resource, the returned metric, and the parameter format with zero filler.

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 a rich annotation set, an output schema covering the return value, and a single documented parameter, the description is nearly sufficient for correct invocation. The only real gap is routing guidance between this tool and get_latest_capabilities.

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 carries the burden and does so reasonably: it names scan_date and supplies the required YYYY-MM-DD format, which the schema does not. It stops short of clarifying timezone or whether the date must correspond to an existing scan.

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 (Get) and resource (ScanMalware's detection content size) and even enumerates the content types covered — indicators, detection rules, ClamAV signatures. The phrase 'on a given date' implicitly separates it from get_latest_capabilities, but that sibling is never named, so differentiation is inferred 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?

There is no explicit guidance on when to call this versus the obvious alternative get_latest_capabilities, nor any prerequisite or exclusion. Usage must be inferred entirely from the phrase 'on a given date'.

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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld. The description adds genuine behavioral context beyond that: it discloses the return content shape (event count, whether collection ran) and the empty-case behavior ('explanatory note when the page wrote nothing'), which an agent cannot get from annotations alone.

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?

Three compact sentences, front-loaded with the primary return content, followed by edge-case behavior and the parameter clarification. No wasted text, though the final scan_id sentence reads as a tacked-on footnote rather than integrated guidance.

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-value detail is not required in the description, and the empty-case plus collection-status notes cover the main ambiguity. For a single-param read tool this is essentially complete, with only sibling routing left implicit.

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 scan_id parameter, so the description carries the burden: it defines scan_id as the UUID of a ScanMalware scan, which is meaningfully more than the schema's bare 'Scan Id' title.

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: returns clipboard writes a page attempted during a scan, with event count and collection status. This is clearly distinguishable in intent from get_clipboard_stats (aggregate) and search_suspicious_clipboard (search), though the description does not explicitly name those 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 phrase 'while it was scanned' implies this is a per-scan lookup requiring a scan_id from a completed scan, and the empty-result case is addressed. However, there is no explicit statement of when to use this versus get_clipboard_stats or search_suspicious_clipboard, leaving routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds scope ('across the archive') and the metric categories returned, which is useful but modest; with an output schema present, return-format details are not needed. No auth or rate-limit context, hence a mid score.

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 verb, resource, scope, and enumerated outputs; no filler and nothing that needs to be moved earlier.

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 parameters, an output schema for the return shape, and annotations covering the safety profile, the description supplies what an agent needs to call it. Only the lack of sibling routing guidance keeps it from being fully 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond confirming the scope is the whole archive rather than a filtered subset.

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 ('Get clipboard and pastejacking statistics') and enumerates what the stats cover (event totals, detections, daily activity). This implicitly distinguishes it from the raw-event sibling get_clipboard_events, but it never names an alternative, so differentiation is left to inference.

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: an agent can infer this is the aggregate/summary counterpart to get_clipboard_events or search_suspicious_clipboard. There is no explicit when-to-use, when-not-to-use, or named alternative, leaving routing between the clipboard tools to guesswork.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that results carry a 'source' field and clarifies the scan_id provenance, which is useful but modest; no rate limits, pagination, or failure behavior are disclosed.

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?

Three short sentences, front-loaded with the resource definition followed by benefit and parameter note. Every sentence contributes; nothing is padded, though the benefit sentence is the weakest of the three.

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 read tool with an output schema present, the description covers purpose, output nature ('with their source'), and the required parameter. Return-format detail is rightly left to the output schema, so no critical gap remains.

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 carry the parameter, and it does: 'scan_id is the UUID of a ScanMalware scan' tells the agent the expected format (UUID) and where the value originates. That is meaningful added value beyond the bare schema for the single required parameter.

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 ('List') and a precise resource ('CPE identifiers in the NVD format derived from technologies detected on a scanned page, with their source'), and the mention of 'derived from technologies' scopes it well. It does not, however, explicitly differentiate itself from close siblings like search_cpe or get_technologies_by_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?

'Useful for matching against vulnerability data' implies a downstream use case but gives no explicit when-to-use, when-not-to-use, or named alternative. The agent can infer this is the per-scan CPE lookup versus the search-style search_cpe, but nothing states that.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is fully covered without the description. The description's added behavior is essentially a restatement of the metric list, which the output schema also covers, so it contributes only modest extra context.

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, zero filler, metrics front-loaded after the scope phrase. Nothing to trim.

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 no-argument aggregate with full annotation coverage and an output schema, the description is sufficient to call the tool correctly. The only missing piece is sibling routing, which is a usage gap rather than a completeness defect.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool 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?

Specific verb+resource ('Get CPE statistics across the archive') with the four metric families enumerated, so the agent knows exactly what comes back. It does not, however, distinguish itself from siblings like get_cpe_by_scan or search_cpe, which are the natural alternatives for CPE data.

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: as a zero-parameter aggregate it is obvious this is the summary view, but the description never says when to prefer it over get_cpe_by_scan (per-scan detail) or search_cpe (lookup). No exclusions or routing guidance 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered. The description corroborates the open-world nature by naming external CT logs, and mentions a 'found flag', but adds no rate limits, coverage caveats, or per-log behavior beyond that.

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 padding; the purpose appears in the first few words. The trailing 'with a found flag' clause is slightly awkward but not verbose.

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 tool with an output schema covering return values, little else is strictly required. Still, the description omits domain formatting guidance and any hint of CT log coverage or result volume, leaving a small but real 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?

Only one parameter ('domain') with 0% schema description coverage, so the description carries the full burden. It says the domain is the lookup target, but never specifies format (bare domain vs subdomain vs URL), which matters for a CT query. The parameter name is largely self-evident, so this lands at baseline adequacy.

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 ('Get the certificates issued for a domain') plus the data source (Certificate Transparency logs), which clearly separates it from CT siblings like get_ct_dns_records, get_ct_domains_by_ip and get_ct_timeline. It stops short of explicitly naming those alternatives, but the resource noun does the differentiating work.

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 reach for this tool versus the other CT tools, no prerequisites, and no exclusions. The agent must infer usage purely from the resource noun.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the shape of the returned data, but says nothing about pagination, result caps, rate limits, or whether lookup requires a live scan – with annotations carrying the safety burden, a 3 is appropriate.

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 sentences, front-loaded with what is listed and followed by the payoff of using it; no filler. Slightly over-brief given the unaddressed operational details.

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 is a read-only single-parameter listing operation. The description covers the essentials; only operational details like result limits and pagination are absent, which 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?

There is a single required 'domain' parameter with 0% schema description coverage. The description implicitly clarifies it by saying 'subdomains of a domain', but adds no syntax, format, or scope guidance (e.g., apex vs subdomain, wildcard handling) 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 gives a specific verb ('List') and resource ('subdomains of a domain found through Certificate Transparency'), plus the payload contents (DNS record type, IPs, TTL, seen dates). It is clear what the tool does, but it never names or distinguishes itself from close siblings like get_ct_certificates, get_ct_domains_by_ip, or get_ct_similar_domains.

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 closing sentence 'Useful for finding the other hosts of a domain' implies the use case, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative CT tool. The agent must infer the boundary against sibling tools on its own.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is fully covered. The description's only additional behavior disclosure is that results include 'record counts and the total', which is useful but thin; there is nothing about rate limits, result caps, or how much data an open-world lookup may return.

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 naming the output, sources, input, and result shape, with no filler. Nothing could be removed without losing 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 annotations cover the safety profile. What remains missing — routing guidance against sibling lookups and IP format expectations — is minor for a one-parameter read-only 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?

With schema description coverage at 0%, the description must carry the parameter burden, but it only restates that the input is an IP address — information already conveyed by the parameter name 'ip_address'. It adds no format detail (IPv4 vs IPv6), normalization rules, 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 gives a specific verb ('List'), resource ('domains'), the data sources used ('Certificate Transparency and DNS data'), and the key input ('an IP address'). This separates it reasonably well from get_ct_certificates and get_ct_dns_records, though it never names a sibling or explicitly contrasts its output with get_ct_similar_domains.

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 explicit when-to-use guidance and no mention of alternatives such as search_by_ip, get_ct_similar_domains, or get_ct_dns_records. Usage can only be inferred from the one-line scope statement, leaving the agent to guess which CT/DNS lookup to pick.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description's remaining contribution is the output shape (certificate count, similarity kind), which is largely duplicated by the existing output schema, and it says nothing about result caps, pagination, or refresh behavior of the CT data.

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 core purpose front-loaded and no filler. The trailing clause about certificate count and similarity kind is mild redundancy against the output schema, but it does not bloat the wording.

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 an output schema and full annotations, the description covers the essentials. However, CT similarity queries can return very large sets, and with no limit parameter and no stated cap or pagination behavior, an agent cannot predict result volume or truncation.

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 exists and schema coverage is 0% (title 'Domain' only). The description says 'similar to a domain', which confirms the input is the seed domain, but adds no format guidance (apex vs. subdomain, punycode, whether wildcards 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?

States a specific verb (find) and resource (domains similar by name) plus the data source (Certificate Transparency), which cleanly separates it from sibling CT tools such as get_ct_certificates, get_ct_dns_records, and get_ct_domains_by_ip. The parenthetical examples (lookalikes, typosquats) remove any ambiguity about the kind of 'similar' meant.

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 mention of lookalikes and typosquats implies the investigative use case (brand/typosquat hunting), but there is no explicit when-to-use or when-not-to-use statement and no named alternative among the many search_* siblings. Usage must be inferred.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety and idempotency profile is fully covered. The description adds the temporal-history scope but no extra behavioral context such as CT log latency, coverage of subdomains, or data freshness.

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 key resource first and the temporal detail after the colon. Slightly redundant, since 'certificate history' and 'when certificates were issued' restate the same idea, but overall efficient.

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 (one obvious parameter), an output schema exists so return values need not be explained, and annotations cover the safety profile. The description gives enough for correct invocation, though it omits any hint of the difference from get_ct_certificates.

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 must carry the meaning. It does implicitly convey that the input is a domain ('certificate history of a domain'), which matches the parameter name, but adds no format or scope detail (e.g., whether subdomains or URLs 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?

States a specific verb+resource ('Get the certificate history of a domain from Certificate Transparency') and adds a scope qualifier about issuance and change times. It is clear what the tool returns, though it never names the closest sibling get_ct_certificates to disambiguate the two.

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 emphasis on 'history', 'when issued' and 'when changed' suggests temporal/change-analysis use cases, but there is no explicit when-to-use statement, no exclusions, and no pointer to get_ct_certificates or get_ct_dns_records as alternatives.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that results are paginated, which is a modest addition; it says nothing about ordering, retention, or result size.

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 sentence with no wasted words, front-loading the resource and then the payload and pagination details.

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-value detail is not required, and the description covers the basic contract. However, with 0% schema coverage and several ambiguous sibling tools, it leaves an agent without the routing or parameter detail needed to call it confidently.

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 should carry parameter meaning. It merely names page and limit ('paginated with page and limit') and says nothing about the domain identifier format, valid ranges, maximum limit, or how page numbering works, leaving the undocumented parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the scan history of a domain') and names the payload contents (total count and scans). It is clear in isolation but never distinguishes itself from close siblings like get_domain_scans or get_domain_stats.

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 when-to-use guidance, no exclusions, and no mention of the near-identical siblings get_domain_scans/get_domain_stats. An agent must guess which history endpoint applies.

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?

Annotations already cover read-only, idempotent, open-world and non-destructive traits, so the description is free to add ordering ('newest first'), the limit cap, and the status filter. Most valuable is the caveat that a verdict on a final_url-only row belongs to the submitted host, not this domain – genuine interpretive context that annotations cannot convey.

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?

Three dense sentences with no filler; scope, ordering and filtering are front-loaded before the matched_on caveat. The second and third sentences are clause-heavy and slightly hard to parse on first read, which keeps it out of 5 territory.

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 an output schema present, return values need not be described, yet the description still explains the critical row-level 'matched_on' semantics. Combined with scope, ordering and filtering, an agent has enough to call it correctly; only the status value domain and sibling routing are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load. It adds meaning for 'limit' ('up to limit') and 'status' ('filters by scan status') and implies 'domain' matches subdomains, but it never enumerates valid status values or explains the default limit, leaving gaps.

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 with scope: 'List the recent scans of a domain and its subdomains, newest first, up to limit.' The domain-scoped framing implicitly separates it from global siblings like get_recent_scans, but no sibling is named explicitly, 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?

Usage is implied by the scope statement (use this to list recent scans for a given domain), but the description never says when to prefer this over get_domain_history, get_domain_stats, or search_scans, nor what prerequisites exist. The matched_on note is interpretation guidance rather than routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the aggregation windows (24h/7d/30d) and the count categories, which is useful scope context, but says nothing about cost, caching, or behavior for unknown 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 front-loaded sentence with no filler; the enumeration is long but each item is a distinct returned metric that 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?

An output schema exists, so the return format need not be explained, and the read-only annotations cover the safety story. The remaining gap is the unclear input format for 'domain', which is minor for a simple aggregation endpoint.

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 'domain' parameter, so the burden falls on the description, which only repeats the word 'domain'. It does not specify the expected format (bare hostname vs. URL vs. subdomain handling) or whether wildcards 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?

States a specific verb+resource ('Get scan counts for a domain') and enumerates the exact metrics returned, which separates it from list-oriented siblings like get_domain_scans and get_domain_history. It stops short of explicitly naming those alternatives, 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as get_domain_scans for the underlying scan list. The agent must infer from the sibling names 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact payload shape and the 'found is false when no favicon is stored' missing-data signal, which tells the agent how to interpret an empty result.

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 action and resource, then the return contents, then the empty-result caveat. Every clause earns its place with no padding, though a semicolon-heavy single sentence is slightly dense.

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 an output schema present, the description needn't document return values in full, yet it still enumerates them, and it covers the empty-result case explicitly. An agent has enough to invoke correctly; only alternative-tool routing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter is scan_id and the schema has 0% description coverage, so the schema itself says nothing. The description names the parameter and ties it to the scan scope, but adds no format, source, or validity details (e.g., where scan_id comes from, whether it must be an existing scan). Adequate but thin.

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 ('Get the favicon recorded for a scan_id') and enumerates the returned fields (size, MD5, SHA-256, base64 image), so the agent knows exactly what comes back. It does not explicitly distinguish itself from near-siblings like get_favicon_stats or search_by_favicon/search_favicon_mmh3, though 'recorded for a scan_id' implies per-scan retrieval.

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 guidance is given. The description never says to use this rather than get_favicon_stats (aggregates) or search_by_favicon / search_favicon_mmh3 (reverse lookup by hash), which are the obvious alternatives in this large sibling set. The scan-scoped nature is only implied by the parameter.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral information beyond them: the query is an aggregate that 'can take up to 90 seconds by default', warning the agent about latency and hinting the timeout is configurable.

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 waste. The scope and contents come first and the performance caveat is appended rather than buried, so the front-loaded information is what an agent needs to decide.

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, yet the description still summarizes them; the latency caveat covers the main operational risk for a no-arg aggregate tool. Nothing essential is missing, though it does not say whether results are cached or how a caller can extend the timeout.

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, which is the baseline-4 case; there is no parameter syntax to explain. The description spends its words on return content and timing instead, which is the right allocation.

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 ('Get favicon statistics across the archive') and enumerates exactly what the aggregate contains: totals, 24-hour counts, and most common hashes with sample URLs. This clearly separates it from per-item siblings like get_favicon and search_by_favicon / search_favicon_mmh3.

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?

Implied usage is legible ('stats' endpoint for archive-wide favicon aggregates), and the 90-second latency note is a real usage consideration. However, no alternative is named and no when/when-not condition is given, so an agent must infer the boundary against get_favicon and search_favicon_mmh3 on its own.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered structurally. The description adds only that the payload is a service status; it offers no extra behavioral context such as latency, failure modes, or degraded states.

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 with no filler, and the action ('Check whether ... is up') is front-loaded ahead of the return detail. 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 no-parameter health endpoint with a full output schema, the description supplies everything an agent needs to decide to call it. Only a note on typical failure behavior is missing, a minor gap given the schema documents 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 tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. There are no argument formats or defaults the description could usefully clarify.

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 ('Check whether the ScanMalware API is up') plus the return content ('service status'). It is unambiguous and clearly distinct from siblings like get_js_runtime_health, which concerns JS runtime health rather than API availability.

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 the natural use case (verify the API is reachable before or during scans), but the description never states when to call it, when not to, or which alternative to prefer. Usage is inferable but not 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?

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is done. The description adds genuine behavioral context beyond them: the result includes a severity breakdown and total count, and the tool legitimately returns empty when no rule fired, which pre-empts a false 'no data / error' interpretation.

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?

Three short sentences, zero filler, front-loaded with what is returned and followed by the edge case and parameter clarification. Nothing is repeated from the schema or annotations.

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-value detail is not required, and the description still covers scope, empty-result semantics and the identifier meaning. The only real gap is not pointing the agent at how to source a scan_id for this per-scan family.

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 is only typed as a string with the title 'Scan Id'. The description compensates partially by identifying it as the UUID of a ScanMalware scan, but it does not say where a scan_id comes from (e.g., search_scans/submit_scan) or what happens on an unknown id.

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 ('Get intrusion detection (IDS) alerts') and narrows scope to one scan, distinguishing it from sibling per-scan getters like get_yara_by_scan and get_malware_by_scan. It also states the payload ('severity breakdown and total count'), so an agent knows exactly what it returns.

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 the usage context (alerts are scoped to a single ScanMalware scan) and notes the empty case, but it never says when to prefer this over neighbors such as get_yara_matches or get_scan_ioc, nor how to obtain a scan_id from other tools. Usage is inferable but not stated.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only that results are 'paginated' and scoped to 'the archive'; it says nothing about rate limits, aggregation window, or behavior on unknown IPs.

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 verb-resource and returned data front-loaded; every clause earns its place and nothing is 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?

With an output schema present, the description need not explain return shapes, and it does cover data scope and pagination. The remaining gap is input semantics for ip_address and the paging parameters, which no structured field fills.

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% across three parameters (ip_address, page, limit), so the description must compensate and largely does not. The single word 'paginated' hints at page/limit but gives no defaults or semantics, and the accepted IP format (IPv4/IPv6/CIDR) is never stated.

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 ('Get statistics for an IP address across the archive') and enumerates the exact aggregates returned (scans, unique URLs, first/last seen, geolocation, ASN/org, BGP, DNS), which functionally separates it from siblings like search_by_ip or get_rdap. It never names an alternative, so the differentiation is implicit rather than explicit.

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: an agent can infer 'use this to summarize an IP', but there is no statement of when to prefer it over search_by_ip, get_ct_domains_by_ip, or get_rdap, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds that each result carries a known-signature match flag and that shared JARM is weak evidence, but it says nothing about result volume, pagination, or error behavior on an invalid scan_id.

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?

Three short sentences, front-loaded with what is returned before the interpretive caveat and the parameter note. No sentence is wasted, though the caveat could be tighter.

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 an output schema present the return shape needn't be described, and the one parameter is defined. Safety is covered by annotations. The definition is nearly sufficient for correct invocation, with only the sibling boundary (search_by_jarm) left implicit.

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 single parameter has 0% schema description coverage, so the description must carry the load. 'scan_id is the UUID of a ScanMalware scan' supplies both the format (UUID) and the referent (ScanMalware scan), adequately compensating for the 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?

The description names a specific verb and resource ('Get the JARM TLS server fingerprints') and scopes it to 'the hosts in one scan', which meaningfully distinguishes this per-scan retrieval from the sibling search_by_jarm pivot. It stops short of naming that sibling explicitly, so an agent must infer the boundary.

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?

It offers an analytic caveat ('a weak pivot on its own'), which implies how much weight to give the result, but never states when to call this tool versus search_by_jarm, get_jarm_stats, or get_tls_details. Usage is implied rather than directed.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds a useful interpretive note (common signatures usually belong to large hosting platforms) but no context about aggregation window, freshness, or scope limits.

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 core action and followed by one sentence of genuinely additive interpretation. No filler or repetition of the title.

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 an output schema present, return values need no explanation, and a parameterless aggregate tool is described adequately. The only residual gap is the boundary against the many sibling stats tools (notably get_jarm_signatures), which is left to inference.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool is 4. The schema fully covers the empty argument object.

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 (JARM statistics) plus scope ('across the archive'), and the mention of 'most common signatures' hints at an aggregate view distinct from the sibling get_jarm_signatures. It stops short of explicitly contrasting with that sibling, so an agent still has to infer the split.

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 word 'statistics' – aggregated counts rather than per-signature records. Neither get_jarm_signatures nor search_by_jarm is named as an alternative, and no condition for choosing this tool over them is 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?

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the safety burden is lifted. The description adds genuine context beyond that: it enumerates the returned content (script URL, scan, hashes, metrics, ML vector) and discloses that functions and HTTP headers are opt-in rather than default.

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 sentence with the lookup key front-loaded, then the return payload, then the opt-in flags. No filler, no repetition of the title.

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 no further explanation, and the description still summarizes them helpfully. Annotations cover the safety profile. The only omission is behavior on a nonexistent id, which is minor for a read-by-id tool.

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 carry the load, and it largely does: it identifies fingerprint_id as numeric and explains that include_functions and include_http_headers 'add more detail'. It stops short of stating the null/false default behavior explicitly, so it is not fully 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 (get), a specific resource (one JavaScript fingerprint record), and the lookup key (numeric fingerprint_id). This distinguishes it from get_js_fingerprints (list) and the many search_js_fingerprint_* siblings without requiring schema inspection.

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 'by its numeric fingerprint_id' — the agent knows it needs an id in hand. However, it names no alternatives or exclusions (e.g., get_jsfingerprint_source, get_jsfingerprint_similar, get_jsfingerprint_bundle_stats) that an agent might otherwise confuse for detail retrieval on the same fingerprint.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds useful content about what the statistics include, but says nothing about behavior when dates are omitted (both default to null), the time basis of the archive, or result ordering.

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 sentence that front-loads the verb and resource and then lists the returned dimensions. No filler, no redundancy with the title.

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 annotations cover the safety profile. The remaining gap is parameter behavior: the two date filters are undocumented in both schema and description, which is a meaningful omission for a date-scoped stats tool.

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 refers to 'a date range', implying from_date/to_date, but gives no expected format, no note that both default to null, and no clarification of what an unbounded range means. The agent is left to guess the date syntax.

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 ('Get statistics') on a specific resource ('bundled JavaScript across the archive') and enumerates the measurements returned (share of bundled files, breakdown by bundler and module format). This is clearly distinguishable from siblings like get_jsfingerprint_library_stats or search_js_fingerprint_by_bundler, which cover different slices of the same corpus.

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 the aggregation use case ('across the archive for a date range'), so an agent can infer this is for aggregate reporting rather than per-record lookup. However, it names no alternatives such as search_jsfingerprint_by_bundler when the agent actually wants individual fingerprints, and gives no explicit 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful analytic framing about what the prevalence numbers mean, but says nothing about volume, cost, or output shape beyond what annotations and the output schema provide.

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, no waste: the analytical value is front-loaded and the parameter note is compact. 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 single-parameter, read-only tool with an output schema, the description covers what the tool produces and the meaning of the input. Return values need not be explained since an output schema exists; only explicit routing to alternatives is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden, and it does clarify that scan_id is the UUID of a ScanMalware scan. That is meaningful type/format information absent from the schema, though it stops short of format examples or failure behavior for invalid 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 and resource: for each script in one scan, report hash prevalence across the archive, plus the interpretive purpose (distinguishing common libraries from rare page-specific code). This is clear and distinguishable from stats-style siblings like get_jsfingerprint_library_stats, though 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?

Scope is implied by 'in one scan' and the scan_id requirement, so an agent knows the input context. However, there is no explicit when-to-use versus alternatives (e.g., get_jsfingerprint_library_stats or get_jsfingerprint_bundle_stats) and no exclusions or prerequisites stated.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that results are aggregated over the archive, with no note on caching, rate limits, or how empty date ranges behave.

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 wastes no words and puts the scope ('across the archive for a date range') before the enumerated outputs.

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 described, and the description is adequate for a read-only aggregate. However, with three undocumented parameters and zero usage routing, an agent gets little help on how to call it correctly versus its many siblings.

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 there are three parameters. The phrase 'date range' loosely maps to from_date/to_date, but neither the accepted date format nor the semantics/default behavior of min_count is explained anywhere, so the description fails to 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 (get), resource (JavaScript library detection statistics) and even enumerates the headline outputs: total fingerprints, detection rate, most common libraries. It is distinguishable from siblings like get_js_library_inventory or get_jsfingerprint_hash_prevalence, though it never names an alternative to sharpen the boundary.

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 only contextual cue is 'for a date range'; there is no statement of when this aggregate stats tool should be chosen over the many other JS-fingerprint siblings (bundle stats, hash prevalence, library inventory) and no prerequisites or exclusions.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and an output schema documents the return shape, so the description's enumeration of hashes and size metrics is partly redundant. The one genuinely additive piece is explaining that the include_* flags extend the result with function lists, headers, or ML vectors. No auth, rate-limit, or pagination behavior is disclosed.

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?

Three front-loaded sentences: purpose and return contents first, flag behavior second, usage hint third. No filler, though the detailed hash enumeration in sentence one is longer than strictly needed given the output schema.

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 four-parameter read-only tool with a full output schema and strong annotations, the description supplies enough to call it correctly: what comes back, what each flag adds, and what scan_id is. The remaining gap is pagination/result-size behavior and explicit routing away from the many search_js_fingerprint_* siblings.

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 carries the full burden, and it does map all three include_* options to concrete content (function lists, HTTP headers, ML vector details) while identifying scan_id as a ScanMalware scan UUID. It does not state that the flags default to null/off, so it compensates well but not completely for the coverage 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 (List) and resource (JavaScript files loaded by a scanned page) and enumerates the fingerprint components returned. It implicitly separates itself from the search_js_fingerprint_by_* siblings by being keyed on a scan, but never names a sibling to make the distinction explicit.

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?

"Useful for collecting script hashes to search for elsewhere" gestures at the follow-up workflow (the search_by_hash/search_jsfingerprint_* family) but stops short of naming an alternative or stating when to prefer this over get_jsfingerprint or search_js_fingerprint_by_sha256. Usage is implied rather than directed.

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?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds value beyond that by specifying the threshold's valid range (0 to 1) and explaining the non-obvious semantics of exclude_same_scan (drops matches from the same scan), which an agent could not infer from the parameter name alone.

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?

Three compact sentences, front-loaded with the action and resource before the parameter notes, with no filler. Sentence two restates what the parameter name already implies, a minor redundancy, but overall the density is high.

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 described, and the description covers every input parameter plus the primary use case. What remains missing is disambiguation from the hash-based sibling and any statement about what 'similar' is measured on, which matters in a family of near-identical tools.

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 carries the full burden, and it does explain all five parameters: fingerprint_id as the anchor, threshold with its 0-1 range, limit/offset as pagination, and exclude_same_scan's effect. It omits the limit/offset defaults and any hint about score semantics, so it is strong but not exhaustive.

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 ('Find JavaScript files whose fingerprint is similar to the one with this fingerprint_id') plus the core scoping mechanism (threshold, pagination, same-scan exclusion), so the operation is unambiguous. It does not, however, distinguish itself from the very similarly named sibling find_js_fingerprint_similar_by_hash, leaving the agent to infer which entry point applies.

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?

'Useful for finding variants of one script' gives a concrete intent, which is more than nothing. But there is no when-not guidance and no pointer to the nearest alternative (find_js_fingerprint_similar_by_hash, search_js_runtime_similar), so the choice among near-duplicate siblings is left 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the query can take up to 90 seconds by default, which is exactly the kind of latency caveat an agent needs for timeout planning.

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 tight sentences, front-loaded with the core action and result shape; the enumeration of similarity models is informative rather than filler. The trailing latency sentence could arguably be merged but it 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?

An output schema exists, so return-value structure need not be restated. For a read-only counting query the description covers purpose, model breakdown and latency; only the threshold parameter's meaning is missing, which is a small but real gap given 0% schema coverage.

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 carries the full burden for three parameters. It explains max_count as a cap and identifies fingerprint_id as the reference file, but the threshold parameter is never mentioned in either the schema or the description, leaving one of three parameters semantically opaque.

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: counting archived JS files similar to the file identified by fingerprint_id, broken out per similarity model. The counting (vs. listing) framing implicitly separates it from get_jsfingerprint_similar, but it never names that sibling, so the differentiation is left to inference.

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 when-to-use / when-not-to-use guidance and no alternative named. An agent must infer that this cheap count should precede pulling the full similar-file list, and nothing states prerequisites (e.g. that fingerprint_id must come from get_jsfingerprint first).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety and repeatability are covered. The description adds one genuinely useful behavioral signal beyond that: 'Source can be long', warning the agent about potentially large payloads. It adds nothing further about auth, rate limits, or truncation 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?

Two tight sentences, front-loaded with the action and key parameter, followed by a short, useful caveat about output size. No filler or redundancy.

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 the description need not enumerate return values, and the safety profile is fully covered by annotations. For a single-parameter read tool it is nearly complete; the only gap is guidance on obtaining a valid fingerprint_id and how to handle the 'long source' case (e.g., truncation or paging).

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 carries the burden for the single parameter. It clarifies that fingerprint_id is the numeric identifier of the JavaScript file and that retrieval is by that id, which is slightly more than the bare 'Fingerprint Id' title in the schema, but it does not explain valid ranges, how ids are sourced, or error behavior for unknown 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 and resource: retrieve the stored source code of one JavaScript file, keyed by fingerprint_id, and previews the returned fields (SHA-256, URL, length). It is clearly distinguishable from list/search tools in the get_jsfingerprint_* family. It does not explicitly contrast itself with the sibling get_jsfingerprint, which likely returns metadata rather than source, so it falls short of full sibling 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?

The description implies the caller must already hold a fingerprint_id but never says when to prefer this tool over get_jsfingerprint, get_jsfingerprint_similar, or the many search_js_fingerprint_* tools, nor how to obtain a valid id. No when-to-use or when-not conditions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description's added value is modest: the return shape ('libraries and versions ... how many scans used each') is largely duplicated by the output schema, and 'min_count drops rare versions' is really parameter semantics. No pagination, caching, or auth details are added.

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?

Front-loads the core purpose, which is good, but crams three distinct ideas (inventory contents, two filter behaviors, identifier format) into a semicolon chain followed by a second sentence. Each idea is useful, yet the sentence would read better split into purpose, filters, and format.

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-optional-parameter aggregate query with an output schema and full safety annotations, the description covers what is returned, how the filters work, and how to format the free-text identifier. The only meaningful gap is disambiguation from the similar library-stats and library-search siblings.

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?

With 0% schema description coverage, the description carries the burden well: it explains that 'library' filters down to one library and that 'min_count' drops rare versions. Crucially it also pins the identifier format ('lowercase names such as react, jquery or nextjs'), which is the most likely source of misuse for the free-text parameter.

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 ('List the JavaScript libraries and versions detected across the archive') plus the aggregate it returns ('how many scans used each'). It does not, however, distinguish itself from near-twin siblings such as get_jsfingerprint_library_stats or search_js_fingerprint_by_library, so an agent cannot disambiguate on this text 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?

No when-to-use, when-not-to-use, or alternative is given. The sentence about 'library' and 'min_count' behavior describes parameter effects rather than guidance, and nothing tells the agent why to pick this over the many JS-fingerprint sibling 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds value by disclosing that include_detailed_events toggles inclusion of individual events. It says nothing about permissions, rate limits, or behavior on a missing/unknown scan_id.

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?

Front-loaded with the fetch purpose, then parameter semantics; three tight sentences with no filler. The return-field enumeration is somewhat dense but is the tool's key differentiator.

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-value explanation is not strictly required, yet the description summarizes it anyway. Combined with annotations and the parameter notes, an agent has what it needs to invoke the tool, and only the sibling differentiation is underdeveloped.

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 carry the burden, and it does: scan_id is documented as the UUID of a ScanMalware scan, and include_detailed_events is explained as adding the individual events. It omits any type/default detail for include_detailed_events, but both parameters are meaningfully covered.

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 and enumerates the returned fields (overall risk, risk scores, script count, eval/Function calls, high-risk events, behavioural signature, composite hash). Very clear about what it fetches. It does not, however, distinguish itself from close siblings like get_js_runtime_coverage, get_js_runtime_health, or get_js_runtime_stats.

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?

Adds useful context that scan_id is the UUID of a ScanMalware scan, which implies usage after a scan. But there is no explicit when-to-use vs. alternatives or exclusion criteria, so the agent must infer from the name which of the several get_js_runtime_* tools to pick.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only that the result is service-wide rather than scan-scoped; it says nothing about aggregation window, caching, or rate limits.

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 with the returned metrics front-loaded and the scope qualifier last. No filler or redundancy.

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 spelled out, and a zero-param aggregate tool needs little else. The only residual gap is that the description does not disambiguate this tool from the several similarly named runtime/stats siblings.

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 there is nothing for the description to disambiguate; baseline 4 applies. The description invents no spurious inputs and correctly presents the tool as parameterless.

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 ('get ... runtime JavaScript fingerprints') and names the concrete outputs (coverage percentage, unique composite hashes, signatures). The closing clause distinguishes it from per-scan tools, but it does not separate itself from close siblings like get_js_runtime_stats or get_js_runtime_health.

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?

'Describes the service, not a scan' implies the aggregate scope, which is useful routing context against per-scan siblings. However, there is no explicit guidance on when to choose this over get_js_runtime_stats or get_js_runtime_behaviour, which have overlapping names.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only that a version is returned, which is largely restated by the existing output schema, leaving little extra behavioral context.

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 purpose front-loaded and no filler. Every word carries information and no sentence is 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 parameterless health check with an output schema and full annotation coverage, the description is sufficient to invoke it correctly. It could note failure/timeout semantics for an unreachable service, but that 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?

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a 0-param tool is 4. Nothing in the description conflicts with the empty 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?

States a specific verb and resource: verify the runtime JavaScript analysis service is up and report its version. This clearly distinguishes it from data-oriented siblings such as get_js_runtime_stats or get_js_runtime_behaviour, though it does not explicitly contrast itself with the broader get_health 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?

The description gives no when-to-use guidance, prerequisites, or alternatives. With a sibling like get_health in the list, an agent is left to infer whether this health check is scoped to the JS runtime subsystem or overlaps with the general endpoint.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered structurally. The description adds useful scope context ('platform-wide') and names the aggregated metrics, but says nothing about data freshness, time window defaults, or aggregation lag, which matter for a stats endpoint. An output schema exists, so the omission of return shape is acceptable.

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 core action and scope statement come first, and the disambiguating clause is placed exactly where it is needed.

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 parameterless aggregate-stats tool with a rich annotation set and an output schema, the description carries enough to select and call it correctly. The only modest gap is the absence of any note on aggregation window or freshness.

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 the baseline applies and there is no parameter meaning for the description to supply. Nothing in the description misrepresents the (empty) input surface.

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 ('Get platform-wide statistics for runtime JavaScript analysis') and then enumerates the concrete metric families returned (risk distribution, eval call averages/totals, high-risk events). The closing clause 'Describes the service, not a scan' cleanly separates it from scan-scoped siblings like get_js_runtime_behaviour and get_js_runtime_coverage.

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 'Describes the service, not a scan' gives explicit scoping guidance and rules out the per-scan interpretation, which is the main ambiguity for this family of tools. It does not name a specific alternative tool to use instead for scan-level data, so it stops short of a full when/when-not/alternative treatment.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds pagination behavior (limit/offset) and the filtering behavior of script_url, but says nothing about auth needs, rate limits, or typical result sizes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core verb and resource, then the filtering and parameter notes. Dense but nearly every clause carries information; loses a point only because the second sentence reads as a compressed parameter dump.

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 re-explained, and the description covers scope, filtering, pagination and the scan_id meaning. The main gap is sibling disambiguation, which for a compact read-only list tool is a minor omission rather than a blocker.

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 carries the burden, and it addresses all four parameters: scan_id ('UUID of a ScanMalware scan'), script_url ('narrows to one file'), and limit/offset (pagination). It lacks concrete format/default detail for limit and offset, but meaningfully compensates for the empty 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?

It states a specific verb and resource ('List the code segments ... extracted from one scan's JavaScript') and scopes the result to a single scan, which implicitly contrasts with hash-based siblings like search_js_segments_by_hash. It does not explicitly name any sibling to route the agent though, 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?

Usage is only implied by the scope ('one scan's JavaScript') and by the note that script_url narrows to one file. There is no explicit when-to-use vs when-not, and no named alternative such as get_js_segments_suspicious or search_js_segments_by_hash, leaving the agent to infer the 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld behavior, so the safety profile is fully covered. The description adds pagination and the return field set (location, snippet, risk details), but those repeat what the schema and output schema already provide, and it does not disclose ordering, default limit, or what 'suspicious' means beyond the threshold.

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 that front-loads the resource and scope, then tacks on the pagination and the scan_id clarification. No filler, though the semicolon-joined clauses pack several ideas together.

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 rich annotations and an output schema, the description only needs to cover selection scope and filtering, which it does reasonably well. The main residual gap is the interplay between 'suspicious' scoring and min_risk_score, plus result ordering, but nothing essential for calling the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden and does address all four parameters at least nominally: scan_id is defined as a ScanMalware scan UUID, min_risk_score as a floor, and limit/offset as pagination. However it gives no scale or range for min_risk_score, no default/limit semantics, and no format beyond 'UUID' for scan_id, 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 gives a specific verb (List) and resource (JavaScript code segments from one scan) and narrows scope with the 'scored as suspicious' filter, which implicitly separates it from siblings like get_js_segments_by_scan and get_js_segments_unknown. It stops short of naming those alternatives, so an agent must infer the routing from content 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 implied rather than stated: 'scored as suspicious, above min_risk_score' signals this is the filtered/threat-focused variant, but there is no explicit when-to-use, when-not-to-use, or 'use X instead' guidance. The alternative segment tools are never 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds pagination behavior and the meaning of the returned segments, but discloses no additional operational traits such as result limits, ordering, or cost. Modest added value over the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with zero filler; the core filter and scope are front-loaded, followed by pagination and the scan_id format. 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?

With an output schema present, return values need no explanation, and the description covers scope, filtering, and all parameters. It is nearly complete, only lacking explicit routing versus the sibling segment tools.

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 carries the full burden, and it does explain all four parameters: scan_id is a ScanMalware UUID, min_code_length is a lower bound, and limit/offset drive pagination. It compensates well, though it omits default behavior (e.g., what happens when limit is null).

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 (List) and resource (JavaScript code segments) scoped to one scan, with the defining filter 'match no known library'. This clearly distinguishes it from siblings like get_js_segments_by_scan and get_js_segments_suspicious without opening any schema.

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 useful interpretation of the results ('usually the page's own or a kit's code'), which implies when this tool is interesting, but it never states when to prefer it over the sibling segment tools or any prerequisites. Usage is implied rather than guided.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds useful content scope (what the counts represent) but nothing about freshness, caching, or whether the numbers are live versus periodically refreshed.

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 verb and the three enumerated payload fields; no filler, no repetition of the title.

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 an output schema present, the description need not explain return values, and annotations carry the safety profile; the enumerated fields are enough to know what this returns. The only shortfall is the missing pointer to get_capabilities_by_date for non-current data.

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 the baseline is 4 and there is nothing for the description to clarify. It correctly avoids inventing parameter details that do not exist.

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 (get the current size of detection content) and enumerates what the count covers: indicators, malware rules, ClamAV signatures. The word 'current' implicitly contrasts with the dated sibling, but the description never names get_capabilities_by_date, so sibling differentiation is left to inference.

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 statement, no exclusions, and no mention of the obvious alternative get_capabilities_by_date for historical snapshots. The only signal is the adjective 'current', which is too thin to count as real routing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only the empty-result behavior, which is useful but modest additional context; no auth, rate-limit or pagination 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?

Three short sentences, front-loaded with what is returned, then the empty case, then the parameter. Nothing is wasted and nothing 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?

An output schema exists, so return values need no further explanation, and the annotation set covers the operational profile. The only shortfall is the absence of routing guidance among the many related read/stat siblings.

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 carry the burden, and it does clarify that scan_id is a UUID belonging to a ScanMalware scan. That disambiguates it from the many other scan-identifier params in this family, though no format example or lookup source is given.

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+resource: 'Get the malware detections for files the scanned page delivered', with an explicit enumeration of returned fields (threat names, detection counts, source). This is clearly distinguishable from data-shape siblings like get_malware_stats, though no alternative is named 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?

'scan_id is the UUID of a ScanMalware scan' implicitly tells the agent this is a post-scan lookup keyed to a specific scan, and the empty-result note sets expectations. But there is no explicit when-to-use guidance versus get_yara_by_scan, get_recent_threats, or get_malware_stats.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description's added value is limited to enumerating the reported statistics, which overlaps with the existing output schema and discloses no behavioral traits (refresh cadence, data window semantics, aggregation scope) beyond that.

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 resource and its returned statistics are stated immediately. Every clause 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?

For a zero-parameter, read-only stats tool with a full output schema and safety annotations already in place, the description covers everything an agent needs to select and invoke it. Return values need not be explained further since the output schema exists.

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 there is no parameter semantics to convey; the schema is complete by definition. Baseline 4 applies for a no-arg tool.

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+resource ("Get malware detection statistics") and enumerates the exact contents (overall and last-24-hour counts, top threats, hourly trend), which lets an agent distinguish this aggregate view from per-scan siblings like get_malware_by_scan. It never explicitly names an alternative, but the phrase "across the archive" establishes global scope versus scoped 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?

Usage is only implied: "across the archive" signals this is the global/aggregate view, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_malware_by_scan, get_recent_threats). An agent can infer the intent but receives no routing 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?

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real value by disclosing that the log content is deliberately excluded and why (tens of megabytes gzipped), which prevents the agent from expecting payload data.

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 tight sentences, front-loaded with the core action and concluding with the key constraint. No filler or redundancy.

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 fields need not be spelled out. The description still covers the essential semantics for this simple 1-param read tool, and the only mild gap is the absence of any note on error/empty cases.

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 one required parameter, but the description only references 'scan_id' in passing without adding format or sourcing detail. The single param is trivially understood from its name, so this is adequate but not compensating for the coverage 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 (describe) and resource (Chrome NetLog network log) scoped to a scan_id, and enumerates exactly what is reported: existence, size, and encoding. No sibling tool covers network logs, so the agent can distinguish it immediately.

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 the use case (fetch metadata rather than the log itself) but never states when to choose this over alternatives or any prerequisites. Usage is inferable from 'the log itself is not returned' but not explicitly guided.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and side-effect profile is covered by structured data. The description adds value by disclosing the shape of the result (confidence, counts, suspicious flags) but says nothing about cost, pagination, or behavior for scans with no OCR results.

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, no filler: the first front-loads what is returned, the second gives the use case and parameter definition. Every sentence carries information an agent needs to select or call the tool.

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 enumerating return fields is technically redundant, yet it helps selection against the many sibling get_* tools. Between the annotations, the output schema and the parameter definition, the description covers enough for correct invocation; only edge-case behavior is unaddressed.

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 parameter, so the schema offers nothing; the description compensates by defining scan_id as the UUID of a ScanMalware scan, which tells the agent both the format and how to obtain a valid value. It stops short of stating what happens for an unknown or non-OCR scan.

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 (get) plus resource (OCR text for a given scan) and it enumerates the returned substance: language, confidence, word and character counts, suspicious regions. This clearly separates it from aggregate siblings like get_ocr_stats and search-oriented siblings like search_ocr or search_ocr_pattern.

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 clause 'Useful when page text is drawn as images' implies the triggering condition, but no explicit when-not guidance is given and no sibling alternative (e.g. get_ocr_stats for aggregates, search_ocr for cross-scan queries) is named. Usage is inferable rather than stated.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds what is aggregated and which metrics are computed, which is modestly useful, but says nothing about scoping, caching, or coverage limits of the statistics.

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 well-formed sentence with the resource and metric list front-loaded and no filler. The metric enumeration is dense but each item earns its place by telling the agent what to expect.

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 zero parameters, full annotation coverage, and an output schema in place, the description only needs to frame the aggregation scope, which it does. Nothing essential for calling the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to clarify and the description correctly avoids inventing any.

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 ('Get OCR statistics across the archive') and enumerates the exact metrics returned: scans with OCR text, average confidence and length, language distribution and daily counts. It is clearly distinguishable from the per-scan sibling get_ocr_by_scan, though it never names 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?

The description gives no when-to-use guidance, prerequisites, or routing against neighbors like get_ocr_by_scan or search_ocr. The aggregate nature of the tool is only implied by the word 'statistics', leaving the agent to infer the context.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the scan-scoping constraint and the phishing rationale, but says nothing about behavior when a page declares no Open Graph tags or how results are keyed to a scan.

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?

Three tight sentences, front-loaded with what is returned, followed by why it matters and the parameter's meaning. No sentence is redundant and nothing 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The only residual gap is edge-case behavior (pages with no OG/Twitter metadata), which is minor for a read-only single-parameter 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?

Schema description coverage is 0%, so the description carries the burden for the single parameter and does so: 'scan_id is the UUID of a ScanMalware scan' supplies both format (UUID) and provenance (a prior scan). It stops short of saying whether the scan must be completed.

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 and resource (retrieve Open Graph and Twitter card metadata) and even enumerates the returned fields (title, description, image, site name). It is clearly distinguishable from siblings like get_ocr_by_scan or get_favicon, though it never explicitly names a sibling to contrast against.

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?

'Phishing pages often copy a brand's metadata' implies the investigative context in which this tool is valuable, which is useful framing. However, there is no explicit when-to-use vs. when-not guidance and no reference to alternative tools for page-content analysis.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds some content context (the result carries a detected flag and a note) but says nothing about volume, pagination, or auth beyond the annotations; the return-shape detail is also partly redundant with the existing output schema.

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?

Three short sentences, front-loaded with the purpose before the parameter note. The middle clause explaining pastejacking costs a few words but earns them by making an obscure term self-explanatory.

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 an output schema present, return values need not be described, and the description covers purpose, the technique's meaning, and the key input's origin. It is only slightly thin on sibling differentiation and on what an empty/negative result looks like.

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 parameter, so the description must carry it — and it does partially, specifying scan_id is a UUID and that it belongs to a ScanMalware scan, which disambiguates it from other scan identifiers in this large toolset. Format/lookup-failure behavior is still unstated.

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 (get) and resource (pastejacking findings) scoped to one scan, and defines the phenomenon so the agent knows what data this returns. It is clearly distinguishable from clipboard-adjacent siblings like get_clipboard_events and search_suspicious_clipboard without opening any schema.

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?

Implies usage is a per-scan lookup ("for one scan") and names the required scan_id, but never says when to prefer this over get_clipboard_events, get_malware_by_scan, or search_suspicious_clipboard, nor any when-not condition. Adequate but leaves routing 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the capture payload is deliberately withheld, and the response is limited to existence/size/compression/content-type metadata, which prevents an agent from expecting binary data.

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, zero filler, and the most decision-relevant fact (what is described, and that the capture is not returned) is front-loaded before the parameter note.

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, read-only metadata tool with annotations covering the safety profile and an output schema covering the return shape, nothing an agent needs to call it correctly is missing. The parameter is resolved and the non-return of the capture is disclosed.

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 carry the burden, and it does: it identifies scan_id as a UUID tied to a ScanMalware scan, which the schema (a bare string titled 'Scan Id') does not convey. It stops short of ID syntax details or failure behavior for unknown scans.

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 ('Describe') and resource (the PCAP recorded during one scan), then enumerates exactly what is returned: existence, size, compression, content type. 'The capture itself is not returned' cleanly separates this metadata reader from any tool that would fetch the artifact.

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?

Scope is clear from context ('recorded during one scan', 'scan_id is the UUID of a ScanMalware scan'), which implies when it is applicable. However, it never states when to reach for this versus related scan-scoped readers such as get_netlog or get_scan_result, and offers no exclusions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the 24-hour window and the three metrics returned, which is useful scoping context, but says nothing about refresh cadence, staleness, or whether the window is fixed.

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 sentence that front-loads the resource and lists the three returned metrics with no filler. 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?

With an output schema present, the description need not explain return shapes, and with zero parameters there is no input documentation burden. The only gap is the undefined 'by visibility' grouping and the absence of any routing guidance among the many stats siblings, which keeps it short of a 5.

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 and schema coverage is 100%, so there is nothing for the description to document. Baseline 4 applies; no parameter-level gaps exist.

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 resource (platform stats) and enumerates exactly what is returned: scan queue length, running scans, and scans completed in the last 24 hours. It is distinguishable from the many sibling *_stats tools by the 'platform' scope, though the qualifier 'by visibility' is left undefined, so an agent cannot tell what grouping dimension it will receive.

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 tool versus the dozens of sibling stats endpoints (get_analyzer_stats, get_domain_stats, get_js_runtime_stats, etc.), nor any prerequisite or exclusion. The agent must infer usage purely from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that results are paginated; it does not explain what happens when 'days' is null (the default), the ordering, or how the result set is bounded.

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, scope stated before the pagination note. It is efficient, though its brevity contributes to the under-specification noted elsewhere rather than being a virtue on its own.

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 no explanation. However, with 0% schema description coverage and a nullable default 'days', the description leaves a real gap around what time window is actually queried by default — the single most important thing an agent needs to call this 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 description coverage is 0%, so the description must carry the load for all three parameters. It vaguely gestures at 'days' and '(paginated)' but never states the semantics of a null 'days', the meaning of 'page', or the maximum/default of 'limit' (defaults only appear as bare schema values).

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 ('List') plus a precise resource ('most frequently detected web technologies') and scope ('over the last days', paginated). This cleanly separates it from per-scan siblings like get_technologies_by_scan and get_technology_stats, though it never names 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?

No when-to-use statement, no exclusions, and no mention of the closely related search_technologies, get_technology_stats, or get_technology_combinations. An agent must infer from the phrase 'most frequently detected' that this is a global popularity ranking rather than a filtered search.

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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds what data is returned but does not disclose limitations such as rate limits, caching, auth needs, or behavior when RDAP data is unavailable.

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 three compact sentences with no wasted words: purpose and returned fields first, then the security rationale, then the parameter clarification. It is appropriately sized and front-loaded.

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 tool with an output schema and full annotations, the description covers the purpose, returned content, and the meaning of scan_id. It omits explicit guidance on when to prefer this tool over related domain-history or DNS tools, but otherwise provides enough to invoke it 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 description coverage is 0% for the single scan_id parameter, so the description must compensate. It does so by explaining that scan_id is the UUID of a ScanMalware scan, which clarifies the value's source and format beyond the bare schema type.

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 ('Get') and resource ('registration data (RDAP)') and enumerates the returned fields (registrar, registration/expiry dates, domain age, nameservers, status). It scopes the lookup to 'the scanned domain and its IP addresses,' which helps distinguish it from generic domain tools, but it does not explicitly name a sibling alternative to route against.

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 'A very young domain is a common phishing signal' implies the tool is useful for phishing assessment, giving some usage context. However, it does not state when to choose this over alternatives such as get_domain_history or get_domain_stats, nor does it provide any exclusions or prerequisites.

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