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

With no annotations provided, the description carries the full burden and does well: it discloses the data source (RSS feed), post-processing behavior ('Extracts MITRE techniques, CVEs, and attributed actors'), and data freshness ('Cached 1 hour'). This gives the agent a solid behavioral model beyond the raw search operation.

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

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

Four short sentences, roughly 40 words, with the primary purpose front-loaded. Each sentence adds information: what it searches, the source agency, extraction behavior, and caching. The acronym expansion ('ACSC (ASD)' → 'Australian Cyber Security Centre') is mildly redundant but useful for clarity.

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

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

For a low-complexity tool (2 params, 1 required, no output schema, no enums), the description covers the essential operational details: source, match types, enrichment output, and freshness. Minor omissions like empty-result behavior and pagination are acceptable gaps for a simple RSS search 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 schema already documents both params ('Search keyword: actor name, CVE ID, malware family, or advisory topic' and 'Max results to return (default: 10)'). The description mostly paraphrases the query parameter without adding new semantic detail, meeting the baseline for high schema coverage.

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

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

States a specific verb ('Search'), a specific resource ('ACSC (ASD) RSS feed'), and the match criteria ('keyword, CVE, actor name, or malware family'). 'Australian Cyber Security Centre' clearly identifies the national source, distinguishing it from regional siblings like anssi_search, jpcert_search, and cisa_search_advisories.

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 source identification ('ACSC', 'Australian Cyber Security Centre') implies this tool is for Australian government advisories, giving the agent useful context among many national CERT/advisory siblings. However, there is no explicit when-to-use/when-not-to-use guidance, no exclusions, and no mention of how it differs from overlapping tools like govt_joint_advisory_search or cccs_search.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'Adds' something, implying a write operation, but it does not disclose whether entries are append-only, deduplicated, persisted for later retrieval, or what kind of response is returned. For a mutation tool, this is a meaningful gap.

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

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

The description is a single, front-loaded sentence that states the action, object, and context without any redundant phrasing. It is appropriately sized for a simple mutation tool whose parameters are fully self-documented in the schema.

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

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

The schema fully describes the parameters, so the invocation details are mostly covered. However, the description does not mention where the learning is stored, whether it can be retrieved later, or how it relates to sibling tools like get_learnings, leaving some context incomplete for an agent deciding whether and how to call it.

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 input schema already documents all five parameters, including examples for topic and the 0-1 range for confidence. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Add') and a specific resource ('learning or insight gained during analysis'), making the tool's purpose clear. It distinguishes from search tools and even from log_decision by framing this as capturing analysis-derived knowledge, though it does not explicitly name sibling alternatives.

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

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

'Gained during analysis' provides a clear contextual trigger for when to use this tool: when the agent has produced a learning or insight while analyzing. It does not explicitly describe exclusions or alternatives, but the purpose of adding knowledge is well-enough scoped.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read-only reporting operation via 'Get' and 'Returns', and adds the useful detail that the payload is ~2KB. It does not discuss auth, rate limits, or default behavior when source_type is omitted, but the risk profile appears low.

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 a helpful size hint and a concise parameter note. Every sentence adds value, though the output list is slightly dense.

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

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

Given the simple one-parameter surface, the description adequately explains what results are returned, including a payload size estimate. With no output schema, it sufficiently covers return expectations, although it could clarify the all-sources default behavior when source_type is not provided.

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

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

Schema description coverage is 100%, so the schema already documents the parameter. The description adds the scoping intent ('scope to a single rule source') and implies the filter is optional, but it does not specify what happens when the parameter is omitted.

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 MITRE ATT&CK coverage stats and enumerates the exact outputs: tactic breakdown, top 10 covered techniques, and weak-spot tactics. It is specific about the resource and result, though it does not explicitly differentiate itself from sibling tools like get_coverage_summary or get_top_gaps.

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 how to use the optional source_type filter but gives no guidance on when to choose this tool over the many overlapping MITRE/coverage-related siblings. There are no explicit alternatives or exclusions, leaving the agent to infer the appropriate 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool identifies IOC type and provides analysis guidance, but it does not describe what analysis is performed, whether external lookups occur, or what the output looks like. This is thin but not contradictory.

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 sentence with the core action front-loaded and no filler. The phrase 'analysis guidance' is somewhat vague, but the overall structure is compact and easy to parse.

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

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

For a single-parameter tool, the definition is minimally sufficient for invocation, but with no output schema or annotations it does not explain what the returned guidance looks like or how it relates to sibling IOC search tools. An agent can call it correctly but may not know what to expect in response.

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

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

Schema description coverage is 100%, and the schema already documents the ioc parameter as 'hash, IP, domain, URL, etc.' The description adds the idea of identifying the type but no additional parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Identify') and resource ('type of an Indicator of Compromise') and adds that it provides analysis guidance. However, it does not explicitly differentiate this tool from sibling IOC lookup tools such as threatfox_search_ioc or otx_pivot_hash, so the distinction is somewhat implicit.

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

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

There is no guidance on when to use this tool versus the many sibling IOC lookup and pivot tools. It neither states conditions for use nor names alternatives, leaving the agent to infer selection from the name alone.

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

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

With no annotations, the description carries the full burden and adds genuine value: 'Cached 1 hour' discloses potential staleness, and 'Extracts MITRE techniques, CVEs, and attributed actors' previews enriched result content. It omits rate limits and result language, but for a simple read-style search tool this is solid 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?

Four short sentences, each earning its place: core search function, source clarification, extraction behavior, and cache caveat. The primary function is front-loaded in the first sentence with zero filler.

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

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

For a low-complexity tool (2 params, 1 required, no output schema, no nested objects), the description covers source, match types, caching, and extracted fields. Minor omissions — result language and empty-result behavior — are unlikely to cause a mis-call.

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 query and limit adequately. The description reinforces the query's accepted value types (actor name, CVE ID, malware family, topic) but adds no new format, syntax, or constraint detail beyond the schema — 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 ('Search') and resource ('ANSSI / CERT-FR RSS feed'), with explicit match scope (keyword, CVE, actor name, malware family). The named source cleanly differentiates it from sibling feeds like jpcert_search and cert_eu_search without needing the 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?

Usage context is implied by naming the French feed — an agent seeking CERT-FR advisories would plausibly select this — but there is no explicit when-to-use/when-not-to-use statement and no alternative tools are named. Given the large sibling set, explicit routing guidance would materially help.

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 the data source ('ANY.RUN sandbox telemetry'), the selection basis ('based on analysis submissions'), and the temporal scope ('currently trending' / 'right now'). It is a read-only trend lookup and this is conveyed clearly even without 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 provide the core purpose and use case with minimal fluff. The only minor redundancy is 'currently' and 'right now,' but overall the description is appropriately sized and front-loaded.

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

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

For a zero-parameter trending feed with no output schema, the description gives enough context to invoke the tool and interpret the result conceptually. It could add detail about return fields or trend window, but the low complexity keeps this from being a significant gap.

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

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

The tool has zero parameters, so the baseline is 4. The description complements the empty schema by specifying what the returned data represents: currently active malware families. No additional parameter explanation 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 uses a specific verb and resource: 'Get currently trending malware families from ANY.RUN sandbox telemetry.' It clearly identifies both the data source and the intended result, and since no other sibling tool covers ANY.RUN trending data, it is well distinguished.

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 a clear use context: 'Useful for real-time threat landscape awareness.' It does not explicitly name alternatives or say when not to use it, but the narrow scope of 'currently trending' makes the appropriate scenario evident.

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

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

With no annotations provided, the description carries the full burden and does a solid job: it discloses the operational behavior (checks for ART test existence and detection rule presence per technique) and the return artifacts (coverage matrix, prioritized gaps, per-technique status). It implies a read-only report operation, though it does not explicitly confirm read-only status or clarify whether prior coverage data ingestion is required.

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 core purpose in the first clause and the output list and use cases following. There is minor redundancy between 'Batch validation of detection coverage' and 'For each technique, checks if ART tests exist and if detection rules are present,' but each sentence still earns its place.

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

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

For a single-parameter tool with no output schema and no annotations, the description is reasonably complete: it covers inputs, mechanism, return values, and use cases. The main gaps are the lack of guidance on choosing among the many overlapping coverage/ART siblings and no mention of dependencies or edge-case behavior for invalid technique IDs.

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 technique_ids with format examples. The description's 'batch... across multiple MITRE techniques' reinforces the plural/array intent but adds no new syntax, format, or constraint information beyond what the schema provides.

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

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

