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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the 20-item cap and the return shape {cves, missing, count}. The 'missing' field implies that some requested IDs may not be found, which is useful behavioral context the annotations don't capture.

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

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

Two sentences with zero waste. The first sentence states the action and cap, the second states the return shape. Everything 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?

There is an output schema present, so return values are documented there. The description covers the key behavioral notes (20 limit, enriched data, missing handling). For a simple 1-parameter, read-only tool with good annotations and full schema coverage, this is essentially complete. Minor gap: doesn't specify what 'enriched' means relative to the singular get_cve.

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 the schema already documents the cve_ids parameter fully ('CVE IDs (max 20)'). The description adds the return-format detail but not new parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 'Fetch up to 20 enriched CVEs by ID in one call' — a specific verb (fetch), resource (CVEs), and scoping constraint (by ID, up to 20, in one call). It distinguishes from the sibling get_cve (singular) and bulk_get_threats by specifying the resource type and batch limit. Returns structure is also noted, adding clarity.

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

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

The description implies usage — use this when you need multiple CVEs in one call rather than calling get_cve repeatedly. However, it does not explicitly state when NOT to use it or name alternatives (e.g., when you need fewer than 20, or when get_cve is preferable). The sibling differentiation is implicit via the bulk/batch framing 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=true and idempotentHint=true, so the safety profile is covered; the description adds valuable behavior beyond that: lean vs full row semantics, the reason a full dossier caps at 3 (~68 KB), and the guarantee that overflow is named in `deferred_ids` and 'never silently dropped.' The `missing` behavior for unresolvable IDs is also disclosed.

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

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

Three sentences, each earning its place: core capability first, then default-payload detail, then full mode, then cross-reference. No filler or repeated schema text; the most important constraint (20 IDs per call) is front-loaded.

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

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

Covers everything an agent needs to invoke correctly and interpret the result: the batch cap, both detail modes, overflow handling, missing IDs, and a pointer to the single-ID fallback. An output schema is present for return fields, so the description's grounding from `count`/`missing`/`deferred_ids` is ample.

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

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

Schema coverage is 100%, so the baseline is 3; both parameters are already documented, including the detail enum and max 20 on threat_ids. The description adds marginal value by explaining response-related semantics: what `count` counts, what `missing` contains, and why detail='summary' is what makes 20 fit in one response.

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?

Opens with a specific verb, resource, and constraint: 'Fetch up to 20 threats by ID in one call.' This cleanly separates it from single-ID get_threat, search-based search_threats, and get_recent_threats without needing to read any schema.

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

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

Explicitly names the alternative tool with its use case: 'Drill into any row with get_threat(id).' It also gives conditions for choosing the detail mode ('detail="summary" default, all 20 fit' vs 'detail="full"... max 3 ids per call'), so an agent knows when and how to call rather than guessing.

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 explains what the tool returns in detail (channels, dominant channel, artifacts, signal count, quality flags) beyond what output schema could convey. It also discloses the 404 behavior when no edge exists, which is useful behavioral context. The readOnlyHint=true and idempotentHint=true annotations are consistent with the description's read-operation framing, so there is no contradiction. The 404 disclosure adds genuine value not present in 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 dense sentences with zero wasted words. Every clause carries informational weight - the return contents, the intended usage trigger, the order-independence note, and the 404 case. Front-loaded with the primary purpose, followed by usage context. This is exemplary conciseness.

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

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

The tool has an output schema present, so return value documentation is handled there. The description covers the essential behavioral surface: what it computes, what it returns, when to use it, how parameters relate (order-independent), and the error case (404). For a relatively simple two-parameter correlation explanation tool with annotations and output schema supporting it, this description is 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 coverage is 100% and both parameters are self-documenting ('First threat ID' / 'Second threat ID'). The description adds one meaningful detail beyond the schema: the pair can be passed in either order (order independence). With complete schema coverage, baseline 3 is appropriate, and the order-independence note justifies not docking further but doesn't elevate beyond 3.

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

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

The description uses a specific verb-resource structure ('explain correlation') with detailed scope: the per-channel similarity decomposition, dominant channel, shared artifacts, signal count, and quality flags. It clearly distinguishes this tool from the sibling get_correlation_path, get_correlation_subgraph, and get_similar_threats by focusing on the evidence/explanation behind a similarity score rather than the path or subgraph.

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 states when to use this tool ('Use when get_similar_threats gives a score and you need the evidence behind it'), naming the predecessor tool by name. It also addresses invocation details ('Pass the pair in either order' - order independence) and the 404 error case when no edge exists. This is model usage guidance with explicit trigger conditions and alternative references.

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 non-obvious behavioral detail beyond those: score is per technique accounting for corpus threats, ranking is within a tactic, the layer is capped at 600 techniques and may carry a 'truncated' entry, and ATLAS/non-enterprise IDs are excluded. These are important for correct interpretation.

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

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

The description is dense and front-loaded with the primary purpose, but includes a full returned-structure list that duplicates the output schema. That sentence is slightly redundant, but otherwise every sentence earns its place and there is 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?

Given branch annotations and output schema exist, the description completely covers non-obvious behavioral details: the meaning of 'score', how the two modes differ, truncation behavior, exclusions, and the exact matching between parameters and use cases. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description largely mirrors that information and adds only a scoring context rather than substantially enriching individual 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 uses a specific verb and resource: 'Export a MITRE ATT&CK Navigator layer (enterprise-attack) for visualization.' It clearly distinguishes this tool from siblings like export_stix or get_mitre_coverage by naming the exact artifact and domain 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?

The description explicitly tells the agent to 'pass actor=<name>' for actor-level coverage or 'all=true' for platform-wide coverage, which is clear usage guidance for the two parameters. It does not explicitly enumerate when not to use this tool versus neighboring export/get_mitre tools, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral value by clarifying what is returned per format flavor (raw query text vs. full object), which is useful beyond the annotations. 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?

Two sentences, zero waste, front-loaded with the core purpose. It's efficient and every clause earns its place. Slightly more could be added about detection_id semantics but not required.

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

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

The tool is simple (2 params, both required, no nested objects) and has an output schema plus strong annotations. The description explains the format value semantics adequately. Could mention what formats are unsupported or typical file extensions, but for the simplicity level this is 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 coverage is 100%, so the schema already documents both parameters. The description adds the interpretation of the format values (spl/kql/sigma = raw text, json = full object), which is a genuine enhancement, though light. Baseline 3 is appropriate given high schema coverage and the modest added meaning.

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

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

The description states a specific verb (export) with a specific resource (one detection rule) and specifies the format dimension, distinguishing it from sibling tools like get_detections and export_stix. The scope ('one detection rule') is clearly delimited against bulk-export siblings.

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

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

The description clearly explains the format parameter semantics, distinguishing raw query text (spl/kql/sigma) from the full object (json). It doesn't explicitly name alternatives like export_stix or get_detections, but the format-flavor distinction gives strong usage context for when this vs. other export/get tools is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the 200-object/80KB cap with a note object on truncation, the trust flag 'community-unverified' for OSINT data, and the return structure with specific object types. It doesn't detail auth/permission requirements, but annotations cover the mutation-safety aspect well.

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, information-dense paragraph with no wasted words. Every sentence carries meaningful content: purpose, parameter requirement, output structure, OSINT option semantics, and truncation behavior. It could be slightly more structured (e.g., separating return format from option behavior), but it is appropriately compact for the richness it conveys.

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 and annotations are strong (readOnly, idempotent, non-destructive), the description fully covers the remaining contextual needs: return object structure, option semantics with trust implications, truncation limits, and the at-least-one-input requirement. This is complete for a moderately complex tool.

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

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

