ContrastAPI

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses truncation behavior (first 50 prefixes by default), rate limits (30/hr free, 500/hr Pro), and output format. This adds significant 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?

Three sentences, each valuable: purpose, usage context, defaults/rate limits/output. No redundancy or fluff. Front-loaded with the core action.

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 schema coverage at 100%, clear output, and annotations, the description covers all necessary aspects: what, when, how, and side effects (rate limits, truncation). No gaps for an AI agent.

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?

Both parameters are described in the schema with full coverage. The description adds nuance about the include_full_prefixes parameter, explaining truncation and giving an example (Cloudflare AS13335). The counts are noted as honest pre-truncation totals.

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

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

The description clearly states it looks up ASN for a domain or IP, listing the output fields (AS number, organization, prefixes). This distinguishes it from sibling lookup tools like IP lookup or WHOIS lookup by specifying the exact resource and verb.

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 explicitly says 'Use to identify network operator and IP range ownership', providing a clear use case. It does not mention when not to use or alternatives, but the purpose is clear enough for an agent to decide.

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?

Description adds details beyond annotations: slim vs full response, 404 on missing id, return object structure, and rate limits, all of which aid agent behavior. No contradiction with 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?

Description is concise (6 sentences), well-structured with front-loaded purpose, and every sentence adds value. No 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?

Covers all necessary aspects: purpose, usage, parameters, behavior, errors, rate limits, and return structure. Output schema exists but description complements it effectively.

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

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

Schema coverage is 100%, so baseline is 3. Description adds useful context for the 'include' parameter (explains slim vs full) and mentions 'next_calls' hint, providing extra value beyond 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?

Description clearly states 'Look up a MITRE ATLAS case study' and distinguishes from sibling tools like atlas_case_study_search and atlas_technique_search by specifying when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises 'Use this after atlas_technique_search' and directs to bulk_atlas_technique_lookup for drilling into techniques_used, providing clear when-to-use and 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 and idempotentHint. Description adds context about default slim response and include='full' for verbose, plus rate limits. No contradictions.

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

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

Four sentences, all essential information. Purpose first, then usage guidance, rate limits, and return format. No verbose or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description outlines return structure ensuring agent knows what to expect. Includes query, total, results with fields, and next_calls pagination hint.

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

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

Schema description coverage is 100% with good descriptions. Description adds meaning by explaining default truncation and examples for keyword and technique_id, enriching beyond 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?

Clearly states 'Search ATLAS case studies by keyword or referenced technique', specifying verb, resource, and search criteria. Distinguishes from sibling tool atlas_case_study_lookup which is for full procedure drill-down.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Useful when the user has a technique in hand and wants to see incidents that exercised it' and directs to atlas_case_study_lookup for full details. Also mentions rate limits for free vs pro.

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=true, idempotentHint=true, destructiveHint=false, indicating safe lookup. The description adds further behavioral transparency by detailing rate limits (30/hr Free, 500/hr Pro), the return object structure, inherited tactics behavior, and the 404 error for missing IDs. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then efficiently adds contextual information about ATLAS coverage, relationships to ATT&CK/D3FEND, usage guidance, rate limits, and return format. Every sentence provides necessary detail without 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?

Given the tool's complexity (ATLAS techniques with sub-techniques, inheritance, and cross-references), the description thoroughly covers usage scenarios, relationships, error handling, rate limits, and return fields. The output schema exists (fields listed) and annotations are provided, making the description highly complete for agent decision-making.

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

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

The schema covers 100% of parameters (technique_id) with format description. The description adds value by providing concrete examples ('AML.T0051' for LLM Prompt Injection) and clarifying sub-technique format, which is helpful for the agent beyond the schema's generic description.

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

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

The description clearly states the tool looks up a MITRE ATLAS technique, defines ATLAS as the AI/ML adversarial attack catalog, and gives specific use cases (LLM red-teaming, adversarial ML). It distinguishes itself from sibling bulk_atlas_technique_lookup by specifying when to use each.

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 explicitly says when to use this tool (user asks about AI/ML threats) and when to prefer the bulk variant. It also mentions the 404 error case for missing IDs. However, it does not mention the sibling atlas_technique_search for searching techniques by name/description, which could be a useful alternative.

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

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

Annotations indicate read-only, idempotent. Description adds default slim response (240 char truncation), include='full' option, size warning for full catalog, and mentions next_calls for pagination. No contradictions.

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

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

Front-loaded with purpose, well-structured with each paragraph adding value. Slightly verbose but justified given complexity.

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?

Covers all aspects: purpose, parameters, default behavior, chaining, cross-referencing, rate limits, return shape. Output schema exists so return values not needed in description.

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?

All 6 parameters documented in schema (100% coverage). Description adds practical context: default values, format examples, size implications for include, and chaining purpose for exclude_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?

Clearly states it searches the MITRE ATLAS catalog by keyword, tactic, or maturity. Distinguishes from sibling tools like atlas_technique_lookup and atlas_case_study_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use (threat-model questions), how to chain with atlas_technique_lookup, and rate limits. Gives example query and explains exclude_id for sibling searches.

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 indicate read-only, idempotent, non-destructive behavior. The description adds details about TXT record filtering, total_txt_records, next_calls chaining, and cost. Slight deduction for not mentioning any error conditions or rate limiting beyond cost.

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 sentences efficiently pack purpose, usage, parameters, and side effects. Front-loaded with main action. No redundant or vague language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, when to use, parameters with details, cost, and chaining. It fully equips an agent to decide and invoke correctly.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds extra context for include_all_txt, explaining the default filter and when to use True, which enriches understanding 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 clearly states the tool's purpose: 'Perform comprehensive domain audit: combines domain_report + live HTTP security headers + technology fingerprinting.' It distinguishes itself from the sibling tool domain_report by noting passive-only vs active checks.

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?

Explicit usage guidance: 'Use when you need the full picture (recon + active checks); use domain_report for passive-only assessment.' Also provides chaining suggestions with subdomain_enum and ssl_check, and mentions cost limits.

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 description discloses many behavioral traits beyond annotations: respect for robots.txt, cache-control handling, rate limiting (60 req/min per eTLD+1), security warnings about _untrusted fields, error codes (502, 403), and output fields. No contradiction with annotations.

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

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

The description is detailed and well-structured, front-loading the purpose and then covering constraints, ethical considerations, and output. While slightly long, each sentence adds necessary information. Could potentially be shortened by omitting some output field details since output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (scraping, ethical checks, error handling, rate limits), the description is highly complete. It covers input, process, constraints, output fields (including cache_respected and summary), and error scenarios. Output schema exists, so return value details are optional but provided.

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

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