The description names a specific verb (batch validates), a resource (detection coverage across MITRE techniques), and a method (Atomic Red Team tests), then spells out the exact checks performed and outputs produced. It clearly differentiates from siblings like art_validate_technique (singular) and generic analyze_coverage by emphasizing batch validation across multiple techniques.

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 the tool ('threat actor profile validation or coverage audits'), giving clear context rather than leaving it implied. However, it does not name alternatives or exclusion conditions, which matters given the crowded sibling field of analyze_coverage, identify_gaps, coverage_gaps_detail, and art_validate_technique that an agent could confuse this with.

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

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

With no annotations, the description carries the full behavioral burden. It signals a read-only operation via 'Get' and adds useful context that data is 'indexed' and includes repository sync status. It does not detail rate limits or authentication, but for a simple stats retrieval this is adequate.

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

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

A single sentence that front-loads the core purpose and then lists the specific summary categories. Every word contributes value, with no filler or redundancy.

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

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

For a tool with no parameters and no output schema, the description thoroughly describes the expected return content. An agent knows exactly what kinds of statistics it will receive and can invoke it without additional inference.

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

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

The tool has zero parameters, and the empty schema already communicates that. The description adds no parameter-level detail because none is needed; this aligns with the baseline of 4 for parameterless tools.

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

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

The description uses a specific verb and resource ('Get summary statistics about indexed Atomic Red Team tests') and enumerates the concrete outputs (total tests, techniques covered, platform/executor breakdown, top techniques, sync status). This clearly distinguishes it from siblings like art_search or art_get_test, which focus on individual tests or search results.

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

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

The description gives clear context: use this tool when you need an overview of indexed Atomic Red Team test statistics. However, it does not explicitly name alternatives or state when not to use it, especially among similarly named tools like get_stats or get_mitre_attack_stats, so some ambiguity remains.

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

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

No annotations exist, so the description carries the full burden. It discloses the operation is a read ('Get') and lists the returned content: attack command, cleanup command, arguments with defaults, dependencies, and platform requirements. It does not mention behavior on missing/invalid GUID, potential errors, or whether it is strictly read-only, but the core behavior is transparent.

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

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

One sentence with no filler. It front-loads the purpose and then packs the return fields into a single efficient clause. Every word contributes to the agent's understanding.

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

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

For a single-parameter lookup with no output schema or annotations, the description is nearly complete: it explains input, purpose, and what the response contains. It omits edge cases like invalid GUID or non-mutating guarantees, but an agent can invoke it correctly with the information given.

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 schema already fully documents the guid parameter as 'Atomic test GUID (UUID format)'. The description only says 'by its GUID,' adding no new semantic detail beyond the schema. Baseline of 3 applies because the schema handles parameter documentation.

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 full details of a specific Atomic Red Team test by its GUID.' The phrase 'by its GUID' and 'specific' clearly distinguish this from sibling art_get_tests (which presumably lists multiple tests) and art_search. An agent can identify this tool as the singular, ID-based lookup.

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

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

The description implies usage: call this when you already have the test GUID and need full details. However, it never names alternatives or states when not to use it, such as 'to search by name or technique, use art_search instead.' Compared to the best examples, this leaves routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's return behavior by listing the kinds of information returned (test names, commands, cleanup commands, platforms, executor type, input arguments), which helps the agent anticipate output. It does not mention side effects or auth requirements, but the 'Get' semantics imply a read-only operation.

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

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

Two dense sentences deliver the core purpose, the return contents, and the intended use without filler. The action and resource are front-loaded, and every clause adds useful information.

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

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

For a simple retrieval tool with two parameters, the description adequately covers what the tool does, what it returns, and why to use it. The lack of an output schema is mitigated by the explicit return-field list. Minor omissions like behavior on invalid technique IDs or pagination do not seriously hinder correct invocation.

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

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

Schema description coverage is 100%, so the input schema fully documents both `technique_id` and `platform`. The description's mention of 'MITRE ATT&CK technique' reinforces the primary parameter but does not add substantial 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 clearly states the action ('Get') and the precise resource ('all Atomic Red Team adversary simulation tests for a MITRE ATT&CK technique'). It also enumerates the returned fields, distinguishing it from the singular sibling `art_get_test` by emphasizing 'all tests' and 'full attack surface'.

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

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

The description provides explicit intended use: 'Use to understand the full attack surface for a technique.' It does not enumerate exclusions or explicitly compare to alternatives like `art_get_test`, but the plural scope and the stated purpose give clear context for when this tool 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?

With no annotations, the description carries the full burden. It explicitly discloses 'Pure string analysis — never executes anything' and enumerates the four match categories, which is important behavioral context. It does not cover auth or rate limits, but those are less critical for a static analysis tool.

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

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

The description is dense but every sentence earns its place: it explains the analysis type, the output categories, the additional gap identification, and the safety guarantee. It is slightly long but well-structured and 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?

There is no output schema, so the description appropriately explains the return value by listing match statuses and the missed-tests identification. It is complete enough for an agent to understand what the tool does and what it returns, though exact output structure is not specified.

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 fully. The description adds general context about field-by-field cross-referencing but does not add parameter-specific meaning beyond what the schema provides.

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

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