Schema description coverage is 100%, so all 4 parameters are documented in the schema. The description adds context that 'at least one' identifier is needed and explains the include_osint side-effect (adds sighting SROs with a community trust flag), which goes slightly beyond the schema. This is a solid baseline-plus scenario where schema handles most of the 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 clearly states the verb+resource (export a threat/actor/CVE as STIX 2.1 bundle) and the audience purpose (ingestion into TIP/SIEM). It distinguishes from siblings like export_detection and get_threat_bundle by specifying the STIX 2.1 format and detailed object composition, which are unique.

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

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

It states the requirement of 'provide at least one of threat_id, actor, or cve_id' and explains the optional include_osint behavior with its caveats. However, it does not explicitly say when NOT to use this tool versus alternatives like export_detection or get_threat_bundle, though the STIX format and TIP/SIEM ingestion purpose imply differentiation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds useful context about the output being deduplicated network indicators and firewall-ready format, but doesn't disclose additional behavioral traits beyond that (e.g., recency window, format specifics, or staleness policy). With annotations covering the safety profile, adding the dedup/actionable context earns a moderate score.

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

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

Two sentences, front-loaded with the core purpose, and the second sentence provides the alternative-tool guidance. Every clause earns its place with zero filler or redundancy.

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

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

The tool has no parameters, an output schema exists, and annotations fully declare the behavioral safety profile. The description covers purpose, output format, and alternative tool selection. The only minor gap is not clarifying the exact recency window or time range of 'recently observed' indicators, but with an output schema present, the return format doesn't need description. This is largely complete.

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

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

The tool has zero parameters and 100% schema description coverage is trivially satisfied. The description does not need to explain parameters because there are none. A baseline of 4 is appropriate for a zero-parameter tool where there is nothing to document.

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 what the tool does: compiles a firewall-ready C2 blocklist of active IPs, returns deduplicated indicators ready for a denylist. It distinguishes itself from sibling get_c2 by specifying when to use each ('use get_c2 with view="beacons" when you need the underlying beacon detail'). Specific verb (compile/generate) + specific resource (C2 blocklist) makes 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?

The description explicitly states when to use this tool ('Use this for actionable blocking') and names the alternative (get_c2 with view='beacons') for when beacon detail is needed. This is an explicit when/when-not pairing with a sibling named directly, satisfying the highest bar for 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes well beyond that by disclosing canonicalisation of tactic keys, DISTINCT technique counting, the 60-cap on mitre.technique_ids, relationship re-derivation, and the meaning of empty relationship lists. These are non-obvious behaviors an agent needs to understand the output.

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?

Though long, every clause carries semantic weight: the output inventory is compact, edge-case behavior is stated directly, and follow-up routing is front-loaded. The long sentence is dense but not bloated, and important caveats are placed ahead of alternatives.

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, the description need not re-specify return shapes. It covers the response's semantics, known data-quality quirks, the coverage caveat for relationships, and alternative tools for heavier detail. Nothing needed to invoke or interpret this tool correctly is missing.

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

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

Schema description coverage is 100% and the schema already documents name as 'Actor name or alias (e.g. 'APT29', 'Lazarus Group')'. The description's 'by name or alias' repeats rather than extends this. No additional parameter-level semantics are contributed.

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

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

The description states a specific verb and resource: 'Get a lean threat-actor profile by name or alias.' It enumerates the exact contents (metadata, attribution counts, MITRE rollups, IOC category counts, summaries, relationships), which clearly distinguishes it from siblings like get_actor_intelligence and get_threat.

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 'For heavy detail use the follow-up tools' and names get_threat, search_detections, get_detection_detail, search_iocs, and get_infrastructure_pivots. It also warns that an empty actor_relationships means 'UNRECORDED' rather than 'unrelated,' giving the agent interpretative 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 the readOnly/idempotent hints, the description discloses exactly how attribution is filtered and ranked: only shared entities whose actor list includes this actor or its aliases, with shared malware/infrastructure ranked above commodity TTPs. This adds meaningful behavioral context that annotations do not provide.

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

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

Two sentences carry the full message: the core purpose is front-loaded, followed by scope and ranking details. It is somewhat dense with parentheticals and capitalized emphasis, but every phrase adds value without 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?

With an output schema present, return details need not be described. A single required parameter is fully documented in the schema, and the description covers filtering, ranking, and intended use, making the tool callable without ambiguity.

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 already fully covers the single 'name' parameter with its type and example. The description does not add parameter-level detail, but with 100% schema coverage, the baseline applies without requiring compensation.

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 a specific composite intelligence picture for a threat actor with an enumerated scope: profile, actor_relationships baseline, and cross-actor attribution. It distinguishes itself from simpler siblings like get_actor or get_actor_relationships by emphasizing the cross-actor attribution component.

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

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

It explicitly frames the use case: "Use it to answer 'who else does this actor overlap with, and on what evidence'." It also explains scope boundaries, but does not name alternative tools or provide 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?

Beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, the description discloses that the table is sparse, that empty results mean 'unrecorded' rather than 'disproved', and that live coverage numbers are included in the response. This semantic nuance is essential for avoiding false negative conclusions and is not available from annotations alone.

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

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

The description is front-loaded with the core purpose and each sentence carries distinct value: scope, novelty semantics, exclusion semantics, sparsity warning, and parameter behavior. It is longer than an average description but every sentence earns its place, and the CRITICAL flag correctly draws attention to the most important interpretive rule.

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

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

The description fully contextualizes this tool: it tells the agent why it exists, what it cannot prove, what emptiness means, how it differs from an alternative, and what live coverage info will accompany the response. Combined with an output schema, nothing needed for correct invocation or interpretation is missing.

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

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

Schema coverage is 100%, so parameters are already documented, but the description adds operational meaning: actor applies to either side, 'Omit to list the whole baseline', and rel_type results can be discovered through the response's coverage.rel_types field. This goes beyond the schema's structural descriptions without being redundant.

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

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

The description names a specific resource (already-documented actor-to-actor links) with a specific verb (get) and explicitly lists relationship types like subgroup/overlaps/similar/linked-to. It also distinguishes itself from get_actor's relationship list by noting it matches both actor slots, so an agent can tell this tool apart from siblings.

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

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

It explicitly says when to call it ('Call this before claiming any actor-to-actor relationship is new') and what not to infer from it ('never to rule a relationship out of EXISTENCE'). It even names the alternative behavior in get_actor that differs, giving the agent clear routing guidance.

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

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

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral context: the distinction between data and tag_pairs, the field names and ranking order, the single_observation:true flag, and the data-quality caveat about 106 total pairs. This goes well beyond the annotations.

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

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

The description is dense but every sentence provides operational value: scope, data field meaning, ranking, the small-n warning, and threshold semantics. It is structured logically and front-loaded with the core resource and 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?

For a tool with only two parameters and an output schema, this description is unusually complete. It covers the data-quality caveats, field semantics, ordering, and interpretation warnings that an agent needs to correctly use the results. Nothing functionally important is missing.

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

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