The single parameter 'domain' has a clear description in the schema. The description adds value by specifying format constraints (no scheme, path, port) and default behavior (fetches https://<domain>/ with HTTP fallback). Schema coverage is 100%, so no 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?

The description clearly states the tool scrapes a domain's homepage <head> for public brand assets, listing specific items like favicon, og:image, theme-color, og:site_name, and JSON-LD Organization.logo. It distinguishes from siblings by emphasizing homepage-only scope and no crawling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: enriching CRM records, building company-card UIs, or correlating a lead's site to visual identity. It also clarifies what it does NOT do (no crawling, homepage-only) and mentions ethical constraints, but does not directly compare to alternative 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?

Beyond annotations (readOnly, idempotent), the description provides concrete behavioral details: rate limits (30/hr free, 500/hr Pro), return shape including status and error fields, normalization, de-duplication, and per-item next calls. All without contradicting annotations.

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

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

The description is a single dense paragraph. It is concise but could benefit from bullet points or more structured formatting. It front-loads the main purpose effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (return structure described), the description covers input format, output shape, rate limits, error handling, and workflow context. It is complete for a bulk lookup 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 coverage is 100% (technique_ids described in schema). The description adds value by specifying format, case-insensitivity, de-duplication, and that each ID counts as a rate limit request, enhancing agent understanding.

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

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

The description clearly states the tool performs a bulk lookup of ATLAS techniques, distinguishing itself from the singular atlas_technique_lookup by handling up to 50 IDs per request. It uses specific verbs like 'retrieve' and 'bulk lookup'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is the natural follow-up to atlas_case_study_lookup and explains scenario, but does not explicitly state when not to use. It implies alternatives but lacks explicit 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 and idempotentHint=true. The description adds transparent details about default truncation (first 20 affected products, first 10 references), optional full lists, and the response shape including successful/failed/partial 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?

The description is front-loaded with the core purpose and limit, then logically expands on defaults and options. Every sentence adds value, though slightly verbose with 50+ words beyond the first 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?

Given 5 parameters, output schema, and complexity (truncation, chaining, rate limits), the description covers all essential behavioral and contextual aspects, including response format summary and tool interconnections.

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

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

Schema coverage is 100% but the description adds meaningful context beyond schema, such as explaining why defaults are set (e.g., payload-bound considerations), how include_reference_tags activates tag-first patch detection, and the impact of setting boolean flags.

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

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

The description clearly states the tool performs batch queries of up to 50 CVEs, distinguishes from the sibling cve_lookup for single CVEs, and specifies use cases like dependency audits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool (bulk enrichment) vs cve_lookup for single CVEs, provides chaining guidance to other tools (kev_detail, cwe_lookup, exploit_lookup), and specifies rate limits for Free and Pro tiers.

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. Description adds valuable behavioral details: partial failure visibility via verdict.sources_queried / sources_unavailable, auto-detection of indicator types, and per-type source coverage. Consistent with 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?

Description is well-structured with front-loaded key info (purpose, limits). Each sentence adds value: auto-detection, sources, partial failures, use cases, rate limits, return format. Slightly dense 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 complex batch tool with 1 parameter and existing output schema, description covers everything needed: input limits, auto-detection, source coverage, partial failures, rate limits, and return structure. Complete for use case.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds maximum limit of 50 and clarifies indicator types, but schema already mentions list of strings and auto-detection. No significant extra meaning beyond 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?

Description clearly states it's for batch querying multiple IOCs (up to 50) with auto-detection of type, and explicitly distinguishes from sibling ioc_lookup (single indicator). Specific verb 'Batch query' and resource 'IOCs' with clear scope.

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?

Explicit guidance: 'Use for SOC alert triage or batch enrichment; use ioc_lookup for single indicator.' Also mentions rate limits (Free: 30/hr, Pro: 500/hr) providing practical 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 indicate read-only, idempotent, non-destructive. Description adds critical behavioral details: per-item validation, error handling (invalid_format, not_found), partial failures via skipped_due_to_rate_limit, quota consumption per rule_id, and parity with bulk_cve/ioc.

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?

Description is detailed but front-loaded with purpose. Slight repetition of quota details, but each sentence adds value. Could be tightened slightly without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (bulk with partial errors, rate limits) and presence of output schema, description covers output shape, error handling, rate limits, and quota. Sufficient for correct agent usage.

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

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

Schema coverage 100% already describes rule_ids. Description augments with quota unit consumption and per-item status behavior for invalid/unknown UUIDs, adding significant context 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?

Description clearly states the tool performs bulk Sigma rule lookups for up to 50 UUIDs, distinguishing it from single sigma_rule_lookup. It specifies the number limit and result shape, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly designed for triage workflows with multiple known rule IDs (e.g., from SIEM alerts or detection bundles). Does not state when to avoid, but contrasts with single lookup calls, providing clear 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 true, and destructiveHint false. The description adds substantial behavioral details: the exact formula, multiplicative boosters, label bands, urgency encoding, and output structure. No contradictions with annotations.

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

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

The description is dense but extremely efficient, front-loading the main purpose and formula. Every sentence serves a clear purpose (formula, boosters, bands, usage guidance, limitations, credits). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a simple input (one CVE ID), the output is complex. The description fully explains the algorithm, all output fields, boosters, urgency, and even limitations relative to exploit_lookup. It is completely adequate for the tool's complexity.

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 cve_id, and the schema description already provides format and examples. The description does not add new meaning beyond the schema for this parameter, so baseline 3 is appropriate.

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

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

The description clearly states it computes a composite risk score (0-100) for a CVE by fusing CVSS, EPSS, KEV, and PoC. It explicitly distinguishes from sibling tools like cve_lookup and exploit_lookup, noting it avoids orchestrating separate lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use: 'Use to triage a single CVE without orchestrating cve_lookup + exploit_lookup separately.' It also provides alternative guidance: 'for full multi-source exploit detail, call exploit_lookup separately.' Rate limits are included.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by explaining the behavior of the 'fixed_in' field: omitted when version range is open-ended or no input version, with corresponding remediation copy. No contradictions with annotations.

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

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

The description is moderately lengthy but well-structured: purpose, usage hint, rate limits, return format, and special case for fixed_in. Every sentence adds value, though slightly verbose for a tool with one parameter.

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 1 parameter, 100% schema coverage, and an output schema existing, the description is complete. It covers the input format, output fields, special behavior of fixed_in, and rate limits. No gaps.

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

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

Schema has 100% coverage for the 'packages' parameter, but description adds meaning: explains the object structure (name required, version optional, max lengths), extra fields ignored, and provides an example. This goes beyond the schema's minimal description.

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

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

The description clearly states the tool audits project dependencies against a CVE database to find known vulnerabilities. It specifies package managers (npm/PyPI/Maven/RubyGems/etc.) and distinguishes from sibling cve_lookup by its use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use for dependency security scanning; use cve_lookup for single CVE.' Also provides rate limit details per tier (Free: 30/hr, Pro: 500/hr), giving clear usage 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds key behaviors: no external requests, truncation to 500 chars by default with option for full values, and return structure {total, by_severity, findings}. No contradiction with 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?

Very concise; three sentences covering purpose, alternatives, rate limits, truncation behavior, and return format. No fluff, front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter validation tool, the description is fully complete. It covers all necessary information: what it does, when to use it, behavioral quirks (truncation, no external requests), and output shape. Output schema is implied by the return description.

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 covers both parameters with descriptions (100% coverage). The description adds value by noting the default truncation to 500 chars and that passing 'full' restores full raw value, which goes beyond the schema's description of the include 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 clearly states the tool validates HTTP security headers against best practices, listing specific headers, and distinguishes itself from the sibling 'scan_headers' by noting the difference between testing provided configs vs fetching live.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool (test config before deployment or validate non-public servers) and when to use the alternative (scan_headers for live fetching). Also mentions rate limits for free and pro tiers.

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 mark this as readOnly, idempotent, non-destructive. The description adds behavioral context: it scans code, returns results with severity, and explicitly states 'No data stored.' No contradiction with annotations.

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

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

The description is concise yet complete, front-loading the core purpose. Every sentence provides essential information (languages, usage, companions, rate limits, response format) without 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?

Given the tool's complexity (2 params, output schema exists, annotations present), the description covers purpose, when to use, supported languages, return format, rate limits, and data handling. No obvious gaps.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds value by clarifying that 'code' can be a single file or snippet, and for 'language' advises using 'generic' if unsure, going 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 explicitly states it scans for injection vulnerabilities (SQL, command injection, path traversal) via unsafe concatenation/unsanitized input, and lists supported languages. It clearly distinguishes from sibling tools like check_secrets and check_dependencies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance: 'Use to detect input-handling bugs; for secrets use check_secrets.' It also names companion tools and their purposes, and includes rate limits (30/hr free, 500/hr Pro), helping the agent decide when to invoke.

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. The description adds valuable behavioral traits: no data stored, and a detailed suppression rule for generic password assignments when more specific credentials fire. This goes significantly 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?

Description is moderately concise, with each sentence adding value. Could be slightly tighter but overall well-structured. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple languages, suppression logic, rate limits) and that annotations cover safety, the description is fully complete. Output schema exists so return values need not be explained.

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

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