The description states a specific verb ('parse', 'cross-reference') and resource ('Sigma rule's detection conditions' against 'Atomic Red Team test artifacts'). It clearly distinguishes itself from sibling ART tools by describing the match matrix output and the unique condition-status taxonomy.

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 implies when to use this tool: when you need to map Sigma rule conditions to ART coverage. It does not explicitly name alternative tools or state when not to use it, but the static-analysis framing and 'never executes anything' provide clear context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the corpus size (~1,770+), the fields searched, and example query types, but it does not state case sensitivity, matching behavior, result ordering, or output format. This is useful but incomplete.

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 no filler. The core action and corpus are front-loaded, followed by concrete search dimensions and examples. Every sentence earns its place.

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

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

For a simple search tool whose parameters are fully documented in the schema, the description is largely complete: it states what is searched, the corpus, and when to use it. It lacks explicit return-format details, but the 'find tests' purpose makes the expected output reasonably clear.

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. The description adds meaning for the keyword parameter by listing the fields searched and example query patterns, though the schema already contains similar examples. This is modest added value beyond the schema.

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

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

The description states a specific verb ('search'), a clear resource ('all Atomic Red Team tests'), and the exact scope ('full-text'), then enumerates the fields searched. This differentiates it from sibling tools like art_get_tests and art_get_test by emphasizing query-based search across test content.

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 use cases: find tests by attack tool, binary, technique pattern, or artifact, with concrete examples. It does not mention when not to use it or point to alternatives for exact test retrieval, so it falls 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?

With no annotations, the description carries the full burden, and it delivers by explaining the per-test check behavior and the return value: a validation matrix with COVERED/GAP status and overall coverage percentage. It does not explicitly state read-only/no side effects, but the described behavior strongly implies it, and no contradiction exists.

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 filler: core action, detailed behavior/return, and usage guidance. The most important information is front-loaded, and every sentence earns its place.

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

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

For a single-parameter tool with no output schema, the description adequately covers the operation and the return format (matrix with coverage status and percentage). It could mention edge cases like 'no tests found' or 'no matching rules', but overall it is complete enough for an agent to decide to invoke it and understand the result.

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

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

Schema description coverage is 100%, and the schema already documents technique_id as a MITRE technique ID with an example. The tool description reinforces that the technique is used for cross-referencing ART tests, but adds no new parameter-specific format or constraints beyond the schema. Baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Cross-reference') and resource ('Atomic Red Team tests against existing detection rules for a MITRE technique'), clearly distinguishing it from related siblings like art_get_tests or get_coverage_summary. It states exactly what the tool does and the scope of its operation.

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 'Use this to find blind spots in rules you thought were complete' provides clear usage context. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough among siblings (e.g., art_coverage_report, analyze_coverage) that the guidance is 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?

The description discloses the core behavior: it queries MalwareBazaar for all samples sharing an imphash and indicates a read-style operation. However, because no annotations are provided and there is no output schema, it does not convey return structure, pagination, or behavior such as whether results are limited by the limit parameter beyond the schema note.

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—two sentences that communicate the action and the threat-intelligence value. The 'ELITE PIVOT' label is somewhat stylistic but not harmful, and the key functional information 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?

For a simple two-parameter query tool with no output schema, the description is mostly sufficient: it states what the tool does, why it matters, and the primary lookup key. It falls short of complete because it does not describe the return format or explicitly guide selection against sibling bazaar 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?

With 100% schema description coverage, the baseline is already covered. The description adds meaningful context beyond the schema by explaining that imphash matches imply shared codebase origin and variant discovery, which helps an agent understand the analytical value of the imphash parameter.

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

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

The description states a specific verb and resource: 'Find all MalwareBazaar samples sharing the same PE import hash (imphash).' This clearly identifies the tool's function and the main query parameter. It does not explicitly contrast itself with sibling tools like bazaar_lookup_hash, but the imphash-scoped behavior is 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 gives clear context for when this tool is valuable: when pivoting from an imphash to reveal variants compiled from the same codebase. It implies the use case of hunting for loosely-related malware families, though it does not explicitly name alternatives or state when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it only says 'Retrieve' and 'most recently submitted.' It does not describe response format, pagination, ordering guarantees, rate limits, or any side effects. The verb implies a read operation, but with zero annotation support, this is minimal 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 one concise sentence with the core action and resource front-loaded. The trailing purpose clause 'for ambient threat intel sync' is somewhat vague but does not add unnecessary bulk.

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

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

For a one-parameter read tool, the description sufficiently identifies the operation, source, and general purpose. However, with no output schema and no annotations, the agent is left without return-shape or behavioral context, making the overall completeness adequate but not strong.

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 input schema already fully documents the single 'limit' parameter with its range and default. The tool description adds no parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description states a specific action, resource, and scope: 'Retrieve the most recently submitted samples from MalwareBazaar.' This clearly distinguishes it from lookup/search siblings by focusing on recent submissions rather than hash, family, or tag queries. It does not explicitly name a sibling alternative, so it falls just short of a 5.

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

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

The phrase 'for ambient threat intel sync' implies a recurring background intelligence-gathering use case, but no explicit when-to-use or when-not-to-use conditions are given. There are no named alternatives or exclusions, leaving the agent to infer the appropriate context from the sibling list.

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

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

With no annotations, the description carries the transparency burden. It usefully discloses return content (imphash, malware family, tags, vendor detections) and implies a read-only lookup, but it does not mention potential API prerequisites, rate limits, or error 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 a single, front-loaded sentence that states the action, the resource, the accepted input formats, and the return fields. Every word 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?

For a one-parameter lookup tool with no output schema, the description covers purpose, accepted input, and key return fields. It could add explicit context about external API access or that the operation is read-only, but the essential information needed to invoke it correctly is present.

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 already documents the hash parameter with accepted types. The description's mention of 'SHA256, MD5, or SHA1' merely restates the schema, adding no new semantic value beyond it.

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

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

The description clearly states a specific verb ('Look up'), a resource ('a malware sample in MalwareBazaar'), and the accepted hash types ('by SHA256, MD5, or SHA1'). It distinguishes itself from family/tag search siblings by focusing on hash-based lookup, though it does not explicitly name any alternative sibling.

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

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

Usage is implied: an agent should use this tool when it has a file hash to resolve. However, the description provides no explicit when-not-to-use guidance or alternatives such as bazaar_search_family or bazaar_get_imphash_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?

With no annotations, the description carries the full burden of behavioral disclosure. It does mention return fields, which is useful, but it claims to return 'all samples' while the schema's limit parameter caps results at 100, making the description misleading about actual scope. It also omits pagination and limit 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 two short sentences with no filler. The primary action and scope are front-loaded, and the return-value sentence earns its place by compensating for the missing output schema.

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

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

For a two-parameter search tool with fully documented schema, the description is mostly adequate: it states the resource, the query concept, and the return fields. However, the 'all samples' wording conflicts with the limit parameter, and there is no guidance on how this relates to sibling family/tag/hash search 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%, so the schema already documents both parameters. The description adds no significant semantic detail beyond restating the 'malware family' concept, which keeps it at the baseline.

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 ('Search'), names the resource ('MalwareBazaar'), and defines the scope ('all samples belonging to a malware family'). It also states the return payload (hashes, imphashes, file metadata), which differentiates it from sibling tools like bazaar_lookup_hash or bazaar_search_tag.

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 when to use the tool: when you need samples by malware family. However, it provides no explicit when-not-to-use guidance or alternatives, leaving the agent to infer the choice from the tool name and sibling list.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates that this is a read-only search operation returning malware samples, which is adequate, but it does not mention result format, pagination, rate limits, or external API behavior. For a simple search tool this is acceptable but not richly transparent.

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

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

The description is a single, front-loaded sentence that states the action, source, and search key, then gives useful examples. Every word earns its place and there is no redundant or vague 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 simple two-parameter search tool with no output schema and no annotations, the description is mostly complete. It identifies the source, the search dimension, and example values, and the schema covers the parameters. It could be slightly more complete by noting what fields are returned, but that is not required for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete example tag values ('keylogger', 'ransomware', 'loader'), which helps an agent understand what valid inputs look like. The limit parameter is not described in prose, but the schema already documents it with a default.

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 ('Search'), a specific resource ('MalwareBazaar'), and a specific dimension ('by tag') with concrete examples. This clearly distinguishes it from sibling tools like bazaar_search_family and bazaar_lookup_hash, which search by different keys.

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 implies the tool is for finding MalwareBazaar samples when you have a tag such as 'keylogger' or 'ransomware'. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it over family/hash/recents searches.

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

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

With no annotations present, the description carries the burden of behavioral disclosure. It usefully discloses that content is enriched with automatically extracted TTPs, CVEs, actors, and malware families, but it does not describe the result format, pagination, freshness, or any external-access limitations.

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 action and source, followed by the automatic extraction value. Every clause adds information 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?

For a low-complexity search tool with complete parameter schemas, the description is nearly sufficient. The only meaningful gap is the lack of an output schema or explicit description of the returned result objects, though the extraction clause gives a strong hint of what comes back.

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 both parameters with 100% coverage: query and limit with default/max. The description reinforces the kinds of query values ('ransomware incidents', 'threat actor activity') but adds no parameter-level detail 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 uses a specific verb and resource: 'Search BleepingComputer' for cybersecurity news, ransomware incidents, and threat actor activity. It also states the value-add of extracting MITRE TTPs, CVEs, actors, and malware families, which clearly distinguishes it from the many other source-specific searches in the sibling list.

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 does not explicitly name alternatives or when-not-to-use, but the source-specific framing ('Search BleepingComputer') plus the sibling list of other source feeds (anssi_search, cisa_search_advisories, etc.) makes the intended context clear. No exclusion criteria are given, so it stops 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?

With no annotations provided, the description carries the behavioral disclosure burden. It reveals useful behavioral traits: it searches an RSS feed, extracts MITRE techniques/CVEs/attributed actors, and caches results for 1 hour. It does not mention rate limits or authentication, but for a straightforward read-only search tool the disclosed details are meaningful and not contradictory.

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: the primary action and target source appear first, followed by the source organization, extracted content, and caching behavior. Every sentence earns its place without redundant or filler wording.

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

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

For a simple two-parameter RSS feed search with no output schema, the description gives a solid picture: what is searched, what kinds of queries are accepted, what enriched fields are extracted, and a caching caveat. It could be even more explicit about the exact shape of the returned results, but it is sufficiently complete for an agent to select and invoke this tool effectively.

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

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

The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds context that the query can be a CVE, actor, malware family, or advisory topic, but the schema already states this for 'query'. The 'limit' parameter is only documented in the schema, so the description does not significantly increase parameter clarity.

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: 'Search CCCS / CCIRC RSS feed for security advisories.' It also names the Canadian Centre for Cyber Security and lists concrete search subjects (keyword, CVE, actor name, malware family), making it easy to distinguish from sibling tools like anssi_search or jpcert_search.

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

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

The description provides clear context for when to use this tool by identifying CCCS/CCIRC and the Canadian Centre for Cyber Security, which is important among a large set of country-specific advisory feeds. It does not explicitly name alternatives or exclusion conditions, but the source association is strong enough to guide selection.

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

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

No annotations are provided, so the description carries the full burden, and it delivers meaningful behavior: 'Extracts MITRE techniques, CVEs, and attributed actors' reveals enrichment beyond a plain feed search, and 'Cached 1 hour' discloses data freshness. It omits rate limits and result ordering, but for a read-only search tool the disclosed traits are substantive.

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

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

Three short sentences with zero filler: the action is front-loaded, the content source follows, and enrichment/caching close it out. Every sentence earns its place.

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

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

For a low-complexity, read-only tool with 2 flat parameters and no output schema, the description covers the source, match semantics, extracted fields, and caching. The extraction sentence partially compensates for the missing output schema. Minor gaps remain around result ordering and pagination, but nothing an agent needs to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's matching types ('keyword, CVE, actor name, or malware family') largely restate the query parameter's schema description, adding little new semantic meaning beyond confirming the searched corpus is the CERT-EU RSS feed.

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 ('Search'), a precise resource ('CERT-EU RSS feed'), and the scope of matching ('keyword, CVE, actor name, or malware family'). Naming the exact feed source clearly distinguishes it from sibling tools like anssi_search, jpcert_search, and cisa_search_advisories without needing to open their 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 second sentence, 'CERT-EU threat intelligence publications for EU institutions,' provides clear context on the content coverage, which lets an agent route to this tool when EU-CERT advisories are needed versus alternative national-CERT feeds. However, it does not explicitly name alternatives or state when not to use it, so it falls 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?

No annotations are provided, so the description carries the full burden. It accurately conveys a read-only membership check, but it does not disclose the return shape (e.g., boolean vs. matched record), behavior for CVEs not in the catalog, or data-source freshness. This is adequate for a simple check but not rich.

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

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

One front-loaded sentence with no filler. The acronym is expanded and the exact function is stated 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?

For a one-parameter membership check with no output schema, the description is nearly complete: it states the action and input format. It falls short of 5 only because it does not specify the return value contract or mention alternatives when users need broader CVE metadata.

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 cve_id parameter already has a description and example in the schema. The tool description adds no separate parameter semantics, 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 uses a specific verb and resource: 'Check if a CVE is in CISA Known Exploited Vulnerabilities catalog.' This clearly distinguishes it from sibling CVE/advisory lookups such as nvd_cve_lookup and cisa_search_advisories, despite not naming them.

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

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

The intended use case (verify KEV membership for a CVE) is clear, but the description provides no guidance on when not to use it or which sibling to prefer for other CVE/advisory lookups. Given several similar-looking CISA/NVD tools in the sibling list, explicit routing would strengthen it.

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

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

With no annotations supplied, the description carries the full burden, and it does add one genuine behavioral trait: 'Cached 1 hour,' which tells the agent how fresh results will be. However, it does not disclose return format, no-result behavior, rate limits, or any access requirements, so the disclosure is partial rather than complete.

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

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

Three short sentences, with the purpose front-loaded in sentence one and usage/behavioral context packed into the final sentence. The second sentence (type filter) mildly duplicates the schema enum, but nothing is wasted and the description remains compact.

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

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

For a low-complexity search tool, the essentials are covered: what is searched, how to filter, and freshness (1-hour cache). But with no output schema and no annotations, the description leaves the return shape and error/empty-result behavior undocumented, which an agent would have to discover at call time.

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%: query, type, and limit each have inline descriptions, so the schema already carries the heavy lifting. The description slightly echoes the query parameter (keyword, CVE, actor, malware family) and the type enum, but adds no new syntax, formatting, or default details beyond the schema — matching the baseline for high coverage.

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

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

The description states a specific verb ('Search'), a clear resource ('CISA cybersecurity advisories and alerts'), and the supported search subjects (keyword, CVE, actor, malware family). It is distinguishable from sibling advisory-search tools like nsa_search_advisories and fbi_flash_search by the CISA attribution, though it never names an alternative explicitly the way a top-tier definition would.

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 claim that 'Advisories from CISA carry the highest confidence for active exploitation' implies this is a good default when actively-exploited vulnerabilities matter, but it is never stated as an explicit when-to-use rule. No exclusions or alternatives (e.g., nsa, cert_eu, ncsc_uk) are mentioned, so an agent must infer routing from the CISA attribute alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully mentions ECS field mappings and support for modifiers, wildcards, and complex conditions, but does not state the output format, error behavior for invalid YAML, or effects of parameters like include_comments and timeframe.

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 concise sentences, each adding distinct value: the conversion target, the mapping approach, and supported features. No repetition or 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?

The description explains the core purpose well, but there is no output schema and no explicit statement of what the tool returns. It also does not describe how the configurable parameters affect the output, leaving moderate gaps for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about ECS mappings and supported syntax, which hints at acceptable sigma_rule input, but it does not provide parameter-specific meaning beyond what the schema already 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 transformation: 'Convert Sigma detection rules to Kibana Query Language (KQL) for Elastic Stack (Kibana, Elasticsearch).' It uses a specific verb and resource, and the direction of conversion is unambiguous, distinguishing it from the sibling convert_yara_to_sigma.

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 implied by the tool name and conversion direction, but the description does not explicitly state when to use this tool versus alternatives such as convert_yara_to_sigma, nor does it give any exclusions. An agent can infer usage, but guidance is 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?

With no annotations, the description carries the full behavioral burden and it largely delivers: it discloses that output is approximate/best-effort, names the mapping strategy, and states the invariant that a manual-review warning is always included. It stops short of describing error behavior for invalid YARA or the exact output format, but the core quality caveat is explicit.

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 no filler; the action, scope, and required warning are each stated once and front-loaded. Every clause earns its place.

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

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

For a moderately complex transformation tool with no output schema, the description conveys purpose, fidelity caveat, and scope but leaves the return format unstated and does not say how unsupported YARA constructs are handled. An agent can likely call it correctly, but it would be guessing about the response shape.

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% — every parameter (yara_rule, product, title_override, logsource_category) already has a description, so the baseline is 3. The description adds mild context by tying the conversion to process_creation/CommandLine, aligning with the logsource_category default, but adds no syntax or formatting detail 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 opens with a specific verb and resource — 'Convert a YARA rule to an approximate Sigma rule' — and immediately distinguishes this conversion direction from the sibling convert_sigma_to_kql. It also bounds the scope by naming supported condition types (string/hex) and the target log source (process_creation CommandLine).

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 present but implied: the 'focused on string/hex conditions' and 'mapped to process_creation (CommandLine)' phrasing tells an agent which YARA rules are suitable, but there is no explicit when-to-use statement, exclusions, or pointer to alternatives such as convert_sigma_to_kql. An agent must infer that non-string/hex rules will convert poorly.

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

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

With no annotations, the description carries the burden and does a solid job: it explains that every technique in the matrix is evaluated, enumerates the four statuses, and frames the tool's purpose as answering what can/cannot be detected and what logs are missing. It could add expected performance/cost or whether it persists anything, but the core behavior is transparent.

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

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

Two sentences, no filler, and front-loaded with the verb and resource. The status taxonomy is presented compactly and the purpose statement earns its place.

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

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

For a single-parameter tool with no output schema, the description gives enough to understand what is computed and the status semantics. It does not explicitly state the return format or side effects, but the per-technique assessment language implies the result shape sufficiently.

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 session_id and states the ingestion prerequisite, so the description adds little parameter-level meaning beyond 'for a session.' Baseline 3 applies because schema coverage is complete.

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 action ('Run a full MITRE ATT&CK coverage assessment for a session') and defines the resource and output categories (COVERED/DETECTABLE/PARTIAL/GAP). It is clear, but it does not explicitly differentiate this from sibling coverage tools like analyze_coverage or coverage_gaps_detail.

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

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

It gives clear context: this is the core engine for answering detectability and log-gap questions, and the schema adds the prerequisite that logs must be ingested first. It does not explicitly say when to prefer alternatives or when not to use it.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states that the tool compares sessions and reports improvement direction along a defined maturity path (GAP→PARTIAL→DETECTABLE→COVERED), which gives an agent a good sense of expected behavior. It does not explicitly state that the operation is read-only, but 'Compare' and 'Shows' strongly imply no mutation.

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

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

Two sentences, no filler, and the primary purpose is front-loaded. The second sentence provides a practical example that adds contextual value without 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?

The tool is simple: two required parameters, no nested objects, no output schema, and no annotations. The description explains what it compares, what it returns, and even gives a representative question it answers, making it sufficiently complete for an agent to invoke correctly.

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

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

The schema already describes both parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantic context by defining session_before as the baseline and session_after as the comparison after adding new log sources, which helps the agent map the parameters correctly to the use case.

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 action—comparing coverage between two assessment sessions—and describes the output (technique improvements and gaps closed). This is distinct from sibling tools like analyze_coverage or identify_gaps, which operate on a single session, and the example use case reinforces its unique 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?

The description gives a concrete scenario ('If I add Sysmon, how much does my coverage improve?') that tells an agent when to use this tool. It does not explicitly mention when not to use it or name alternatives like analyze_coverage, but the two-session comparison framing is clear enough for typical selection.

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

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

With no annotations, the description carries the burden and does state the report contents (GAP/PARTIAL techniques, missing sources, remediation steps) and filterability. However, it does not disclose the default status behavior (all non-COVERED per schema) and the phrase 'every technique that is GAP or PARTIAL' sits slightly awkwardly with that default.

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

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

Three short sentences, front-loaded with the core action and output content, and every sentence earns its place. No fluff or repetition.

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 4-parameter reporting tool with no output schema, the description covers the main output and filtering semantics well. It is slightly incomplete because it omits the prerequisite relationship to coverage_assess_session and does not differentiate from overlapping gap-report siblings, though the schema compensates for the prerequisite.

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 applies; the schema already documents session_id, filters, values, and limit. The description only adds that results are filterable by tactic/status, which mirrors the schema rather than adding new 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 uses a specific verb ('Get'), names the resource ('coverage session'), and defines the deliverable: every GAP or PARTIAL technique with missing data sources and remediation steps. This content and 'detailed' wording distinguish it from summary/top-gap 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 implies use after a coverage session and shows filtering options, but does not state when to prefer it over sibling tools like identify_gaps, get_top_gaps, or coverage_summary, nor give exclusions. The prerequisite is only present in the schema, not the description.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It covers parsing behavior, supported log formats, the structured-input alternative, and automatic session creation when session_id is absent. It is transparent about the core side effects (creating/adding to a session), though it does not detail success/failure semantics or whether existing session data is modified.

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; the first sentence states the purpose, and subsequent sentences add only necessary operational detail. There is no redundant phrasing or 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 no output schema and no annotations, the description provides substantial context: input modes, supported formats, mapping behavior, and session creation. The main gap is that it does not describe what is returned or how success is signaled, but the core invocation requirements are well covered.

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. The description adds meaningful value by enumerating supported parseable formats (Windows Event XML, Sysmon, JSON, auditd, CEF) and clarifying the mutual exclusivity of raw_log vs event_source+event_id, which is only tersely indicated in the schema. This goes beyond the bare schema definitions.

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

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

The description opens with a specific verb and resource: 'Ingest a sample log into a coverage assessment session.' It then clearly states what the tool does with the log—extracts event source, event ID, and fields, and maps to MITRE ATT&CK data sources/components. This distinguishes it from sibling analysis tools like coverage_assess_session and coverage_gaps_detail.

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

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

The usage context is clear: ingest logs into sessions, with optional raw log or structured event_source/event_id input. However, it does not explicitly say when to prefer this tool over related coverage session tools, nor does it state any exclusions or preconditions. Usage is implied rather than directly contrasted with 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?

No annotations exist, so the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, and mentioning session statistics adds some context. However, it does not describe response format details, pagination, or whether the optional filter changes the session statistics 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 concise sentences deliver the core purpose, the output format, and the intended use case with no filler. 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?

For a simple read-only listing tool with one optional filter and no output schema, the description covers what the tool does, what it returns conceptually, and when to use it. Slightly more detail about the session statistics would be beneficial, but overall it 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?

The single parameter has 100% schema description coverage, so the schema already explains 'event_source_filter'. The description reinforces that event sources can be filtered but adds no additional meaning 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 opens with a specific verb and resource: 'List all known telemetry-to-MITRE mappings' and defines the exact output shape '(Event ID → Data Source/Component)'. This clearly differentiates it from sibling tools focused on coverage summaries, gaps, or technique counts.

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 tells the agent when to use it: 'Use to see which event sources/IDs the coverage engine understands.' It does not name alternative tools or state when not to use it, but the use case is clear enough among the many coverage-related 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this well by explaining the analysis logic, ranking criteria, and prioritization by actor usage, plus an illustrative output example. It does not explicitly state that the operation is read-only or describe the exact return format, but 'analyzes' and 'recommendations' strongly imply a non-mutating analysis tool.

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

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

The description is three sentences with no filler. It front-loads the core purpose, then adds the ranking logic, an illustrative answer, and the prioritization rule. Every sentence contributes meaningful information without repeating schema content.

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

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

For a two-parameter tool, the description is largely complete: it explains what the tool does, how it prioritizes, and gives an example of the kind of output it produces. The prerequisite that session_id must come from coverage_assess_session appears only in the schema, not the main description, and there is no output schema, but the example partially compensates for the missing return-shape detail.

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

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

Schema description coverage is 100%, with both session_id and max_recommendations already documented in the input schema. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific, informative phrase: 'Pareto-optimal log source recommendations.' It then explains exactly what the tool does: analyzes coverage gaps, ranks missing data sources by technique gaps closed, and prioritizes by actor usage. This clearly distinguishes it from sibling tools like coverage_gaps_detail or identify_gaps, which focus on listing gaps rather than recommending sources.

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

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

The description implies the use case: after assessing coverage, get ranked recommendations for log sources to enable. The schema also notes that session_id must come from coverage_assess_session. However, the description does not explicitly state when to prefer this tool over siblings like coverage_gaps_detail or get_top_gaps, nor does it provide exclusion criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create' without explaining side effects, duplicate handling, whether existing entities are updated, or whether any validation occurs. An agent cannot know if creating an entity with an existing name fails, overwrites, or creates a duplicate.

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 sentence with no filler. It front-loads the core action ('Create an entity in the knowledge graph') and uses the parenthetical examples efficiently, earning every word.

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 creation tool with a fully documented schema, the description is adequate to make a correct call. However, the absence of annotations and output schema means return values, duplicate behavior, and required relationship to existing entities are not disclosed, leaving some operational context 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 the baseline is met and the schema already documents all five parameters. The description adds examples like 'technique, actor, tool, detection', but these mostly mirror the schema's type enum and do not enrich parameter meaning beyond it.

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

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

The description clearly states a specific verb and resource: 'Create an entity in the knowledge graph', with concrete examples of entity types. It naturally distinguishes itself from sibling tools like create_relation and search_entities, so an agent can tell what this tool does at a glance.

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

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

No explicit guidance about when to use this tool versus alternatives such as create_relation or search_entities. The knowledge graph context and examples imply a use case, but there is no stated condition, prerequisite, or exclusion, leaving the agent to infer when creation 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states that it 'creates' a relation, implying a mutation, but does not mention whether existing relations are overwritten, whether validation occurs, what happens on duplicate relations, or whether this is reversible. For a state-changing tool with zero annotation coverage, this is a notable gap.

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 clear sentence that is concise and front-loads the action and object. It wastes no words, though it could have used the spare space meaningfully to add behavioral or usage 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?

For a mutating tool with no annotations and no output schema, the description is under-specified: it doesn't mention whether the graph becomes immediately persistent, what happens if source/target entities don't exist, how relation_type is constrained, or what the response/return behavior is. Given the mutation risk and the large sibling list, the description should provide more context.

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 structured fields already document all 6 parameters. The description adds no additional semantic meaning beyond what the input schema provides, such as relation_type vocabularies, expected formats, or constraints on source/target IDs. Baseline 3 is appropriate since schema fully covers parameter 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?

States a specific verb ('create') and resource ('relation between two entities in the knowledge graph'). It clearly describes what the tool accomplishes but does not differentiate it from sibling tools like create_entity or search_entities; although the name is fairly descriptive, the description doesn't explicitly contrast with related graph 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 implies its use when the agent needs to establish a relation in the knowledge graph, but it provides no explicit guidance about when to use create_relation versus create_entity or search_entities, nor any conditions or alternatives. The context is clear enough from the resource noun, but there are no stated exclusions 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?

With no annotations present, the description carries the burden of behavioral disclosure, and it does a solid job: it reveals that the tool fetches external CVE data from NVD, maps it to ATT&CK, and produces multi-format detections with additional artifacts. It does not discuss output format beyond formats and components, or side effects, but the described behavior is clearly non-mutating.

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 efficient: the primary purpose is front-loaded, and the subsequent clauses list the process and deliverables without filler. It is slightly long and could be broken into cleaner sentences, but every segment adds useful 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 complex generate-from-CVE tool with no output schema, the description covers the important bases: input, data sources, output formats, and auxiliary content such as false positives and response actions. It doesn't specify the exact response structure or failure modes, but enough is present for an agent to invoke it and interpret the result.

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

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

Schema description coverage is 100%, so the structural baseline applies: the schema already explains cve_id with an example. The description adds no parameter-specific semantics or syntax details, so it neither improves nor harms parameter understanding.

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

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

The description states a specific verb and resource: converts a CVE into SIEM detection logic. It goes beyond a simple lookup by naming the pipeline (NVD fetch, MITRE ATT&CK mapping) and concrete outputs (KQL, Splunk SPL, Sigma), which clearly distinguishes it from sibling tools like nvd_cve_lookup, list_by_cve, and the standalone Yara/Sigma converters.

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 use case is clear: when an agent has a CVE identifier and needs actionable detection content, this is the tool. It doesn't explicitly state exclusions or name alternatives such as nvd_cve_lookup for plain CVE metadata, so it falls just short of explicit 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?

With no annotations, the description carries the burden, and it does state the output behavior: returns a sorted list with risk tiers. It doesn't cover errors, rate limits, or exact tier definitions, but the read-only lookup nature is implied and no contradiction exists.

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 with the main action first and no filler. Every sentence adds useful context about what the tool does, why it matters, and when to use it.

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

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

For a single-parameter lookup with no output schema, the description covers the input, the primary behavior, and the return shape (sorted list with risk tiers). It could add CVE format guidance or tier definitions, but nothing critical is missing for selecting and invoking the tool.

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

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

The schema already fully documents cve_ids and the max of 100; the description adds no parameter-level detail beyond reaffirming multiple CVEs. With 100% 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?

States a specific action ('Batch EPSS score lookup') and target ('multiple CVEs'), and the phrase 'Batch' plus 'multiple' distinguishes it from sibling epss_score_lookup. The purpose of ranking by exploit probability is also clearly conveyed.

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?

Gives concrete use contexts: prioritizing patching and enriching scanner output. It doesn't explicitly state when to prefer epss_score_lookup for a single CVE, but the batch framing makes that boundary 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens for unknown CVEs, the exact return format (e.g., float 0-1 vs percentage), or any rate limits or external API dependencies. The 'FIRST' qualifier hints at behavior but is insufficient for a tool with zero annotation coverage.

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 no fluff. The action is front-loaded, and the EPSS explanation earns its place by clarifying why the score matters. Every word contributes to understanding.

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-only lookup, the description is mostly complete: it names the resource, the input, and the output type ('probability score'). However, with no output schema, it could be more explicit about the return format and error behavior. Still, the tool is simple enough that an agent can likely call it correctly based on this description.

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

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

Schema description coverage is 100%, and the single parameter cve_id is already documented with an example. The description adds contextual meaning about EPSS but does not provide additional parameter syntax or format details beyond what the schema already offers, matching the baseline for high schema coverage.

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

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

The description uses a specific verb ('Get') and resource ('FIRST EPSS probability score for a CVE'), clearly distinguishing it from the sibling epss_bulk_check by emphasizing 'FIRST'. It also explains what EPSS is, leaving no ambiguity about the tool's function.

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 a clear use case ('essential for CVE prioritization beyond raw CVSS scores') but does not explicitly mention when to use this tool versus alternatives like epss_bulk_check or nvd_cve_lookup. No exclusions or alternative routing are provided, so usage 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?

With no annotations, the description carries the full behavioral burden. It usefully reveals that results are recent submissions and that the tool automatically extracts TTPs, CVEs, and IOC markers. However, it does not disclose output structure, time-window semantics, pagination, or any access limitations.

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, with the core action and resource in the first sentence and the value-added extraction behavior in the second. No filler or repetition of schema fields.

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

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

The tool is simple, with two fully documented parameters, so the core call is understandable. However, without an output schema, the description only partially explains what the agent will receive, and it lacks any usage-or-alternative context amid the large sibling set.

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 query and limit are already documented. The description restates that queries can be keywords or CVEs and adds the 'recent submissions' nuance, but it does not add meaningful detail about limit behavior or query formatting 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 names a specific resource (Exploit-DB), a specific action (search), and the input focus (keyword or CVE). It also adds extraction behavior (MITRE TTPs, CVEs, IOC markers) that sets expectations beyond a simple search. This clearly differentiates it from sibling threat-intel search tools by source and 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?

No guidance is given about when to choose this tool over the many sibling search tools such as nvd_cve_lookup, malpedia_search, or otx_search_actor. The description implies use when Exploit-DB data is desired, but it does not state exclusions, alternatives, or typical scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond basic search semantics by stating the feed is cached for 1 hour and that the tool extracts MITRE techniques, CVEs, and attributed actors. This is useful operational context even though it does not detail rate limits or output shape.

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

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

The description is three tight sentences with no filler. The main purpose is front-loaded, followed by source clarification, extraction behavior, and caching. Every sentence adds value and the total length is proportionate to the tool's simplicity.

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

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

For a two-parameter search tool with fully documented schema and a clear source attribution, the description covers the important operational details: what is searched, what is extracted, and caching behavior. It does not describe result format, but no output schema exists and the description's extraction note partially compensates.

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 query and limit. The description reinforces the query parameter by listing example search categories (actor, CVE, malware family, topic), but it does not add meaning beyond what the schema provides. 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 uses a specific verb ('Search') and resource ('FBI / IC3 RSS feed'), and specifies the searchable entities (keyword, CVE, actor name, malware family). This clearly differentiates it from sibling tools like anssi_search, cisa_search_advisories, or jpcert_search by naming the exact data source.

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 makes clear this tool is for FBI flash alerts and IC3 public service announcements, which tells an agent when to pick it over other threat-feed searches. It does not explicitly state 'use X instead when...', but the source attribution provides strong contextual guidance.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It does so well by stating that it saves to a specific desktop path, creates the output folder automatically if missing, and returns the full output file path on success. It does not mention overwrite behavior or error conditions, but the main write side effects and return behavior are transparently 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?

The description is front-loaded with the core action and then provides the output path, file-creation behavior, and return value in a logical order. The enumeration of required card fields is somewhat redundant with the schema, but it is compactly presented and helps an agent assemble valid input without parsing the full nested schema.

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

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

Given the tool's complexity and rich input schema, the description covers the essentials: what the tool generates, where it saves, folder auto-creation, key input structure, and the success return value. It does not explain formatting details, overwrite behavior, or error handling, but for invocational purposes the provided information is sufficient alongside the detailed 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%, so the baseline is 3. The description mostly restates what the schema already encodes, such as required top-level fields and card-level requirements. It adds minor context like 'one per technique' and 'query (Sigma YAML)', but these are already present in or implied by the schema, so the parameter semantics are adequate but not enhanced.

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

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

The description starts with a specific verb and resource: 'Generates a formatted Word document (.docx) threat hunt report from structured hunt card data.' It clearly distinguishes this tool from the many sibling search/lookup tools by being the only one focused on report generation. It also states the output file path and return value, leaving no doubt about what the tool accomplishes.

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 context is clear: this tool is for producing a Word report from structured hunt card data, and it explicitly lists required input ('report metadata and an array of hunt cards'). It does not explicitly name alternatives or state when not to use it, but among the sibling tools, none competes with this generation function, so the usage context is reasonably unambiguous.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful behavioral context: the response is a compact object of roughly 200 bytes and the tool is faster/smaller than analyze_coverage, implying a read-only summary operation. It does not detail error behavior or exact output keys, but for a simple read-only summary this is reasonably transparent.

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 short, purposeful sentences with no filler. It front-loads what the tool does, then adds size/performance characteristics and a usage recommendation. Every sentence earns its place.

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

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

This is a low-complexity tool with one optional parameter and no output schema or annotations. The description sufficiently conveys purpose, output size, and when to use it. However, because no output schema exists and the description only says 'compact object (~200 bytes)', the exact response shape is left somewhat approximate.

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 source_type property is already documented with its allowed values (sigma, splunk_escu, elastic, kql). The description does not add any extra parameter semantics, so the baseline score of 3 applies.

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

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

The description opens with a specific verb and resource: 'Get tactic-level detection counts as a compact object'. It clearly scopes the tool to tactic-level summary counts and explicitly contrasts it with analyze_coverage as a faster/smaller alternative, making it easy to distinguish.

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 names analyze_coverage as a sibling alternative and positions this tool as the quick-orientation option: 'Use for quick orientation before deeper analysis.' This implies when to choose it, though it does not explicitly spell out when-not-to-use it or what conditions should trigger analyze_coverage 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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-style operation that returns data sources and log types for a technique, but it does not disclose output shape, empty-result behavior, or sub-technique handling. These are minor gaps for a simple lookup, but the description is still somewhat minimal.

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 short sentences with no filler. The action and resource are front-loaded, and the second sentence adds a concrete example question that reinforces the tool's 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?

With a single well-documented parameter and no output schema, the description gives enough information for an agent to call the tool correctly. It could mention return formatting or invalid-ID behavior, but for a simple lookup these are not critical gaps.

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

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

Schema description coverage is 100%, and the parameter description already includes the format and examples ('T1021', 'T1059.001'). The tool description only repeats the T1021 example and adds no additional semantic meaning beyond what the schema provides.

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

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

The description uses a specific verb ('Get') and a specific resource ('required data sources and log types') tied to a MITRE technique, and the example question 'What logs do I need for T1021?' makes the intent concrete. It does not explicitly name sibling tools like list_data_sources or lookup_mitre_technique, but the scope is clear enough to avoid obvious confusion.

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

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

The description provides a clear use case: answering what logs are needed for a given MITRE technique. It does not state when not to use this tool or name alternatives, but the example question gives sufficient context for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only mentions recency and logging status; it does not explain ordering, pagination, search behavior, or whether this is a read-only operation beyond the verb 'Get'.

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

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

The description is a single, front-loaded sentence with no filler. The parenthetical '(tribal knowledge)' adds useful context without extra 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?

For a simple read tool with zero required parameters and full schema coverage, the core purpose is conveyed. However, with no annotations and no output schema, the description leaves ambiguity about what constitutes a 'decision' and how results are ordered or filtered.

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

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

The input schema covers both parameters at 100%, including the default limit of 20 and optional search. The description adds no parameter-level semantics, but the schema is sufficient, 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?

The description uses a specific verb ('Get') and resource ('recent logged decisions'), with the parenthetical 'tribal knowledge' clarifying the content type. It distinguishes itself from generic get_* tools, though it does not explicitly differentiate from similar siblings like get_learnings.

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 'recent logged decisions' implies when to use the tool, but there is no explicit guidance about alternatives or exclusions. With siblings like get_learnings and log_decision nearby, an agent could benefit from clearer routing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly signals a read-only lookup ('Get', 'Returns') and spells out the exact data returned, so an agent knows what to expect. It does not cover error/not-found behavior, but for a simple getter this is a minor omission rather than a transparency failure.

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

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

Two sentences, no filler. The first sentence names the operation and resource, the second lists the useful return fields and a concrete use case. Every clause earns its place.

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

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

For a one-parameter getter with no output schema and no annotations, the description is nearly complete: it names the input, the output fields, and a use case. Minor omissions such as invalid-ID behavior or output formatting are low-impact for this tool, but would have made it fully complete.

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

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

Schema coverage is 100% and the only parameter, id, is described as 'Detection ID'. The description reinforces that this ID selects a specific detection but adds no additional format, source, or validation semantics beyond the schema, so it meets the baseline but not more.

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 full details of a specific detection by ID') and enumerates the returned fields. This makes it clearly distinct from search_detections and the list_by_* siblings, which are about finding detections rather than retrieving a single detection's full record.

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 a concrete trigger for use: 'Use this to extract detection conditions for kill-chain correlation.' This is clearer than no guidance, but it does not explicitly state when not to use it or name alternatives such as search_detections, so it stops 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core function and does not mention return format, exact-match requirements, sub-technique handling, or behavior for unknown technique IDs.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to conveying the tool's 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 simple one-parameter read tool, the schema covers the input well and the description states the core purpose. However, with no output schema, the description does not clarify the return shape or edge-case behavior, leaving some ambiguity for an agent.

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

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

The input schema already fully documents the single parameter technique_id with format and examples, giving 100% schema coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Find all threat groups') and the resource ('MITRE technique'), making the tool's purpose easy to grasp. It is implicitly distinguished from siblings like get_software_using_technique by focusing on threat groups, but it does not explicitly name or contrast any sibling.

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

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

The description gives no guidance about when to use this tool versus alternatives such as search_threat_groups, lookup_mitre_technique, or get_software_using_technique. There are no exclusions, prerequisites, or context cues beyond the basic purpose.

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

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

No annotations are provided, so the description carries the burden of behavior. The verb 'get' implies a read-only operation, and the tool has no parameters, so invocation risk is low. However, the description does not disclose what the summary contains, how it is computed, or any limitations.

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 clear sentence with no filler. It is front-loaded and appropriately sized for a parameterless tool.

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

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

For a zero-parameter tool with no output schema, the description gives the essential purpose and enough distinctiveness from siblings. It could say a bit more about what 'summary of the knowledge graph contents' means, but nothing critical is missing for invoking the tool correctly.

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

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

The tool has zero parameters, so the input schema is trivially complete. Description-level parameter explanation is unnecessary, and the baseline of 4 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 uses a specific verb ('Get') and a clearly identified resource ('knowledge graph contents'). It is distinct from siblings like get_coverage_summary or get_stats because it explicitly targets the knowledge graph, though it does not elaborate on what kind of summary is produced.

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

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

The description gives no guidance on when to prefer this tool over alternatives, nor any indication of context or prerequisites. With dozens of sibling tools, an agent cannot tell whether this is the right choice or when a more specific summary tool should be used.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only retrieval via the verb 'Get' but does not disclose what the output looks like, how results are ordered, whether pagination applies, or whether any side effects or state changes are involved.

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

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

The description is a single, front-loaded sentence with no filler or redundant wording. It communicates the core operation efficiently.

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

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

For a simple two-parameter retrieval tool, the description plus schema is minimally viable for invoking it correctly. However, because there is no output schema and no sibling differentiation, the description leaves some gaps around return values and when to prefer this tool over similar ones.

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 describes both parameters completely (limit and topic), so the description adds little beyond restating that topic acts as a filter. With 100% schema description coverage, 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 states a specific action ('Get') and resource ('learnings/insights') with a filtering criterion ('by topic'). It is clear enough to understand the basic function, though it does not differentiate itself from siblings like add_learning or get_knowledge_summary.

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

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

There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools. The usage is only implied by the phrase 'by topic', leaving the agent to infer 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?

With no annotations provided, the description carries full behavioral burden and does it well: it discloses tiered response sizes in tokens, default behavior, content shape (counts + names, top 15 per source, key fields, everything), and a strong recommendation to avoid 'full.' It does not cover aspects like rate limits or exact response fields, but for a read-oriented context tool this is solid transparency.

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: purpose first, then mode behavior, then a routing rule. Every sentence adds value; there is no filler or repetition of the tool name beyond the first useful sentence.

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

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

For a tool with no annotations and no output schema, the description gives enough to select, invoke, and interpret results: modes, token sizes, default behavior, content differences, and the alternative tool path. An agent can decide summary vs detailed vs full and know what to expect from each.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining mode escalation semantics and that omitting technique_id in summary mode returns a corpus-wide overview. This goes beyond the schema's per-parameter descriptions, making the tool safer and easier to invoke correctly.

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: 'Get LOLFarm intelligence relevant to a MITRE ATT&CK technique.' It clearly differentiates from sibling tools by framing this as a tiered context-gathering tool and noting that deep-dives should go through lookup_* tools instead. An agent can understand what this tool is for and how it differs from search_lolfarm and the per-source lookup tools.

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

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

Usage guidance is explicit per mode: summary for Step 1 recon, detailed when authoring, full only sparingly. It also tells the agent to prefer per-source lookup_* tools for deep-dives instead of escalating mode, which directly addresses the alternative-tool decision an agent must 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic function and does not mention what the response contains, whether it returns structured mitigation data, or any limitations. For a tool with no annotation safety hints, this is a notable gap.

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 short sentences with no filler. The core action is front-loaded, and the example question adds clarity without unnecessary 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 simple one-parameter lookup, the description is mostly sufficient, but because there is no output schema and no annotations, an agent is left without details about the response shape or any behavioral caveats. It is adequate but not fully complete.

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

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

The input schema already fully documents the single parameter, technique_id, with a clear example. The description reinforces that the parameter is a specific technique ID but adds no new semantic detail beyond the schema.

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

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

The description clearly states a specific verb and resource: getting MITRE ATT&CK mitigations for a specific technique. The example question 'How do I mitigate T1059?' reinforces the exact purpose and distinguishes it from sibling tools that handle techniques, groups, software, or data sources.

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 implied: call this when you need mitigations for a specific technique ID. However, there is no explicit guidance about when not to use it or which alternative tools might be better suited for related needs, such as getting detections or data sources.

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

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

With no annotations, the description carries the full burden. 'Get' clearly implies a read-only operation, and 'indexed' usefully scopes the data source. However, it doesn't disclose what form the statistics take, whether they are computed on demand, or any other behavioral nuances beyond the word 'indexed'.

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

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

A single compact sentence with no filler. The action and resource are front-loaded, and the parenthetical examples add useful context without bloating the description.

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 trivially easy to call with no parameters, but since there is no output schema, the description doesn't say what the returned statistics look like. Given several similar sibling statistics tools, an agent could still pick the wrong one without clearer differentiation.

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 schema description coverage is trivially 100%. Per the baseline for a zero-parameter tool, the description appropriately has no need to elaborate on parameters.

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

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

The description uses a specific verb ('Get') and resource ('statistics about the indexed MITRE ATT&CK data') and gives examples of the entities involved. However, it doesn't differentiate from overlapping siblings like get_stats, get_technique_count, and get_coverage_summary, so some ambiguity remains.

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

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

No guidance is given on when to choose this tool over the many sibling statistics tools, such as get_stats, get_technique_count, or get_coverage_summary. The agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Get details' but doesn't disclose what fields are returned, whether the lookup is exact or fuzzy, case sensitivity, or whether a missing name returns null or errors. It's a simple read, but the agent is still left guessing about the 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 two sentences and entirely relevant. It front-loads the core purpose and gives examples without padding. Minor room for improvement in adding usage guidance, but the structure is efficient.

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

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

For a simple single-parameter lookup with no output schema, the description is mostly adequate: it says what the tool does and what input it takes. However, since there is no output schema and no annotations, a bit more context about the response or matching behavior would make it 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 fully documents the 'name' parameter with examples. The description reiterates the same examples (Cobalt Strike, Mimikatz) and adds 'PsExec' via the schema, but doesn't add meaning beyond the schema. 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?

The description states 'Get details about MITRE ATT&CK software (malware or tools) by name' with a specific verb and resource. It names examples (Cobalt Strike, Mimikatz), which adds clarity. It doesn't explicitly differentiate from sibling search_software, but the 'by name' lookup semantics are somewhat implied.

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

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

The description gives no explicit guidance on when to use this tool vs. the many sibling tools like search_software, malpedia_search, or get_software_using_technique. The examples imply a known-name lookup, but there is no stated exclusion or 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?

With no annotations, the description carries the full burden. It clearly implies a read-only search and defines the scope as malware and tools, but it does not disclose return format, handling of unknown technique IDs, or whether results are limited to ATT&CK software entries.

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 sentence with no filler. It front-loads the action and object, and every word contributes to the tool's 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?

This is usable for a one-parameter lookup, but with no output schema and no annotation context, it omits what the returned list contains and how it differs from several nearby MITRE-related siblings. It is minimally complete but not richly contextual.

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 provides 100% coverage for technique_id, including a clear example format. The description adds minimal semantic context ('malware and tools that use a specific MITRE technique') but does not meaningfully expand 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 uses a specific verb ('Find') with a clear resource ('all malware and tools') and a precise subject ('specific MITRE technique'). It distinguishes itself from siblings like get_groups_using_technique at a glance.

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

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

No guidance is provided about when to use this tool versus alternatives such as list_by_mitre, lookup_mitre_technique, or get_groups_using_technique. The intended context is only implied by the name and description.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It discloses that the tool returns aggregated counts by source, severity, and MITRE coverage, which is useful. However, it does not mention whether the result is a single summary object, how the stats are scoped in time, or any freshness/availability 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 a single, front-loaded sentence with no filler. Every word contributes to conveying what the tool returns, and it is appropriately sized for a zero-parameter tool.

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

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

For a zero-parameter, no-output-schema tool, the description is largely complete: it names the resource and the return dimensions. It could have added a note distinguishing it from sibling statistics/coverage tools, but nothing essential to invoking it 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?

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter information 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 names a specific verb and resource: getting statistics about indexed detections, and specifies the main output dimensions (counts by source, severity, MITRE coverage). It is clear, though it does not explicitly differentiate itself from similarly named sibling tools like get_mitre_attack_stats or get_coverage_summary.

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

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

No guidance is given about when to use this tool versus the many related sibling tools such as search_detections, list_by_mitre, list_by_severity, or get_coverage_summary. The description implies it is an aggregate statistics endpoint, but it does not state 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?

With no annotations present, the description carries the transparency burden. It discloses that the tool returns a count, that the response is small (~50 bytes), and that it is fast. It could mention edge-case behavior (e.g., invalid technique IDs or zero-count results), but for a read-only count tool the provided behavioral context is solid.

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 short sentences with no filler. The core purpose is front-loaded, and the usage hint is packed into the second sentence. The inclusion of '~50 bytes' is concise and informative.

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

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

For a simple single-parameter count tool, the description covers the key information: what it does, when to use it, and rough response size. It could be slightly more complete by noting behavior for empty results or invalid IDs, but nothing critical is missing for an agent to call 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 technique_id with an example, and schema coverage is 100%. The description adds only the word 'single,' which does not meaningfully increase parameter understanding beyond the schema.

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

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

The description uses a specific verb ('Get') and a specific resource ('detection rule count for a single MITRE technique ID'), making the tool's function immediately clear. It also distinguishes itself from sibling tools by emphasizing it returns only a count rather than full detection objects.

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 positions the tool as 'a fast pre-check before pulling full detection objects,' giving clear guidance on when to use it. It does not name a specific sibling tool like get_detection, but the intended workflow is 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that results are deduplicated, flat, size-limited (~200 bytes), and contain no full objects. It does not mention empty-result behavior or filter combination semantics, but it gives a clear and honest picture of the operation's output characteristics.

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 tightly packed sentences, front-loaded with the core purpose and return shape, followed by filter options. Every word earns its place; there is no redundancy or 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 simple read-only list tool with three optional documented filters, the description covers what is returned, the output's shape and size, and the available narrowing options. It could add a sentence on whether filters combine and what happens with no filters, but these are minor gaps given the tool's simplicity.

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

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

Schema description coverage is 100%, and the description simply restates that the three parameters exist as filters. It adds the phrase 'to narrow scope,' but no additional meaning beyond what the schema already provides for tactic, severity, and source_type.

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

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

The description states a specific verb and resource: 'Get a deduplicated flat list of MITRE technique IDs covered by detection rules.' It also explicitly distinguishes its output scope with 'No full objects,' which separates it from sibling tools that return full technique objects or counts.

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 frames the use case: when you need a compact, deduplicated list of technique IDs, optionally narrowed by source_type, tactic, or severity. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It does state what the tool returns (aliases, description, linked techniques) and implies a read-only operation, but it omits error behavior, case sensitivity, sources, or coverage limits. This is adequate but not deeply transparent.

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 compact sentence with no filler. It front-loads the core action, clearly states the resource, and includes the identifier forms and expected return fields, making every word earn its place.

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

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

For a simple one-parameter lookup, the core invocation requirements are covered and the expected output content is specified. However, with no output schema and several close sibling tools, the description does not clarify when to prefer this tool over alternatives or what it deliberately does not return, leaving moderate gaps.

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

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

Schema coverage is 100%, and the schema already documents the 'name' parameter with helpful examples like 'APT29' and 'G0016'. The description only reiterates the 'by name or ID' framing already present in the schema, so it adds no new semantic meaning beyond the baseline.

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

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

The description uses a specific verb ('Get details') and clearly identifies the resource ('MITRE ATT&CK threat group') plus the accepted identifier forms (name or ID) and returned fields. It is clear and specific, but does not explicitly differentiate itself from close siblings like get_threat_profile or search_threat_groups, so it does not earn a 5.

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

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

There is no guidance on when to use this tool versus the many sibling lookup and search tools, and no exclusions or fallback conditions are stated. An agent is left to infer that exact-name/ID retrieval is intended, which is a significant gap in the sibling-rich context.

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