The schema already describes both parameters at 100% coverage, but the description adds important semantics for min_cooccurrence: default 2 means the honest set, setting 1 includes single-observation pairs, and those rows should not be treated as true associations. This extra meaning goes beyond 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?

The description states a specific verb ('returns pairs'), a specific resource (MITRE ATLAS technique co-occurrence), and the scope (threats that attack AI/ML systems). It also explicitly distinguishes ATLAS techniques from free-text publish tags, so an agent can tell it apart from general MITRE or threat-search siblings.

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

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

The description gives clear on how to interpret results, especially the small-n warning: it tells agents not to report single-observation pairs as associations and that min_cooccurrence=2 is the honest default. It provides clear dataset context, though it doesn't explicitly name alternative sibling tools or when to use them instead.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description adds more useful behavioral context. It explains how to interpret the 'generator' field and asserts that 'derived' ordering must not be read as causality, which is valuable beyond what annotations or schema provide.

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

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

Three focused sentences, each carrying necessary information: what the tool returns, an important causal interpretation caveat, and an alternative tool for similar causal sequences. No filler is present, and the most relevant definitions come first.

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 rich annotations, full parameter coverage, an output schema, and a detailed semantics explanation, the description fully equips an agent to understand what the tool returns and how to interpret it. The alternate tool reference adds extra context for when this tool is the wrong choice.

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 the parameters and their differences are already well documented. The description does not add much parameter-level detail, but it does clarify the semantic meaning of the returned data. With a high-coverage schema, a 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?

States a specific verb and resource ('get the analyst-authored MITRE ATT&CK Flow for a threat') and defines the result as a causal DAG of actions, conditions, operators, and assets. It explicitly contrasts itself with a flat technique list, which makes its purpose clear and distinguishes it from sibling 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?

Provides explicit usage guidance by stating the tool returns asserted causality rather than a flat technique list, and warns against misreading 'derived' timelines as causal. It also names get_flow_similar_threats as the alternative for finding threats sharing a causal sequence.

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 a safe, idempotent read operation. The description adds behavioral nuance by distinguishing 'last real assessment' from 'last nightly intake,' and revealing it exposes research backlog/contradictions. This goes beyond basic read-only semantics.

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 sentence covering many output components. It is compact but somewhat run-on; it could be front-loaded and broken into clearer phrases. Still, no waste words.

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

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

The description covers the key data dimensions (breakdowns, backlog, contradictions, top actors, research clock) and annotations/output schema handle safety and return format. Missing is any explanation of the optional actor parameter or the 'recent' list it scopes, which is a gap relative to the 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?

The schema fully documents the one optional parameter (actor) with a clear description, so baseline is 3. However, the tool description never mentions the 'recent' list that the parameter refers to, creating a slight disconnect between the description's corpus-level scope and the parameter's scoping behavior.

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 defines the tool as providing corpus-level attribution coverage metrics, distinguishing between genuinely assessed, actor-labelled, and uncovered threats. This differentiates it from sibling tools like get_attribution_evidence, which focuses on evidence for a specific entity.

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

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

The description implies use for understanding overall attribution quality but does not state when to use it versus alternative tools or explicitly mention the optional actor filter. No exclusion criteria or alternative tool names are provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which broadly cover the safety profile. The description adds meaningful value beyond annotations by disclosing the distinct `state` field semantics and the fact that this tool reveals attribution depth (researched vs intake stub) — genuinely useful behavioral context about what the returned data represents.

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

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

Two sentences, zero waste. The first sentence enumerates the data fields returned; the second delivers the crucial differentiator (`state` and what it means). Every clause earns its place, and the example format mention adds concrete 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?

With a single required parameter, a high-coverage schema, full annotations, and an output schema present, most of the burden is already handled structurally. The description covers the key addition (state field semantics). It's a complete description for a focused, single-parameter lookup tool, though it could mention the output format/pagination slightly.

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

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

Schema coverage is 100% and the description clearly explains what the returned data will contain, which helps the agent understand what it's getting. The single parameter threat_id is fully documented in the schema with an example. With full schema coverage and one simple parameter, the description adds no additional parameter semantics needed beyond what's already provided, warranting the baseline 3.

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 this tool returns the attribution evidence for a threat: verdict, canonical actor, confidence, scope, evidence chain, signals, alternatives, and analyst reasoning. It explicitly distinguishes its purpose from siblings like get_threat by highlighting that it reports `state` (researched vs unresearched intake stub) which threats.threat_actor alone cannot convey.

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 explains that this tool reveals whether an attribution is a researched assessment or an unresearched stub — useful context for when to trust the output. However, it doesn't explicitly name when-not-to-use or point to alternative tools for getting the threat actor, leaving the when/alternative guidance implicit rather than 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it positions the data as 'live', names the default view as 'beacons', and clarifies that the tool returns raw records rather than transformed blocklist output.

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

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

The description is compact: one sentence states the main purpose, one enumerates the views with useful semantics, and one names the alternative tool. Every section earns its place and the most important information is front-loaded.

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

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

With 100% schema coverage, an output schema, and robust annotations, the description only needed to add purpose, view semantics, and sibling differentiation — all of which it provides. The missing details such as exact default limits and the offset caveat are present in the input schema, so nothing essential is absent.

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

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

Schema coverage is 100%, so the baseline starts at 3. The description goes beyond the schema by clarifying what each view means — for example, 'watermarks' is a Cobalt Strike watermark index and 'correlations' contains cross-C2 correlations — which makes the enum values more interpretable for an agent.

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 identifies the tool as querying the live C2 intelligence center and enumerates seven concrete views with short parenthetical definitions. It also distinguishes itself from the sibling generate_c2_blocklist by contrasting raw records with firewall-ready output, so an agent can pick the right tool without opening schemas.

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 explains the available data views and names the alternative generate_c2_blocklist for firewall-ready output. This gives the agent concrete when-to-use and when-not-to-use guidance rather than leaving that to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context by explaining the output categories (dedicated/mixed/shared fidelity, compromised flags) and the underlying reverse-DNS approach. It does not contradict any 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 concise sentences, front-loaded with the core purpose. The second sentence adds actionable guidance on filtering. No filler or redundant detail.

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

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

With an output schema present and annotations covering safety, the description fully explains the tool's purpose, key filters, and output nature. It does not address pagination or edge cases, but these are not critical for a read-only get tool with 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?

Schema covers limit and compromised descriptions; description reinforces fidelity filtering and compromised-host flags, giving tactical meaning beyond the enum. Limit's default/max is already in the schema, so no duplication needed.

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

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

The description uses a specific verb+resource: 'Reverse-DNS unmasking of C2 beacon infrastructure' and explicitly states what it returns (domains per IP, fidelity, compromised-host flags). It clearly distinguishes this from sibling tools like get_c2 or get_ioc_dns by focusing on infrastructure fidelity and shared-hosting separation.

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

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

Provides clear context: 'Answers "what else lives on this C2 infrastructure"' and instructs to 'Filter by fidelity to separate adversary-owned infrastructure from shared hosting.' It does not explicitly name alternative tools, but the guidance is sufficient for choosing this tool.

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?

Goes beyond annotations by explaining how membership is computed (the lightweight UNION of curated references and threats matching by title), warns that the curated table is thin, names the `matched_via` field values, and tells the agent to treat title-matched rows as leads. This is excellent behavioral disclosure.

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

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

The description is dense but every sentence serves a purpose: core action, output contents, membership source, and important caveat about trustworthiness. The warning about title rows is essential and the ClickFix example justifies why the union is needed.

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

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