Schema coverage is 100% with both parameters described. The description adds little to parameter semantics beyond enumerating language values (already in schema). However, the suppression rule context is useful but not parameter-specific. Baseline 3 is appropriate.

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

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

The description clearly states it scans source code for hardcoded secrets, lists supported languages, and differentiates from sibling tool check_injection for injection detection. The verb 'scan' and resource 'source code for secrets' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('detect leaked credentials before commit') and when not ('for injection detection use check_injection'). Also provides rate limits (30/hr free, 500/hr Pro), giving clear usage 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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context: active outbound fetch, per-target throttling, and rejection of bare IPs/private domains. While transparent, it could mention other potential behaviors like rate-limiting effects on response times.

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 well-structured, front-loading the purpose, then listing modules, usage guidance, constraints, and output fields. It is informative but slightly verbose (e.g., enumeration of all 11 modules). Could be tightened by summarizing modules without listing each.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an active scan with multiple analysis modules, the description covers essential context: what the tool does, how it differs from siblings, operational constraints (throttling, pricing), and what output to expect (including a listing of return fields). An output schema exists but is not shown; the description compensates by listing fields.

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

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

Schema coverage is 100% with a clear description for the single parameter 'domain'. The tool description does not add new parameter guidance beyond the schema, so baseline 3 is appropriate. No additional semantics are provided.

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

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

The description clearly states the tool performs an active security scan using the ContrastScan C engine with 11 specific modules, and enriches results with severity-ranked vulnerabilities and a letter grade. It distinguishes itself from sibling tools audit_domain and scan_headers by noting they are passive or headers-only, respectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to use this tool (hands-on misconfiguration scan) and when not to (use audit_domain for passive recon, scan_headers for headers only). Also provides throttling limits (60 req/min) and pricing tiers (Free/Pro), giving clear operational 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=true and idempotentHint=true. Description adds that verdict is at response root (not per-row), mentions rate limits (30/hr free, 500/hr Pro), and explains default slim avoids duplication. No contradictions. Could be more explicit about sorting order, but overall adds useful 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?

Description is front-loaded with purpose and usage, well-structured. Slightly verbose with multiple details packed into a single paragraph, but each sentence adds value. Could be more concise, but still 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?

Given tool complexity (3 parameters, output schema exists), description covers purpose, usage guidelines, parameter details, behavioral notes, rate limits, and output shape. References output fields implicitly. Complete for an AI agent to understand when and how to use the 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 coverage is 100% with descriptions for each parameter. Description adds significant value: explains include parameter default ('') returns slim list, 'full' returns more fields, and why slim default is used. Also explains verdict placement. Adds meaning beyond 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?