A given output schema handles return shape, and the description fully covers what the tool does, how membership is sourced, and how to treat results. Nothing important needed by an agent deciding to call or trust it is missing.

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

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

With 100% schema coverage, the schema already documents the name parameter. The description adds extra value through concrete examples like 'Snowflake campaign' and 'ClickFix' and clarifies that title-based matching also matters, helping the agent pick a good input.

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

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

The description opens with a specific verb and resource: 'Pivot on a named campaign / operation by name'. It lists concrete returns — threats, actors, prevalence, ATT&CK techniques — so an agent knows exactly what intelligence it will get for a named campaign.

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

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

Usage context is clear: call this when you have a campaign name like 'Snowflake campaign' or 'ClickFix'. There is no explicit mention of when not to use it or comparison to sibling tools like list_campaigns or search_threats, so it does not reach 5.

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 that this is a hand-maintained release feed, not a deploy log, that it stopped being written in Feb 2026, and that the response carries latest_entry_date, stale_days, and a warning. This is valuable behavioral context well beyond what the idempotent/read-only annotations provide.

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

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

Every sentence earns its place: the resource and ordering constraint, the parameter guidance, and the critical staleness warning with alternatives. The most decision-relevant caveat is front-loaded and clearly formatted with NOTE.

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

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

For a simple one-parameter read tool with an output schema, the description is fully sufficient: it explains the data source, staleness, expected response markers, and directs the agent to the correct sibling tools. Nothing needed for correct invocation is missing.

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

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

The schema already documents limit with default and max values, and schema description coverage is 100%. The description restates 'Pass limit (default 20, max 100)' but adds no new semantic meaning beyond reinforcing that the parameter is optional.

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 this tool returns the platform changelog — new threats, detections, and features — ordered strictly newest-first by date. It goes beyond a mere restatement of the name by specifying the content scope and ordering behavior.

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 the agent when to avoid relying on this tool: for current platform state, use get_platform_stats or get_engine_status instead. It also warns not to answer 'what changed recently' from this feed alone, giving clear routing guidance relative to sibling tools.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details beyond annotations: upstream proxy failure returns community_error instead of erroring, and cluster labels are upstream AI output rather than Threadlinqs attribution. 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?

Three sentences with no redundant content. Each sentence earns its place: first lists the contents, second clarifies data provenance, third explains error handling. Very concise and front-loaded.

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

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

With an output schema present, return values are documented. The description covers purpose, data source, content fields, provenance caveat, and error behavior. Only missing explicit alternative tool comparisons, which for a simple read-only list tool is an acceptable gap.

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

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

Schema has 100% coverage for the single parameter 'limit' with its description (default 15, max 50). The tool description adds no further information about parameter usage, so baseline 3 applies.

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

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

Description clearly identifies what is returned (campaign clusters from community OSINT layer) and lists specific fields (cluster name, confidence, targeted brand, first/last seen, indicator count/types, tags, reporters). It distinguishes from siblings by naming the source (tweetfeed.live, CC0) and explicitly stating that cluster labels are upstream AI output, not Threadlinqs attribution.

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

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

Implied usage context is strong: the tool provides community-layer campaign data, and the description gives guidance on how to interpret labels (do not present as our assessment) and how to handle errors (report 'community feed unavailable' rather than 'no campaigns'). However, no explicit alternative tools or when-not-to-use scenarios are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior: it explicitly discloses the found:false return shape with the reason distinction (no edges vs different components) rather than an empty array, which is valuable behavioral context beyond annotations. Missing some context like hop semantics or path weighting, but 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?

Two sentences, zero filler. The first sentence delivers the core value in one flowing clause, and the second sentence proactively handles the negative-return case. Every clause adds 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?

Output schema exists, so return values are documented separately. Both parameters are documented, annotations cover the safety profile, and the description handles the edge case (found:false) and the interpretation guidance (weakest-link strength, connectedness question). This is complete for a read-only graph-query 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 clear descriptions for to, from, and max_hops (including the 1-8 range and default 6). The description reinforces path semantics (hop count, weakest-link strength) that map to max_hops usage. It adds value by explaining what the path represents per hop, but relies largely on the schema which already documents all three parameters well.

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

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

Clear verb-plus-resource ('Shortest evidence path between two threats across the similarity graph'), specific scope, and explicit answer to the analytical question ('is this incident connected to that campaign, and through what'). The output content is enumerated (intermediate threats, per-hop signal, weakest-link strength), which thoroughly distinguishes this from siblings like get_similar_threats or explain_correlation.

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

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

The description implies the tool answers connectivity questions between two threats but does not explicitly say when to prefer it over explain_correlation or get_correlation_subgraph, which appear as siblings and sound adjacent in purpose. No explicit when-not/alternative guidance, though the purpose statement ('Answers is this incident connected to that campaign') provides reasonable implied 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 cover read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds that the data is 'precomputed' and that 'overview' is a rollup across engines, which is useful behavioral context beyond annotations. It doesn't describe the response envelope, but an output schema exists and the parameter schema covers summary/paging behavior.

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

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

Two tight sentences. The core purpose ('Read precomputed cross-dataset correlations') is front-loaded, followed by the engine list and the drill-down workflow. No filler or repetition of structural data.

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 three-parameter read tool with full schema coverage and an output schema, the description supplies the missing conceptual layer: what the engines are and the recommended access pattern. It feels complete enough for correct invocation, only lacking any comparative positioning against sibling correlation tools.

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

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

Schema description coverage is 100%: all three parameters (limit, engine, offset) have detailed descriptions including enums and paging notes. The description adds strategy ('use overview first') but not parameter meaning 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 names a clear verb ('Read') and a clear resource ('precomputed cross-dataset correlations'), and enumerates all engine choices. It does not explicitly contrast itself with the many correlation-related siblings like get_correlation_path or explain_correlation, so it stops short of a full sibling-differentiation 5.

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

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

The description gives concrete guidance: use 'overview' first, then drill into a specific engine. This is useful, explicit, intra-tool routing. However, it does not tell an agent when to choose this tool over the many sibling correlation tools, so it misses exclusion/alternative 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 the annotations (read-only, idempotent, non-destructive), the description discloses important behavioral details: depth expansion is resource-bounded, edge_type pruning changes which nodes are reachable, and min_fidelity uses a scale that '0.5 filters nothing.' It also warns about comparing rounded fidelity and points to raw values, all of which is practical operational behavior.

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

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

The description is compact and front-loaded with the main purpose, followed by usage guidance and a nuanced numeric validation note. Every sentence earns its place: purpose, budget/expansion rationale, sibling differentiation, and edge-fidelity warning,

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

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

The description is thorough for a graph traversal tool: it covers output shape, expansion pattern, borrowing limits, sibling selection, scale calibration, and edge-specific raw data. With an output schema present and annotations covering safety, it doesn't need to enumerate every return field. It might not describe all edge response capabilities, but nothing essential for invocation is missing enough for a 3.

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 high (86%), so the baseline is decent. The description adds valuable semantics beyond the schema, especially for min_fidelity ('Scale is 0-100, NOT 0-1—typical NPMI edges sit between 5 and 30') and for edge_type pruning semantics. It doesn't add elaborate semantics for every parameter, but the ones it covers are materially helpful.

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 says specifically what the tool does: 'The N-hop neighbourhood around any graph node — nodes, edges, and each edge's fidelity — for incremental exploration of the correlation graph.' This clearly identifies the verb, resource, and output, and it differentiates from get_entity_profile by emphasizing 'actual edge topology.'

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 is explicit about when to use this tool: 'Start at depth 1 and expand' is directly tied to 'a whole-corpus graph exceeds every response budget.' It then names an alternative ('prefer get_entity_profile, which is cheaper') and the condition under which this one should be selected ('when you need the actual edge topology').

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 beyond the readOnlyHint/idempotentHint annotations by explaining subtle behaviors: the threat_ids field is a live join from threats.cve_list, stale derived-index disagreement is surfaced via threat_ids_note and threat_ids_derived_only, pre-release CPEs are collapsed into ranges, and blank CVSS/EPSS values mean NOT MEASURED. This is exactly the kind of behavioral context an agent needs.

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 each sentence earns its place by adding non-obvious operational details (live join, derived-only fallback, CPE collapsing, enrichment_status semantics, sibling routing). The core lookup purpose is front-loaded. It is somewhat long, but the complexity of the behavior justifies the length.

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 small, single-parameter tool, this description covers all needed non-obvious context. The output schema can document the return structure, so the description correctly focuses on semantics that would otherwise be a surprise: linkage provenance, stale index handling, collapsed counts, and the meaning of absent metrics. Nothing critical appears 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 input schema already documents cve_id with an example (CVE-2024-3400), and schema description coverage is 100%. The description repeats the same parameter guidance without adding new syntax, formatting, or validation details, so it provides no extra meaning beyond the schema. A 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's purpose: looking up a CVE by identifier and enumerating the specific data returned (description, CVSS, EPSS, KEV, weaknesses, products, references, threats). It also distinguishes itself from get_cve_intelligence by noting when that richer tool is preferred.

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

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

The description gives an explicit routing recommendation: prefer get_cve_intelligence when linked threats need titles, actors, detections, or velocity in one call. It also explains important interpretation context for enrichment_status and collapsed CPEs. It does not mention other sibling alternatives like bulk_get_cves, but for a single-CVE lookup the guidance is clear enough.

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 the readOnly/idempotent annotations, the description adds valuable behavioral nuance: it explains the authoritative join on cve.threat_ids, the reconciliation of attributed actors and techniques, and the corpus-relative weaponization rank. This clearly matches the non-destructive read annotation with 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 front-loaded with the high-level concept 'Composite CVE dossier in one call' and then enumerates the contained components. It is dense and somewhat list-like, but every component listed contributes to understanding what the tool provides.

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 tool with one required parameter, an output schema, and read-only/idempotent annotations, the description is complete. It clearly communicates the full scope of the returned intelligence including threats, actors, techniques, velocity ranking, sibling CVEs, and detections, so an agent is well-equipped to select and invoke it correctly.

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

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

The input schema already fully documents the single cve_id parameter with an example, so schema coverage is 100%. The description adds no additional parameter-level meaning, making the schema-based baseline of 3 appropriate.

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

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

States a specific verb and resource: 'Composite CVE dossier in one call' with a detailed inventory of what it returns. This clearly distinguishes it from singular tools like get_cve or get_cwe by emphasizing the aggregated, cross-referenced payload.

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

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

The phrase 'Composite CVE dossier in one call' gives clear context for when this tool is appropriate: when you need a broad CVE intelligence bundle rather than a single detail. It does not explicitly name alternative tools or exclusion conditions, so it stops short of a full 5.

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?

Even though readOnlyHint and idempotentHint already establish the operation is a safe lookup, the description adds important non-obvious behavior: CWE has no CVSS severity, likelihood_of_exploit is the ontology's own rating, related_cves is limited to top 20 with related_cve_count as the true total, and related_cves may be null when the join fails. This volume of field-level caveats goes well beyond what annotations convey.

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

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

The description is dense with useful information and has no filler, but it is written as a long run-on paragraph with many embedded caveats, making it harder to parse than it needs to be. It is front-loaded with the core action and purpose, but the structure could be improved with short clauses or separation.

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 read-only lookup with one parameter and an output schema, the description covers everything an agent needs: input format, available fields, related-tool routing, the CWE-vs-CVE severity distinction, and exceptional return values. No obvious behavioral gap remains.

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

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

The parameter cwe_id is already fully documented in the schema with the exact format ('CWE identifier (e.g. CWE-79)'), and the description only repeats that same format without adding normalization rules or boundary cases. Since schema_description_coverage is 100%, the 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 opens with a precise directive — 'Look up a CWE by identifier' — and distinguishes this from CVE-related tools by explicitly noting that CWE has no CVSS severity and directing severity-seeking callers to related_cves or get_cve. It also names the sibling search_vulnerabilities for a fuller CVE list, so the tool is clearly scoped among its siblings.

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

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

The description gives actionable routing guidance: use this tool for CWE details, switch to get_cve for scored severity, and use search_vulnerabilities with cwe=<id> for the complete list of related CVEs. These explicit alternatives and conditions leave little ambiguity about when to select this tool over siblings.

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?

Goes well beyond the readOnly/idempotent annotations by explaining the deterministic nature of the projection, the 197-of-1,891 coverage rate, the 200-with-empty-mappings case, why that absence is not an error, and when a 404 is actually returned. This is exactly the behavioral nuance an agent needs 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?

Every sentence in the description carries load: the core purpose, the coverage limitation, the empty-vs-notch response, and the interpretive caveat. The COVERAGE and IMPORTANT markers make the longer text easier to parse, and the most actionable guidance appears first.

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 only one required param and a complete output schema, the description still covers the full behavior: the default result, rare-empty state, the 404-only condition, and the fatal conclusion. There is no ambiguity left for an agent in interpreting either a result or an error from this tool.

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

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

Schema description coverage is 100%, and the schema already documents threat_id format and limit's default, max, and behavior. The description adds no new parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb ('Get') and a concrete resource: the defensive twin mapping from ATT&CK technique to artifact to D3FEND countermeasure, with coverage by defensive tactic. The scope is unique among the sibling tools and directly answers 'what would have stopped this'.

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 to use it for 'what would have stopped this' and gives clear behavior expectations: absence of a mapping is common and not an error, and countermeasure overlap must not be treated as correlation evidence. It does not name any alternative sibling tool, so the 'vs alternatives' guidance is implied rather than 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 establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat those guarantees. It adds behavior context by stating the latest-day default, the date override behavior, and the aggregate contents returned in the bundle. This is useful supplementary context and is fully consistent with the annotations.

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

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

The description is two sentences with no wasted text, and it front-loads the tool's core purpose and composition. The second sentence is a high-value routing signal that helps the agent decide what to do after receiving the bundle. Every part of the description 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?

Given zero required parameters, a rich output schema, full schema description coverage, and read-only/idempotent annotations, the description is sufficiently complete. It explains what the response will contain, how to customize it via date, and what to do next for more detail on a threat.

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 already describes both parameters with 100% coverage, so the description only needs to add marginal semantic value. It adds 'latest by default, or pass date' for date and summarizes top_n as 'top threats as LEAN summary rows,' but this mostly restates default semantics that a capable agent can already derive from 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 identifies the tool as a one-shot aggregate 'what happened' bundle composed of a debrief, platform stats, top recent threats, and correlations. It names a concrete resource category that an agent can distinguish from single-purpose sibling tools like get_debrief or get_correlations, and it even points to a complementary sibling, get_threat, for 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?