Description clearly states 'List CVEs indexed from MITRE/GHSA BEFORE NVD publication (early-warning, freshest data)'. It uses specific verb 'list' and resource 'CVEs', and distinguishes from siblings by mentioning data source and timing. It contrasts with cve_lookup (drill-down) and cve_search (published NVD 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?

Explicitly says when to use: 'Use for threat intelligence on emerging CVEs; use cve_search for published NVD data.' Also mentions for drill-down prefer cve_lookup. Provides clear alternatives and 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 indicate read-only, idempotent, non-destructive behavior. The description adds details on default truncations (20 affected products, 10 references), rate limits (30/hr free, 500/hr Pro), and optional parameter behaviors, providing comprehensive 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?

The description is lengthy but well-structured, starting with the main purpose, then default behaviors, parameter explanations, usage comparisons, and chaining hints. It efficiently conveys necessary information without redundancy, though brevity could be slightly improved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity with 5 parameters and rich output, the description covers all critical aspects: return fields, default truncations, optional flags, usage guidance, chaining, and rate limits. It is fully self-contained and sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the description adds meaningful usage context for each parameter, such as explaining when to enable include_full_references for bandwidth-bound cases and the purpose of include_severity_breakdown for surfacing vendor disputes.

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

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

The description clearly states 'Retrieve detailed CVE data by ID' and distinguishes from sibling tools like cve_search by specifying use cases. It provides a specific verb and resource, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool versus cve_search and provides chaining guidance to kev_detail, cwe_lookup, and exploit_lookup. Also includes recommendations for parameter settings like include_affected_products for bulk audits.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description reinforces. It details response formats (slim vs full), pagination with offset/limit, default sort, and the behavior of filters (e.g., null CVSS excluded when score filters active). Rate limits (30/hr free, 500/hr Pro) 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?

Despite its length, the description is well-structured: it starts with a concise summary, then covers response format, parameter nuances, usage alternatives, and rate limits. Every sentence adds value, and the information is front-loaded for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 14 parameters and numerous edge cases, the description thoroughly covers: tool purpose, response structure, parameter semantics, pagination, rate limits, and alternatives. It also hints at the output schema and includes a global hint for drill-down. No gaps remain.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains exact token matching for product/vendor, provides conversion examples for date filters, clarifies null CVSS behavior, and details the 'include' parameter's impact on payload size. This enriches understanding beyond the schema alone.

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

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

The description clearly states 'Search CVE database with filters...' and lists the specific filter criteria. It differentiates from siblings like cve_lookup (single CVE), check_dependencies, and tech_stack_cve_audit by explicitly stating their use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives: 'Use for vulnerability discovery by criteria... use cve_lookup for single CVE... For dependency/package lists prefer check_dependencies...'. It also explains nuances like exact token matching and hints for further drill-down.

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 indicate readOnly hint, idempotent, non-destructive. The description adds valuable behavioral details: returns 404 if CWE not in research view 1000, explains the slim vs full response via the include parameter, notes cve_count is a lower bound, and specifies rate limits (30/hr free, 500/hr Pro).

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 comprehensive and well-structured, front-loading the main purpose and then detailing return fields. However, it is somewhat verbose, listing all return fields which may be redundant with the output schema. Still, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (rich object with many fields), the description fully explains all return field behaviors, error conditions, rate limits, and how to use the include parameter. The presence of an output schema (though not shown) does not detract, as the description provides essential context beyond that.

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

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

The input schema covers 100% of parameters, but the description adds significant meaning: for cwe_id, it explains accepted formats (CWE-79, cwe-79, bare '79') and lists common values; for include, it clarifies default behavior vs full. This enriches the schema definitions.

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

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

The description clearly states that the tool looks up MITRE CWE catalog records, specifies the research view 1000, and distinguishes itself from sibling tools (cve_lookup, cve_search, kev_detail) by explaining when to use this tool in conjunction with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use this tool (after cve_lookup or kev_detail) and how to chain with cve_search. However, it does not explicitly state when not to use it, though the context makes it clear that it is for CWE lookups, not CVE details.

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 indicate readOnly, idempotent, non-destructive hints. The description adds valuable behavioral details: rate limits ('Free: 30/hr, Pro: 500/hr'), input cap ('Capped at 500'), and output structure ('Returns {queried_techniques, coverage_by_tactic, ...}'). No contradictions.

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

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

The description is concise (3-4 sentences), front-loaded with the key purpose, and every sentence adds value. No redundant or extraneous 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?

Despite having an output schema, the description enumerates the return fields and provides rate limits and usage advice. With one simple parameter and clear output structure, the description fully equips an agent to use the tool correctly.

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

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

Schema coverage is 100% for the single parameter 'attack_technique_ids', with description, maxItems, and example. The tool description adds little beyond the schema, such as the 500 cap and example with T9999, but baseline 3 is appropriate as the schema already does heavy lifting.

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 explicitly states 'Batch coverage breakdown: given a list of ATT&CK T-codes, return distinct defense counts per D3FEND tactic + identify which techniques have NO D3FEND mapping'. It uses specific verbs and resources, clearly distinguishing it from sibling tools like 'd3fend_defense_for_attack' or 'bulk_cve_lookup'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use to assess the defensive posture of an entire attack campaign or threat model in one call.' It also suggests pairing with 'cve_search per gap'. While it doesn't explicitly state when not to use it, the context is sufficiently clear.

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 (readOnlyHint, idempotentHint, destructiveHint) are supplemented with rich details: rate limits (30/hr Free, 500/hr Pro), truncation behavior ('defenses is capped at limit; total is honest pre-truncation count'), and response structure changes based on the 'include' parameter. No contradiction with annotations.

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

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

The description is appropriately sized for the tool's complexity. It is front-loaded with the core purpose, then logically flows to usage context, parameter details, rate limits, and response format. Every sentence earns its place without 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?

Given 4 parameters, high schema coverage, and an output schema (not detailed in input but referenced), the description covers the response structure, edge cases (no mapping, truncation), rate limits, and default behaviors. It leaves no significant gaps for an agent to infer incorrectly.

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

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

Schema description coverage is 100%, but the description adds significant value beyond schema: explains rationale for default limit, token savings with slim responses, use of exclude_id for chaining, and format of attack_technique_id. Each parameter's purpose is contextualized.

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 starts with 'Reverse lookup: given an ATT&CK T-code, return D3FEND defenses that mitigate it.' This is a clear and specific verb+resource pairing, distinguishing it from sibling tools like d3fend_defense_lookup (which looks up a defense by ID) or d3fend_defense_search (keyword search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Pair with cve_lookup or atlas_technique_lookup output — when those carry an ATT&CK id, call this tool to surface the mitigations.' It also explains the behavior when no mapping exists (returns empty list as a signal), providing clear context without excluding cases.

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, indicating a safe read operation. The description adds behavioral context: it returns 404 for unknown slugs, includes ATT&CK mitigation links, and describes the response structure (defense_id, label, attack_techniques, etc.), complementing annotations without contradiction.

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 concise, front-loaded sentences convey purpose and usage, followed by a brief list of response fields. Every sentence adds value—no fluff. Rate limits are efficiently noted.

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 lookup tool with output schema and annotations, the description is complete. It explains the relationship to ATT&CK, the role of d3fend_defense_search, and return fields, leaving no ambiguity for the agent.

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

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

Schema coverage is 100% with a clear description for defense_id (CamelCase slug). The description adds context by specifying the slug format ('TokenBinding', 'FileHashing'), but this largely overlaps with the schema. Nonetheless, it reinforces meaning and provides 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 clearly states 'Look up a MITRE D3FEND defense technique,' identifying both the action (lookup) and resource (defense technique). It distinguishes from the sibling d3fend_defense_search by noting this is for full record retrieval after search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use after d3fend_defense_search for the full record + ATT&CK chain,' providing direct guidance on sequence. Also notes 404 behavior for missing slugs and rate limits (30/hr, 500/hr), helping the agent decide when to invoke.

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 indicate non-destructive, read-only, idempotent. Description adds value by disclosing default slim response (saves ~60 chars/row), explain exclude_id behavior for chaining, and rate limits. No contradictions.

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

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

Single paragraph is dense but well-organized: purpose first, then usage details, then return format. Every sentence contributes value; could be slightly more scannable but not excessively long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and output schema exists, description covers all needed context: default behavior, optional parameters, chaining strategy, rate limits, and exact return structure. No gaps.

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

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

Schema has 100% coverage, but description adds practical context: explains 'include' impact on size, gives example for 'keyword' and 'exclude_id', and clarifies 'artifact' case-insensitive exact match. Not just repeating 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?

Description clearly states it searches the MITRE D3FEND catalog by keyword, tactic, or artifact, with examples like 'what defenses harden access tokens?'. Distinguishes from sibling d3fend_defense_lookup by specifying this tool is for discovery and that tool for deep dives.

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 explicit when-to-use guidance: default slim response, optional include='full', exclude_id for chaining. Mentions rate limits (Free/Pro) and directs drilling into d3fend_defense_lookup for deeper mappings.

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?

Adds value beyond annotations by disclosing that TXT records are returned raw with honest count, and directing to domain_report for filtered view. Also includes rate limit information, and aligns with annotations (read-only, idempotent).

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?

Description is a single paragraph but efficiently packs use cases, special behavior, rate limits, and return format. Slightly dense but every sentence contributes value; front-loads purpose and usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter and an output schema provided (mentioned in description), the description fully covers necessary context: what the tool returns, its limitations, and when to use alternative. No gaps.

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

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

Schema coverage is 100% with a clear description for the only parameter (domain). The description does not add additional parameter semantics beyond what the schema provides, so baseline score of 3 applies.

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

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

Clearly states it queries all DNS record types for a domain, with specific record types listed. Explicitly distinguishes from sibling tool domain_report by noting when to use that instead.

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 explicit use cases: mail routing inspection, nameserver verification, SPF/DMARC checks. Also tells when not to use it (use domain_report for security-only TXT view) and includes rate limits.

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 declare readOnly, openWorld, idempotent, and non-destructive. Description adds details: default TXT record filtering, honest pre-filter count in dns.total_txt_records, behavior of include_all_txt, and next_calls emission. No contradictions.

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

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

Single dense paragraph, but front-loaded with primary purpose. Every sentence adds value, though could be slightly more structured for easier scanning.

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?

Covers all key aspects: default behavior, parameter guidance, chaining via next_calls, rate limits, and return fields. Output schema exists, so description doesn't need to detail return types.

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

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

Schema coverage is 100% with good descriptions. Description adds significant value: explains why default filter strips vendor verification strings, when to set include_all_txt, and what the pre-filter count is.

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?

Clearly states it queries DNS, WHOIS, SSL, subdomains, and threat intel for a domain. Differentiates from sibling audit_domain which does live headers and tech stack.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says use as starting point for domain investigations and suggests audit_domain for live headers/tech stack. Also mentions chaining with subdomain_enum, ssl_check, tech_fingerprint via next_calls, and provides rate limits.

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 indicate readOnlyHint=true and destructiveHint=false, making the safety profile clear. The description adds rate limits (30/hr free, 500/hr Pro) which is useful beyond annotations. No contradictions. No further detail on timeout or error handling, but sufficient given the tool's simplicity.

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 well-structured, starting with the core function, then usage guidance, companion tools, rate limits, and return format. Each sentence adds value, though slightly longer than minimal. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with rich annotations and an output schema, the description covers all necessary context: purpose, when to use, alternatives, rate limits, and return structure. Nothing 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 single parameter 'email' is fully described in the schema (100% coverage). The description adds example addresses (user@tempmail.com, test@guerrillamail.com) but doesn't add significant meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool checks if an email uses a disposable/temporary provider, with specific examples (Guerrilla Mail, Temp Mail, Mailinator). It distinguishes itself from sibling tools like threat_intel and email_mx by specifying use cases: input validation vs. domain reputation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool ('for input validation to detect throwaway signups') and when to use alternatives ('for domain reputation use threat_intel'). Also lists companion tools (email_mx, domain_report, threat_intel) with brief descriptions of their purposes.

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 mark it as read-only and idempotent. The description adds detailed behavioral context: how DKIM status is determined ('verified' iff at least one selector responded, else 'unverifiable'), and explains the grading logic in full, including the nuance that DKIM absence is not penalized. No contradiction with annotations.

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

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

The description is comprehensive but efficient, front-loading the purpose and then detailing behavior and output structure. Every sentence adds value, though it is slightly dense. A minor improvement could be breaking into shorter sentences, but it remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has an output schema (described in the description) and good annotations, the description adds all necessary context: rate limits, behavioral details, grading logic, and output structure. It is fully complete for agent decision-making.

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

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

Schema coverage is 100% for the single 'domain' parameter, and the schema already describes it as 'Domain to analyze email configuration for.' The description does not add further parameter-specific meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it analyzes email security including MX records, SPF, DMARC, DKIM, mail provider, and grade. It distinguishes itself from the sibling tool 'domain_report' by noting that for a full audit one should use domain_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises when to use: 'Use to verify email-auth setup and phishing risk; for full audit use domain_report.' Also provides rate limits: 'Free: 30/hr, Pro: 500/hr.'

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?

Discloses DKIM probing behavior (common selectors + recent dates, custom selectors required), rate limits (30/hr free, 500/hr Pro), and passive nature (no SMTP probe). Adds significant value beyond annotations which already declare read-only and idempotent.

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?

Concise single paragraph with multiple sentences covering purpose, usage, behavior, and limits. No structural formatting but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description adequately covers score range, grades, authentication checks, dual-use, probing behavior, and rate limits. Complete for a 2-param 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 coverage is 100% so baseline is 3. Description adds value by explaining default DKIM probing behavior and that custom selectors must be supplied, which supplements the schema descriptions.

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?

Clearly states it analyzes domain email authentication posture (SPF, DMARC, DKIM) with numeric score and grades. Distinguishes from sibling tools like email_mx or email_verify by focusing on authentication rather than mere existence or verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly notes dual-use for red-team and blue-team, and states it is passive DNS-only with no SMTP probe. Provides clear context but does not explicitly list when not to use or alternative 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 indicate read-only, idempotent, non-destructive; description adds rate limits (Free: 30/hr, Pro: 500/hr), details on role_address detection (Gmail +tag stripped), and ethical decision not to do SMTP probing. No contradiction with 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?

Description is well-structured, front-loading the core purpose and usage, then expanding on details and limitations. While lengthy, every sentence adds value; could be slightly more concise 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?

Given the output schema exists, description covers all necessary aspects: purpose, usage, limitations, rate limits, behavioral nuances, and ethical context. Fully adequate for an AI agent to understand and use the tool correctly.

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

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

Only one parameter (email) with schema description already covering format. Schema coverage is 100%, so baseline 3 is appropriate. Description adds minor clarification ('Must contain @') but does not significantly extend beyond 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?

Description clearly states it is a 'one-call email validation' covering multiple checks (syntax, MX, disposable, role, free provider). It explicitly distinguishes from siblings like email_mx and email_disposable by replacing them with a single structured response.

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?

Explicit usage guidance: 'Use BEFORE adding an email to a contact list, sending an outbound message, or auditing a lead-list dump.' Also clearly states what it does NOT do (SMTP deliverability) and suggests alternatives (Hunter.io/NeverBounce).

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?

Discloses truncation behavior (SHODAN_REFS_LIMIT default 200, truncated flag), sources structure, and return fields. Annotations already declare read-only and idempotent, and description adds further behavioral details.

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?

Description is detailed and front-loaded, but somewhat verbose. Could be more concise while retaining key 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?

Complete coverage of sources, truncation, next_calls, and integration with sibling tools. Output schema existence reduces need for return value explanation.

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

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

Schema coverage is 100% with detailed description of cve_id format. Description adds no additional parameter semantics beyond 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?

Description clearly states it searches public exploits for a specific CVE across three sources, and distinguishes from cve_lookup by positioning as a follow-up for real-world risk assessment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (after cve_lookup to assess weaponized exploits) and when to pair with kev_detail and cwe_lookup. Provides next_calls guidance and avoids blind pivots.

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. The description adds behavioral context such as the rejection of v2 vectors with a 400 error, the inclusion of temporal/environmental scores when present, and the re-computation of base score. This goes beyond annotations without contradicting them.

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 informative but somewhat verbose, listing all output fields in a single string. While structured, it could be more concise by grouping related information. However, it front-loads the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of CVSS parsing, the description is thorough: it lists all metrics, describes handling of temporal/environmental metrics, mentions error cases, and provides rate limits. It is complete enough for an agent to use correctly.

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

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

Schema coverage is 100%, so the schema itself documents the vector parameter. The description adds meaning by providing an example vector string and clarifying that v2 vectors are rejected. This adds value 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 clearly states the tool parses a CVSS v3.x vector string into metrics and a recomputed score. It distinguishes from siblings by explicitly noting that v2 vectors are rejected and directing users to the cvss_v2_field on cve_lookup for v2 detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (to translate raw CVSS strings) and when not (v2 vectors are rejected, use cve_lookup for v2). It also includes rate limits (free 30/hr, pro 500/hr), which helps the agent decide based on usage constraints.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds the return structure ({found, malware_family, ...}) and rate limits, which are not in annotations. While there is no contradiction, the description adds moderate behavioral context 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?

The description is concise at roughly 6 sentences, front-loaded with purpose, then usage guidance, sibling tools, rate limits, and return value. No redundant content; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool with a clear output schema (return structure described), the description covers all necessary context: purpose, usage, alternatives, rate limits, and return format. It is fully sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with the single parameter 'file_hash' well-described in the schema (format, length, example). The description mentions the hash types (MD5/SHA1/SHA256) but this is already in the schema. Thus the description adds minimal semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool queries MalwareBazaar for file hashes (MD5, SHA1, SHA256) and lists the returned information (malware family, file type, etc.). It distinguishes from sibling ioc_lookup by specifying that hash_lookup is for file hashes only, while ioc_lookup auto-detects all IOC types. This provides a specific verb and resource, with clear 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 explicitly says 'Use to check if file hash is known malware; use ioc_lookup for auto-detection of all IOC types.' It also provides rate limit information (Free: 30/hr, Pro: 500/hr) and lists companion tools. This gives clear when-to-use and 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 indicate read-only, open-world, idempotent, non-destructive. Description adds specifics: per-type source coverage (hash→ThreatFox, IP→ThreatFox+Feodo+URLhaus, etc.), verdict fields (sources_queried, sources_unavailable), and error handling. No contradiction.

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?

Description is informative but slightly long. Well-structured: starts with purpose, then source coverage, verdict fields, usage guidance, rate limits, and final output shape. All sentences earn their 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?

Given tool complexity and presence of output schema, description covers all essentials: auto-detection, source details, verdict structure, rate limits, and sibling differentiation. No gaps evident.

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

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

Schema coverage is 100% with good description. Tool description adds context on auto-detection of indicator type and provides examples of valid formats, enhancing understanding beyond 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 clearly states it enriches IOC by auto-detecting type and querying abuse.ch feeds, listing supported types (IP/domain/URL/hash). It differentiates from siblings like threat_intel and hash_lookup by stating when each should be used.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use as primary IOC triage when type unknown, and directs to threat_intel for domain-only and hash_lookup for richer hash data. Also mentions rate limits (30/hr Free, 500/hr Pro).

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?

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals numerous behavioral traits: two-tier cloud provider detection, reputation sources per tier, null-explicit response, conditional `next_calls`, and a breaking change in vulns format. It also explains behavior when tier conditions are met.

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

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

The description is a single long paragraph (~350 words) that packs extensive details, version notes, and multiple behaviors. While informative, it lacks structural breaks and is longer than necessary for an AI agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (many return fields, tier differences, breaking change, conditional next_calls), the description covers all essential aspects: input, output fields, behavior under different conditions, rate limits, and differentiation from sibling. The presence of an output schema (implied by the return list) is leveraged by not needing to detail every field, yet the description still lists them for clarity.

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

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

Schema description coverage is 100% for the single parameter 'ip'. The description adds no additional semantic information beyond what the schema already provides (e.g., the example IPs are already in the schema's description). Thus baseline 3 is appropriate.

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

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

The description clearly states it queries comprehensive IP intelligence and lists numerous data points, with a specific verb 'Query'. It distinguishes itself from the sibling `threat_report` by noting that for orchestrated IP+reputation, one should use `threat_report`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use for IP investigation; for orchestrated IP+reputation use threat_report.' It also mentions rate limits (Free: 30/hr, Pro: 500/hr) and indicates when `next_calls` are triggered, but does not discuss exclusion scenarios like when not to use.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details: returns 404 when CVE not in KEV, lists all return fields including lifecycle metadata (date_updated, date_removed, updated_at), and mentions rate limits ('Free: 30/hr, Pro: 500/hr'). No contradictions.

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

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

The description is well-structured and front-loaded with the main purpose. It efficiently covers purpose, return fields, usage guidance, error behavior, rate limits, and follow-up without redundancy. Every sentence earns its place and adds distinct 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?

Given the tool's complexity (detailed KEV record with multiple fields) and the existence of an output schema, the description is comprehensive. It explains what each return field means (e.g., date_removed when CVE removed), describes error conditions, and provides usage context. No gaps remain.

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 (cve_id) with 100% schema description coverage. The description adds value by providing format examples ('CVE-2021-44228') and clarifying the expected format (CVE-YYYY-NNNNN), which goes beyond the schema's basic description.

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 it looks up CISA KEV full records for a CVE, specifies what fields are returned (e.g., due_date, required_action), and distinguishes itself from sibling tools like cve_lookup. It clearly identifies the resource (KEV record) and action (lookup), and contrasts with non-KEV CVEs.

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 explicitly says when to use ('after cve_lookup or cve_search(kev=true) when in_kev=true'), when not to use ('use cve_lookup for non-KEV CVEs'), and suggests follow-up actions ('chain with cwe_lookup on each returned CWE'). It also provides scenarios and 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?

Adds significant behavioral context beyond annotations: k-anonymity mechanism (5-char prefix, full hash never leaves), read-only, no data storage, and rate limits. Annotations already indicate readOnly, idempotent, and non-destructive, but description enriches with specific technical details.

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?

Reasonably concise with three sentences, front-loaded with purpose. Includes necessary extras (rate limits, siblings) without excessive verbosity. Could be slightly tighter but effective.

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?

Covers behavior, usage, companion tools, rate limits, and return format ({found, count}). Given the presence of annotations, output schema, and low complexity (1 param), the description is 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?

Schema has 100% coverage with description for the single parameter. Description does not add meaningful semantics beyond the schema, but the format is implied. Baseline score of 3 is appropriate.

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

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

Description clearly specifies the verb 'Check' and resource 'HIBP breach dataset', and distinguishes from siblings by naming companion OSINT tools. The use of k-anonymity is also explicitly 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?

Provides clear use case ('password breach audits') and states read-only nature. Includes sibling differentiation and rate limits, but does not explicitly exclude any contexts or mention when not to use.

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 indicate read-only, open-world, idempotent, and non-destructive. Description adds detailed behavioral context: staleness from historical records, is_malicious conditions, threat levels, and rate limits. No contradiction.

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 comprehensive yet not overly verbose. It front-loads the key logic and includes all necessary details. Could be slightly more structured, 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?

Given the presence of an output schema (context: Has output schema: true), the description covers all aspects: parameter, behavioral logic, sibling differentiation, rate limits, and return fields. Nothing missing for an AI agent to correctly invoke and interpret the 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 coverage is 100% with a detailed description for the single 'url' parameter. The description adds value by providing examples and explaining how the URL is used (including protocol requirement), going 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 clearly states the tool queries URLhaus for a URL and its host, explains the logic for is_malicious, and differentiates from sibling tools like threat_intel, ioc_lookup, and hash_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use for URL-level threat assessment and mentions alternative tool (threat_intel) for domain-level checks. Also lists companion tools and provides rate limits (30/hr Free, 500/hr Pro).

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, but description adds crucial behavioral detail: carrier is omitted in MNP-restricted regions, and carrier_status must be checked. Explains return format. No contradiction with 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?

Concise yet comprehensive: front-loaded purpose, then details, caveats, and companion tools. No fluff; 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 one parameter, 100% schema coverage, and an output schema (even though not shown), the description covers input format, use cases, rate limits, return fields, and a subtle behavioral quirk. Complete for agent decision-making.

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

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

Schema coverage is 100% (one parameter well-described), baseline 3. Description enhances with format requirements, examples of correct and incorrect inputs, adding significant value beyond 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?

Clear verb-resource pair ('Validate and analyze phone number') and specific outputs (country, region, carrier, line type, etc.). Explicitly distinguishes from sibling tools by naming username_lookup and email_disposable as companion OSINT 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?

States when to use: 'verify phone legitimacy and detect fraud risks'. Requires E.164 format with examples. Provides rate limits (30/hr Free, 500/hr Pro). Could mention when not to use, but context is sufficient.

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 description goes well beyond the annotations (readOnlyHint, idempotentHint, etc.) by disclosing SSRF-guarding (re-validation of resolved IPs), per-target throttle, loop detection, truncation at 10 hops, and error responses. These details are critical for safe and correct use.

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 concise yet comprehensive, structured as: purpose -> use cases -> behavior -> throttling/limits -> return value. Every sentence adds value, no redundancy, and it's well-organized for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of redirect chain analysis (multiple hops, loops, throttles, errors), the description covers all essential aspects. The output schema exists (mentioned in return fields), so the agent can understand the structure without further detail.

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 'url' is fully described in the schema (100% coverage). The description adds practical guidance: pass URL exactly as for curl -L, required format (http/https), and that encoding is handled. This enhances understanding 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 clearly states the tool walks HTTP redirect chains hop-by-hop, provides per-hop data (url, status_code, location, latency_ms), and lists specific use cases like deobfuscating URL shorteners and auditing suspicious links. This specificity distinguishes it from sibling tools (e.g., DNS lookups, IP lookups).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool (deobfuscate URL shorteners, phishing investigations, marketing tracking). It does not mention when not to use or list alternative tools, but the context of siblings makes this clear. The behavioral details (SSRF-guarded, hop limits) implicitly guide appropriate usage.

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 provide readOnly, openWorld, idempotent hints. Description adds crucial details: ContrastAPI User-agent, honouring Disallow for our UA, per-domain throttle (60 req/min), free/pro limits, and error handling (502 means upstream failure, not no robots). No contradiction.

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?

Well-structured and front-loaded with action and use case. Every sentence adds value, though slightly lengthy. Could be trimmed slightly but still effective.

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?

Covers edge cases (404, DNS failure), rate limits, user-agent handling, and output summary. With output schema present, description need not detail return values but does so helpfully.

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 100% and description adds that subdomains are accepted and the tool fetches HTTPS with HTTP fallback, providing clarity 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?

Clearly states 'Fetch + parse the target domain's robots.txt' and lists specific outputs (sitemaps, rules, crawl-delay, etc.). Distinguishes from sibling tools by focusing on robots.txt parsing, which no other tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Use BEFORE crawling/scraping a target site (seo_audit, brand_assets, redirect_chain) to honour the site's published rules.' Also explains how to handle 404 (implicit allow-all) and 502 (upstream failure).

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 indicate read-only, idempotent, not destructive nature. The description adds important behavioral details: header value truncation (500 chars default, CSP can exceed 4KB) and the option to pass include='full' for full raw values. This goes beyond annotations without contradicting them.

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 structured logically: what the tool does, when to use it, rate limits, truncation details, and return type. Every sentence adds value with no redundancy. It is appropriately front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, output schema present), the description is complete. It covers purpose, usage, behavioral quirks, and return structure. The output schema likely details return fields, so description does not need to explain them extensively.

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

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

Schema description coverage is 100% for both parameters, so baseline is 3. The description adds value by explaining the truncation behavior in context of the include parameter, specifically noting that CSP headers can exceed the default truncation limit, which helps with parameter selection.

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

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

The description clearly states the tool performs live HTTP GET and analyzes security headers, listing specific headers. It distinguishes from sibling tool 'check_headers' by specifying that scan_headers is for auditing live sites while check_headers validates existing headers.

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 explicit guidance on when to use this tool (audit live website headers) and when to use the alternative (check_headers to validate headers you already have). Also includes rate limit information (Free: 30/hr, Pro: 500/hr) to help manage usage.

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 indicate read-only, idempotent, etc. The description adds substantial behavioral context: rate limiting (60 req/min per eTLD+1), robots.txt honoring, cache skip conditions, error codes (502, 403), and scoring logic. No contradiction with annotations.

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

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

The description is lengthy but front-loaded with purpose. Every sentence adds value (scoring, constraints, error cases). Slightly verbose but efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 audit rules, error handling, rate limits, robots.txt, cache), the description is complete. Output schema exists, so return values are covered. No gaps in explaining behavior for a homepage-only audit 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 coverage is 100% with a good description for 'domain'. The tool description adds extra clarification: 'Strictly homepage-only' and 'bot fetches https://<domain>/... we do NOT crawl', which adds value 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 clearly states 'One-shot SEO audit of a domain's homepage' with a specific score and missing_signals list. It distinguishes from siblings by emphasizing it's homepage-only and not a crawl, and mentions deeper auditing tools like Lighthouse/SEMrush as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists when to use: 'BEFORE pitching SEO work', 'triaging a lead's marketing maturity', or 'pre-flight before deeper auditing tools'. Also implies when not to use (if crawling needed) and includes ethical floor constraints.

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?

Disclosures beyond annotations: daily refresh schedule, rate limits (Free: 30/hr, Pro: 500/hr), response structure with next_calls, and detailed return fields. No contradictions with annotations (readOnlyHint, idempotentHint).

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?

Well-structured with front-loaded action and clear organization. Each sentence adds value, but could be slightly more concise by combining some points. No 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?

Comprehensive coverage: purpose, input, return fields, use cases, follow-ups, rate limits, and data freshness. With an output schema available, the description is sufficient for correct invocation.

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

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

Schema coverage is 100% (parameter fully described). The description adds minor context about obtaining the UUID (from REST endpoint or SIEM). Baseline of 3 is appropriate as the schema already carries the semantic load.

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

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

The description clearly states 'Look up a single Sigma detection rule by UUID' and lists the specific fields returned. It distinguishes the tool from sibling lookup tools by specifying the unique data source (SigmaHQ corpus) and output details (e.g., detection logic, status, level).

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 concrete use cases: fetching a known rule for SIEM detection context or inspecting a rule from sigma_rule_search. Mentions natural follow-ups via next_calls. Lacks explicit comparison to alternative tools, but the unique resource (Sigma rule) makes usage clear.

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?

Description explains behavior beyond annotations: invalid certs return valid=false+validation_errors instead of failure, and differentiates grade D vs F. Annotations already indicate safe read operations; description adds valuable 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?

Description is well-structured and informative, but slightly verbose. Could be more concise without losing key 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?

Tool has output schema (not shown) and description lists expected return fields comprehensively. Covers all necessary aspects for a certificate checking 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 coverage is 100% with description for the single parameter 'domain'. Description adds example formats but no new meaning beyond schema. Baseline 3 is appropriate.

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

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

Description clearly states it analyzes SSL/TLS certificates with specific outputs (grade, protocol, cipher, expiry, etc.) and distinguishes from sibling 'audit_domain' by stating 'for full domain audit use audit_domain'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use case: 'Use to audit certificate validity and detect expiring certs; for full domain audit use audit_domain.' Also mentions rate limits (30/hr free, 500/hr pro), providing clear guidance on when to use.

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 indicate readOnly, idempotent, openWorld. The description adds passive nature, non-intrusiveness, rate limits, next_calls behavior, and detailed status interpretation (crtsh_status). No contradictions.

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

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

The description is well-structured, starting with purpose, then usage, then behavioral details. It is slightly verbose but every sentence adds value; no 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?

Given the tool's complexity (multiple sources, rate limits, status checks, next_calls), the description is thorough. It explains result interpretation, error handling, and output fields, complementing the existing output schema.

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 100% schema coverage for the single parameter (domain), the description adds minimal extra semantic meaning beyond the schema's description and example. Baseline of 3 is appropriate.

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

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

The description explicitly states the tool discovers subdomains using passive methods (CT logs + DNS brute-force) and describes its purpose for mapping attack surface. It clearly distinguishes from active probing tools and sibling tools like ssl_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use (mapping attack surface, non-intrusive) and includes rate limits (30/hr free, 500/hr Pro). It implicitly differentiates from ssl_check via 'capped at 5 ssl_check hints', but no explicit when-not-to-use statement.

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, destructiveHint=false, and idempotentHint=true. Description adds rate limits and return format. Does not contradict annotations. No additional behavioral traits needed.

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 well-structured sentences: first covers purpose and method, second covers usage guidance, rate limits, and output format. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description includes return format details ({technologies: [{name, category, confidence%, version}]}). With good schema and annotations, this is complete for a simple one-parameter 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?

Only one parameter 'domain' with schema description already clear. Description adds example formats ('example.com', 'shopify.com') but doesn't significantly enhance beyond schema coverage.

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?

Description clearly states the tool detects website technology stack, listing specific categories (CMS, frameworks, CDN, etc.) and methods (HTTP headers + HTML analysis). It distinguishes from sibling tool audit_domain by noting this is for passive reconnaissance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Use for passive reconnaissance') and when not to, with an alternative ('for full audit use audit_domain'). Provides rate limits (30/hr free, 500/hr Pro) to set expectations.

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 indicate read-only and idempotent behavior. The description adds significant behavioral context: MCP-only endpoint, local DB data sources, CVE batch size of 50, cost of 10 credits per call, and rate limits (Free 30/hr, Pro 500/hr). It also specifies the return structure. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose ('Composite tech-stack + CVE audit') and then elaborates with necessary details. It is appropriately sized for the complexity of the tool, though some details like cost and rate limits could be formatted more concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description thoroughly covers purpose, steps, data sources, limitations, cost, and return format. The existence of an output schema is mentioned. It provides complete information for an AI agent to select and use the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents the domain parameter. The description adds that IPs and internal hostnames are rejected, which is also in the schema description. No additional significant meaning beyond what schema provides.

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

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

The description clearly states it performs a composite tech-stack detection and CVE audit, detailing each step: detecting technologies, querying CVE database, enriching with KEV, and checking exploit availability. It distinguishes itself from sibling tools like tech_fingerprint or cve_lookup by being a combined audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use: for a comprehensive tech-stack and CVE audit. It mentions MCP-only, no tier gating, and local DB mirrors, but does not explicitly state when not to use or list alternative tools. This is sufficient but not explicit.

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, openWorldHint, idempotentHint, and destructiveHint false, establishing the tool's safety profile. The description adds context about single-source nature (URLhaus) and return format, enhancing transparency without contradiction.

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 concise: two sentences covering purpose and alternatives, plus a sentence on rate limits and return format. Every sentence adds value with no 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?

Given the tool's simplicity (one parameter, rich annotations, output schema), the description is complete. It covers data source, alternatives, usage context, rate limits, and return structure without gaps.

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

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

Schema coverage is 100% with a well-described domain parameter. The description adds no additional parameter details beyond the schema, so it meets the baseline for parameter semantics.

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

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

The description clearly states the tool checks a domain against abuse.ch URLhaus for malware-distribution URLs. It distinguishes from sibling tools ioc_lookup (multi-feed correlation) and phishing_check (specific URLs), making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use this tool ('fast domain-level threat assessment') and when to use alternatives (ioc_lookup for multi-feed, phishing_check for specific URLs). It also provides rate limits (30/hr free, 500/hr Pro), giving clear usage 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?

Discloses ASN prefix limit (at most 50) and workaround (asn_lookup with include_full_prefixes=True). Warns about breaking change in enrichment.vulns format since version 1.16.0. All information beyond annotations (readOnlyHint etc.).

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?

Well-structured with clear sections, though slightly long. Every sentence adds value; no fluff.

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?

Covers purpose, usage, limitations, versioning, rate limits, and return structure. Output schema exists but description still lists keys, making it comprehensive.

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?

Adds context to 'ip' parameter: specifies public IPv4/IPv6, gives examples, notes private/reserved IPs rejected. This enhances the schema description.

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?

Clearly states 'Query comprehensive threat profile for an IP' and lists data sources (Shodan, AbuseIPDB, ASN/geolocation, ports). Distinguishes from sibling 'domain_report' for domain 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?

Explicitly states use case 'IP investigation and SOC alert triage' and alternative 'for domain data use domain_report'. Also provides rate limits (Free: 30/hr, Pro: 500/hr).

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, openWorldHint, idempotentHint, destructiveHint. Description adds output structure, platform details, and rate limits, providing value 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, efficient and front-loaded with key information. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with one parameter, output schema provided, and annotations cover safety. Description is complete enough for an agent to use correctly.

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

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

Schema coverage is 100% with detailed description. Description does not add new semantic information beyond what schema already provides for the 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?

Description clearly states it searches for a username across 15+ platforms, listing examples like GitHub, Reddit, Twitter. Differentiates from siblings which are other lookup types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use for OSINT investigations and identity verification. Mentions rate limits but does not explicitly exclude misuse scenarios.

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, openWorldHint, idempotentHint, destructiveHint. Description adds critical behavioral context: rate limits, timeouts for heavy domains, status codes with authoritative vs unavailable, and warnings array with error codes. No contradictions.

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

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

Description is thorough but appropriately front-loaded with main purpose, then usage guidance, then edge cases. Could be slightly more concise, but every sentence adds value and is well-organized.

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?

Output schema is described in detail (domain, status, total_snapshots, etc.). With one parameter and full output description, the description covers everything needed for correct invocation and interpretation.

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 schema description already clear. Schema coverage is 100%, so baseline 3 is appropriate. Description doesn't add extra parameter info, but it's unnecessary.

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?

Description clearly states the tool retrieves Wayback Machine snapshots for a domain, listing what it returns (first capture, latest, total count, snapshot list). It also distinguishes from sibling tool domain_report, which is for a full audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says use for investigating domain history and age, and directs to domain_report for full audit. Provides rate limits (30/hr free, 500/hr Pro). Detailed guidance on interpreting status values, including that unavailable means unknown (not zero) and how to handle heavy domains, with fallback advice.

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, openWorldHint, idempotentHint, destructiveHint=false, so the safety profile is clear. The description adds value by specifying the return structure ({domain, whois: {...}}) and rate limits, though it does not need to repeat the annotation hints.

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 extremely concise: three sentences covering purpose, usage, rate limits, and return format. No fluff 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?

Given the tool's simplicity (one parameter, output schema provided), the description is fully complete. It covers what the tool does, when to use it, rate limits, and the output structure. The output schema handles return details.

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

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

Schema description coverage is 100% for the single parameter 'domain', providing clear examples. The description does not add additional semantic meaning beyond the schema, meeting the baseline expectation.

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

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

The description clearly states the tool retrieves WHOIS registration data and specifies the exact data fields (registrar, dates, nameservers, status). It distinguishes from the sibling tool domain_report by noting 'for full audit use domain_report'.

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 explicit use cases ('verify domain ownership, age, expiration') and an alternative tool ('for full audit use domain_report'). Additionally, includes rate limit information (Free: 30/hr, Pro: 500/hr), guiding usage based on plan.

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