The phrase 'One-shot what happened bundle' gives a clear contextual use case: use this for a consolidated daily situational snapshot in a single call. It does not exhaustively contrast this with similar aggregate siblings such as get_landscape_briefing or get_threat_bundle, but it does provide useful routing guidance by saying to use get_threat(id) when more detail on a listed threat is needed.

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 subtle behaviors that annotations cannot capture: tags are recomputed live, tags_source distinguishes live/snapshot/none, and the theme sentence may be generated before ingest finishes, making snapshot_threat_count and theme_note potentially inconsistent. It also gives trust guidance: when they disagree, trust tags. This exceeds the baseline provided by annotations.

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

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

Three dense, purposeful sentences each deliver a distinct semantic point: the core data scope, the live/snapshot/no-tag distinction, and the stale-theme caveat. The most important information is front-loaded first and the description contains no wasted wording.

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

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

For a no-argument read tool, the description covers ordering, time horizon, ranking rules, tie-breaking, field provenance, staleness, and a trust heuristic, leaving no call-critical question unanswered. The output schema can fill in exact field names, so no missing return-value explanation is needed.

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?

This tool has zero parameters, so there is no input-schema ambiguity for a description to resolve. The description appropriately devotes its space to output semantics rather than parameter details, matching the baseline for a no-parameter tool.

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

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

Begins with a concrete verb and resource: 'Get the recent daily landscape themes', immediately scoped by 'newest first, 14 days' and 'top 6 threat tags'. This makes the tool's identity and output unmistakable and clearly differentiates it from other daily-intel sibling tools.

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

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

The intended use is strongly implied: call this when you need recent daily landscape themes with associated threat tags. However, it does not explicitly say when to prefer this over similar intel-read siblings such as get_landscape_briefing or get_daily_intel_bundle, so there is no direct alternative 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 declare readOnly, idempotent, and non-destructive behavior, so safety is covered. The description adds valuable context about the output structure (posture summary, themes, threats grouped by severity, etc.), which is not redundant 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?

Two sentences deliver the core purpose, output contents, and a prerequisite instruction. No redundant wording; highly efficient and front-loaded.

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

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

Given the output schema exists and annotations cover safety, the description is complete for an agent to invoke. It lists the debrief sections and the necessary prerequisite step, making it sufficient for correct use.

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 fully documents the date parameter with format and example (100% coverage). The description only repeats the YYYY-MM-DD format, adding no new semantic information beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves a full daily intelligence debrief for a specific calendar date, listing its contents (posture summary, themes, threats, etc.). It differentiates from sibling tools like list_debriefs and get_latest_debrief by emphasizing 'specific calendar date' and referencing the prerequisite list_debriefs call.

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

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

It explicitly directs users to first call list_debriefs to find available dates, providing a clear usage guideline. It does not enumerate all alternative tools, but the instruction implies this is the tool for a specific date rather than the latest debrief.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile. The description adds value by specifying the returned content depth (complete query text, metadata, threat mapping) beyond simple read semantics. However, it doesn't discuss behaviors like what happens with an invalid/unknown detection_id, rate limits, or whether the full query text is ever truncated.

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

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

One tightly-written sentence that covers purpose, scope, and returned content without waste. Every element earns its place — the query-format enumeration (SPL/KQL/Sigma) is valuable detail packed into few words.

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

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

The tool has an output schema, extensive annotations, and a single well-documented parameter, so the description's job is modest. It competently communicates what's returned (full query text, metadata, threat mapping). Minor gap: no mention of how a missing/unknown ID is handled or fallback behaviors, but for a read-only single-fetch tool with strong structured metadata, this is largely sufficient.

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

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

Schema coverage is 100% and the single parameter detection_id is simply documented as 'Detection ID'. The description reinforces the parameter's role (the ID of the detection to fetch) but adds no format, source, or usage detail beyond what the schema provides. With full schema coverage, 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 fetches full detail for a single detection rule by ID, enumerating specific content included (query text in SPL/KQL/Sigma, metadata, threat mapping). The verb 'Get' plus resource 'detection detail' is specific and distinct from siblings like get_detections (which lists detections) and search_detections (which searches).

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

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

The description implies this is for retrieving a single detection when you have a specific ID in hand, contrasting implicitly with get_detections (bulk listing) and search_detections (searching). It doesn't explicitly name alternative tools for when NOT to use it, but the single-ID parameter and 'full detail' framing make context reasonably 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context: pagination mechanics (has_more, next_cursor reusable as offset/cursor) and the specific precedence rule (cursor ignored when offset given). This enriches the annotation-based safety signals with concrete runtime behavior.

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

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

Three efficient sentences with zero wasted words. Front-loads the core purpose, then filters, then pagination mechanics. Every clause adds information that isn't elsewhere, and the structure logically groups listing behavior, filtering, and pagination in order of importance.

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

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

The tool has an output schema, which relieves the description of explaining return values. With 5 parameters, no required fields, pagination mechanics explained, and read-only idempotent semantics assumed from annotations, this is reasonably complete. Minor gap: doesn't name sibling alternatives (search_detections) for when broader search is needed, but the complexity is low enough that the description suffices.

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 all five parameters are documented in the schema. The description adds the relationship between cursor and offset (cursor decoded to offset, ignored when offset given), which is genuinely helpful beyond the schema. However, the individual parameter descriptions in the schema are already thorough; the description's contribution is mainly the cursor/offset interaction nuance, warranting baseline 3 rather than higher.

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 states a specific verb+resource ('List detection logic') and enumerates the content formats (Splunk SPL, Microsoft KQL, Sigma). It distinguishes from siblings like search_detections (which implies a search action) and get_detection_detail (singular detail) by specifying this is a listing operation with filters. Clear differentiation from sibling tools.

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

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

The description clarifies pagination behavior and mentions optional filtering by threat_id or type, giving clear usage context. However, it doesn't explicitly contrast with search_detections or get_detection_detail, nor state when to prefer this over those alternatives. The pagination guidance is strong but sibling differentiation is implied rather than 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value by disclosing the tool is a status/health read that returns state rather than data, and enumerates the derived statuses (ok/stale/empty) and pipeline metadata that compose the response. This complements rather than duplicates the annotations.

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

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

Two sentences, zero filler. The first sentence densely enumerates the return payload using semicolon-separated clauses, and the second gives one actionable directive. Every word earns its place with no rhetorical padding.

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

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

For a parameterless, read-only status tool with no nested objects, an output schema, and full annotations, the description is complete. It not only lists the payload categories but also the derived status vocabulary and the use-case context. There is an output schema to define return structure, so the description need not duplicate field 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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on describing what the tool returns instead of parameter usage, which is the correct approach for a parameterless tool. No parameter documentation is needed.

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

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

The description opens with a specific interrogative about pipeline health and enumerates exactly what is covered: per-engine row counts, last-compute times, ok/stale/empty status, nightly graph pipeline progress/stage/degraded flag, recent failures, and latest AUC eval. It clearly distinguishes from siblings like health and get_platform_stats by specifying the concrete data points returned.

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 final sentence gives explicit guidance: 'Check this before reasoning over correlation output if freshness matters.' This is a clear when-to-use directive tied to a specific downstream workflow (correlation reasoning). Though it does not name alternative tools, it provides actionable context for when this check is warranted.

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 state that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations: the output is a nightly snapshot, the data is grouped into specific lanes, coverage_basis distinguishes 'measured_zero' from 'not_measured', and c2_intel's 0% is explained as a true omission rather than a measurement artifact. This is exactly the kind of interpretive detail an agent needs to avoid misreading the data.

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

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

The description is information-dense but every sentence earns its place: the row set, the non-lane caveats, the hit_rate caveat, the measured-zero explanation, and the freshness warning. It is front-loaded with the main purpose and then adds necessary exclusions and interpretation guidance. There is no redundant 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?

For a no-parameter, output-driven tool, this description covers all the essential context an agent needs: what the overview reports, how the rows/lines are defined, what fields like hit_rate and coverage_basis actually mean, and how to check freshness. The output schema is already available, so the description does not need to re-list the return shape. No important usage aspect seems missing.

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

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

The tool has zero parameters, so there is no schema surface for the description to clarify. The description instead clarifies the semantics of the returned object, which is more than enough for an empty input schema. Since there are no parameters to describe, the baseline of 4 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 states a very specific resource: 'Health and coverage of the enrichment LANES feeding the platform,' and immediately enumerates the exact rows/groups the tool returns. It also clarifies what is not included (EPSS and KEV are fields inside cve_details, not separate lanes), which removes ambiguity an agent would otherwise have when deciding whether this matches the user's request.

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

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

The description gives strong context on how to interpret the result: values like coverage_basis have special meanings, hit_rate definitions vary by lane, and c2_intel's 0% is a true measured zero. It also cautions the agent to read as_status/stale_hours because this is a nightly snapshot. It does not explicitly name alternative sibling tools or a when-not-to-use condition, so it falls just short of a 5.

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 a safe read, but the description adds material behavior: the data source over-merges subgroups, alias entries are mappings not identity assertions, and relation/other_entities/corpus_uses_separately carry distinguishing semantic meaning. This is valuable context the annotation schema cannot convey.

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

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

Every sentence earns its place: reverse relationship, usage guidance, data-quality warning, key output semantics, and accepted inputs. The structure front-loads the differentiating relationship and remains dense 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 output schema exists, the description need not restate return formats; instead it provides the conceptual semantics that make the results interpretable, plus the over-merge warning that affects correct reasoning. It is complete for an agent deciding whether and how to invoke this tool.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents name, type, and uuid well. The description matches the input fields but adds no meaningful parameter details beyond what the schema states; its extra content is about output semantics and caveats.

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 first sentence gives a specific verb and resource ('Every alias the reference set maps to ONE entity') and explicitly contrasts it with resolve_entity, which 'only walks a single alias forward.' This immediately distinguishes it from a close sibling and makes the reverse-relationship clear.

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

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

It names the exact use case ('Use it to check alias collision') and the alternative tool (resolve_entity), while explaining how this tool differs and the common failure it addresses. The MISP over-merging caveat also tells the agent when the data may be misleading.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds genuinely useful behavior beyond those annotations: NPMI edges carry raw pmi/co-occurrence/marginal values, rarity is defined in terms of corpus_df vs corpus_n, and top_neighbors_truncated can hide low-fidelity neighbors unless limit is raised. This is transparent about an easy-to-misread response behavior.

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

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

The description is front-loaded and information-dense: the first sentence defines the core purpose, and the following sentences add high-value details like the NPMI payload, rarity semantics, and truncation caveat. It is somewhat long and technical, but no sentence is 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?

Given the tool has an output schema, annotations, a moderate parameter list, and strong parameter descriptions, the description supplies the missing context about return content, edge fields, rarity interpretation, and pagination/limit caveats. For a complex intelligence-graph endpoint, nothing essential for correct invocation appears to be missing.

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

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

Schema coverage is 67%, with node_id and limit already described, and node_type sufficiently conveyed by its enum. The description adds real parameter value: it explains how limit interacts with fidelity ordering, which matters because low-fidelity edges are the first dropped. It also contextualizes the node_id values across node types. This exceeds the baseline without fully replacing the schema's per-parameter detail.

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

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

The description clearly identifies the tool as a one-call dossier for any intelligence-graph node, naming the supported node types (threat, technique, actor, IOC, CVE). It distinguishes itself from the many sibling getters such as get_threat/get_actor/get_cve by claiming to replace five or six separate lookups, so an agent can select it with confidence.

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

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

The description states when to use it: when a consolidated overview with neighbors, rankings, and type-specific rollups is needed, and that it is the best token-per-call option in the graph family. It also gives practical guidance about checking top_neighbors_truncated and raising limit before concluding a neighbor is absent. It does not explicitly name alternatives or give when-not-to-use conditions, so it falls just short of a 5.

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 the tool as read-only, idempotent, and non-destructive. The description adds useful interpretation context: flow-derived findings only apply to the covered portion of the corpus, and clarifies the special gate semantics, which is beyond annotation content.

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

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

The description is compact and front-loaded about the returned information; the second sentence provides the operational instruction. There is no redundant wording or unnecessary schema information.

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

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

For a zero-input, read-only tool with an output schema and annotations, the description provides enough context about what coverage means, how it is split, and when to call the tool. No essential guidance is missing.

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

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

The tool has zero parameters, so the description is not expected to document parameter semantics. Schema already covers the entire parameter surface.

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

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

The description clearly states what the tool reports: corpus-wide ATT&CK Flow coverage split by provenance, plus totals for nodes, transitions, and path similarity, and the coverage-gate status. It is specific and reader can distinguish it from siblings like get_attack_flow and get_mitre_coverage, though it doesn't explicitly name an alternative.

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 to call this tool before reasoning over flow data so that findings are correctly interpreted against the covered slice. It gives clear usage context, but it does not state explicit when-not-to-use conditions or alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: the scoring algorithm, the ATT&CK Flow transition concept, and the expectation that it returns inspectable shared transitions like 'T1003>T1021'. 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?

Every sentence earns its place: the core operation, the uniqueness explanation, the return contract, and the independence from get_similar_threats. It is front-loaded with the primary verb and resource, and there is no padding.

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

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

With the output schema present, parameter meanings fully documented, and annotations covering side effects, the description is complete enough for an agent to successfully call this tool. The remaining constraints like min_score and limit are already captured in the 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?

Schema description coverage is 100%, with meaningful definitions already provided for threat_id, limit, and min_score. The description does not need to restate parameter details, and it does not meaningfully expand beyond what the schema says. 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 identifies the specific action: finding threats that share a causal SEQUENCE of techniques, using ordered-bigram cosine over ATT&CK Flow transitions. It also distinguishes this tool from the sibling similarity tool by explicitly stating its score is NOT folded into get_similar_threats' blended score.

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

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

It gives clear context on when this tool is valuable: when attack ORDER matters and flat-set similarity signals are insufficient. It names get_similar_threats as the alternative and contrasts its blended scoring, but it stops short of explicitly listing when-not-to-use conditions.

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, so the safety profile is covered. The description adds value beyond annotations by warning that a cluster of one event documented multiple times can look identical to a real multi-event campaign until the agent reads the duplicate_risk evidence fields (distinct_member_dates, date_span_days, shared_title_tokens). That is non-obvious behavioral context which prevents an agent from misinterpreting results.

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

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

The core identity of the tool is front-loaded ('Campaign clusters the engine assembled from the similarity graph'), and the differentiation from sibling tools comes in a clearly marked second sentence. The first sentence is dense with enumerations, but each item corresponds directly to actual return fields, so there is 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?

For a tool with one documented parameter and an output schema, the description fully explains the resource's origin, content, cluster semantics, the duplicate_risk caveat, and the naming neighbor tools. No information needed to call it correctly or interpret its output is missing.

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

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

Schema description coverage is 100% — the only parameter, limit, already carries a full schema description (default 15, max 50). The description adds nothing parameter-specific, but it does not need to; the schema fully documents the single input.

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

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

States a precise verb ('reports') and a well-scoped resource: campaign clusters the engine derived itself from the similarity graph (connected components + label propagation), with an explicit list of contents (label, cohesion, actors, techniques, IOCs, nation-states, per-member fields). It also differentiates itself from get_campaign_intelligence and list_campaigns, making the tool distinguishable from its closest siblings without opening any schema.

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

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

The description gives explicit routing rules: use get_campaign_intelligence when looking up a NAMED campaign from threat text, use list_campaigns for the roster of named campaigns, and use this tool for the clusters the engine derived itself. Each alternative is named with a criterion that selects it, leaving the agent with no inference to make.

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 the annotations (readOnlyHint, idempotentHint, destructiveHint), it explains important behavioral details: results derive from the same indicator universe as the correlation graph, pivots carry value_threat_count thresholds, and confidence is rarity-based. It also clarifies a real semantic trap — that zero pivots can mean either a genuine negative or merely no pivotable indicators, and that labels are excluded by design so the returned evidence is not overstated.

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 front-loads the primary purpose and then earns every subsequent sentence with real-value guidance: value_threat_count interpretation, coverage semantics as denominator, and when to route to get_similar_threats. It is dense but appropriately so for a tool whose output requires careful interpretation.

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

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

There is one required parameter, an output schema is present, and independent annotations already cover read-only/idempotent safety. The description supplies the missing interpretive context — how to read pivot_count/value_threat_count and why zero results can still be meaningful — making this complete for the agent to invoke and consume the tool responsibly.

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 already gives 100% coverage of the only parameter, threat_id, with a format example. The description adds no additional parameter detail beyond framing it as the 'given threat,' so the baseline of 3 applies; the schema is doing the heavy lifting here.

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

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

The description states a clear verb and resource: "surface cross-threat infrastructure links" for a given threat, listing the exact artifacts involved (IPs, domains, hashes, DNS overlaps). It differentiates itself from get_similar_threats by explicitly disclaiming TTP/actor-based similarity, leaving no ambiguity about 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?

The description says when to use it (to find shared infrastructure across threats) and when not to ('labels are deliberately not pivotable') with a direct pointer to the alternative: 'Use get_similar_threats for TTP/actor-based similarity instead.' It also tells the caller how to interpret edge cases like pivot_count=0 with scorable_iocs > 0 vs = 0.

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

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

Annotations already declare readOnly and idempotent, so the safety profile is covered. The description adds critical behavior beyond that: case-insensitive matching, CVE union semantics from two sources, authoritative CVE-to-threat mapping, and the caveat that edge_scores is a sampled projection and never the denominator for 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?

Three sentences, each dense with necessary information and no filler. The core purpose is front-loaded, and the behavioral caveats are organized logically.

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

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

The description is complete for a moderately complex but bounded tool: it explains inputs, depth semantics, matching behavior, edge probabilities, CVE-specific union logic, and tool alternatives. An output schema exists, so detailed return values do not need to be restated.

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 the schema already documents both parameters. However, the description adds meaningful elaboration: it defines depth traversal rings concretely (1=threats, 2=+techniques, 3=+actors & sibling IOCs) and clarifies the meaning of coverage and edge_scores in the output, 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 states a specific action ('Map the blast radius'), a precise resource ('one indicator'), and enumerates the output dimensions (threats, MITRE techniques, actors, sibling IOCs). It also differentiates itself from the closest sibling by explicitly saying get_ioc_intelligence is for a richer multi-source dossier.

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 this to scope impact of a single IOC' and names the alternative for a richer dossier on one indicator (get_ioc_intelligence). This gives the agent clear selection criteria and an exclusion.

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, and destructiveHint=false, so the safety profile is well covered. The description adds meaningful context beyond these annotations: it clarifies that the data is 'previously resolved and cached' and explicitly flags that this is NOT a live lookup — a key behavioral caveat not captured by any annotation. Minor deduction for not describing the output format beyond 'reverse-IP and subdomain records.'

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

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

The description is three sentences and tightly written with zero filler. It front-loads purpose in the first sentence, adds the critical non-live caveat in the second, and points to the alternative in the third. Every sentence earns its place. Minor deduction only because the parenthetical 'reverse-IP and subdomain records' could arguably be integrated more cleanly, but this is essentially optimal.

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 is a simple single-parameter read operation with comprehensive annotations (readOnly, idempotent, non-destructive) and an output schema present, the description is largely complete. It covers the stored-vs-live distinction, the input scope, and points to the richer sibling. Context signals show only 1 parameter, 100% schema coverage, and presence of an output schema, all of which reduce the descriptive burden. Could add pagination/limits info for many-record DNS results, but that's speculative.

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 single required parameter 'value' has a clear description ('IP address or domain'). The main description reinforces the acceptable input types. Since the schema already documents the parameter fully, the baseline of 3 applies — the description adds slight value by phrasing it as 'stored DNS enrichment lookup' but not much beyond schema. There's only 1 parameter, so there's little semantic ambiguity to resolve.

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 what the tool does: 'Return stored DNS enrichment for an IP or domain indicator.' It specifies the resource (stored DNS enrichment), the scope (IP or domain), and explicitly differentiates from siblings ('Use get_ioc_intelligence for the full stored dossier'). The verb 'Return' plus resource 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?

The description explicitly notes this is a read of stored/cached data, NOT a live lookup at call time, which prevents misuse. It also names the alternative get_ioc_intelligence for a fuller dossier, giving clear when-to-use vs when-not guidance. This is exceptional usage guidance for a retrieval tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the composite-content framing and that it returns 'full story' in a single call, which is marginally useful context. It doesn't note rate limits, data freshness, or what happens for unknown indicators, but with strong annotations the bar is met at a moderate level.

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, both earning their place. The first states what the tool returns; the second gives routing guidance with a sibling alternative. Zero filler, front-loaded with 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?

An output schema exists, so return-value explanation isn't needed. With strong annotations (read-only, idempotent), strong schema (100% coverage), and one simple parameter, the description covers the essential context. It could potentially mention what happens with an unrecognized indicator, but for a single-param read-only dossier tool, this is sufficiently complete.

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

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

Schema description coverage is 100%, so the schema already documents the 'value' parameter as an exact indicator value (IP, domain, hash, or URL). The description reinforces that a single exact indicator is expected, which aligns with the schema. Since the schema does the heavy lifting, baseline 3 is appropriate; the description adds little beyond what the schema states.

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 verb ('Get'), resource ('composite intelligence dossier'), and scope ('for one indicator'), then enumerates contents: linked threats, actor attribution, related IOCs, and enrichment context. It also distinguishes itself from the sibling search_iocs by clarifying it works with an exact indicator value. This is a specific, well-defined purpose.

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 directs to prefer this over search_iocs when an exact indicator value is available and full context is needed. This implies search_iocs is for broader/fuzzy searches. Naming the alternative tool with a clear when-to-use rule is exactly what dimension 2 rewards.

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