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 that the tool is '@slow' and spans multiple domains, but does not explicitly state that it is read-only, which data sources it queries, or any side effects. The output schema covers return structure, but the behavior beyond speed is somewhat opaque.

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

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

The description is concise and front-loaded with the core purpose and a performance warning ('@slow'). The 'USE WHEN' list is directly relevant and adds no fluff. Every sentence and 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?

Given the tool's complexity (26 parameters) and the absence of annotations, the description is relatively sparse. It provides high-level usage scenarios but does not explain parameter interactions (e.g., asset_id skipping broad queries), how results are aggregated across domains, or how to interpret the output. The rich schema and output schema help compensate, but the description alone leaves gaps for such a feature-rich tool.

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

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

Schema coverage is 100%, so parameter descriptions exist. The tool description adds value by mapping natural language to specific parameters, e.g., 'cloud risk in AWS' implies provider='aws' and scope='cloud', and 'container vulnerabilities' implies scope='containers'. This semantic mapping goes beyond the schema's literal field descriptions.

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

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

The description states a clear, specific purpose: cross-domain risk assessment across VMs, cloud, containers, web apps, certificates, and assets. The 'USE WHEN' examples further specify intent ('what's our risk?', 'show me cloud risk in AWS'). This distinguishes it from siblings like security_overview by emphasizing the cross-domain aggregation.

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 'USE WHEN' section with concrete example queries, giving clear context for when to invoke the tool. It does not explicitly mention alternative tools or when not to use it, so it falls short of a 5, but the examples are strong enough to effectively 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?

With no annotations provided, the description carries the behavioral burden. It implies a read-only operation via 'list and health status' but does not describe return details, pagination, or potential rate limiting. This is acceptable for a simple list tool but leaves some behavioral aspects unspecified.

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 concise sentence followed by a 'USE WHEN' list, with no redundant wording. It front-loads the core purpose and provides immediately useful trigger phrases.

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 presence of an output schema and fully described parameters means the description only needs to convey purpose and usage context, which it does effectively. The sibling tool list adds context, and the tool is simple enough that no more behavioral detail is required.

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

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

The input schema fully documents both parameters with descriptions: 'limit' (max connectors, default 50) and 'detail' (summary/standard/detailed). The tool description adds no additional parameter-level meaning, so it relies on the schema's 100% 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 clearly states the tool 'list and health status for multi-account AWS setups,' with a specific verb and resource. It distinguishes itself from sibling tools like cache_status or investigate by focusing on AWS Organization connectors.

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?

A 'USE WHEN' section provides explicit trigger phrases like 'show AWS org connectors' and 'AWS Organizations status', giving clear context for when to use this tool. It does not explicitly mention when not to use it or name alternatives, but the sibling list and distinct purpose make the usage context 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?

No annotations are provided, so the description carries the full burden. It states the two modes (show stats/clear caches) but does not disclose side effects of clearing caches, such as performance impact, irreversibility, or potential disruption to other users.

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

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

The description is a single, front-loaded sentence with no wasted words. The '[Admin]' tag gives immediate context, and all information is relevant and efficiently presented.

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 simplicity of the tool (one boolean parameter and an output schema), the description is minimal but adequate for basic usage. However, the lack of any warning or context around the destructive 'clear' operation, combined with no annotations, leaves the description incomplete for safe usage.

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

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

Schema coverage is 100%, and the parameter description already explains the 'clear' flag. The tool description essentially restates the parameter behavior without adding additional meaning, so it meets the baseline but doesn't exceed 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 the tool displays cache statistics or clears all caches. The '[Admin]' prefix and verbs 'Show'/'clear' specify the action and resource, making it distinct from sibling security/risk 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?

No explicit guidance on when to use this tool versus alternatives. The '[Admin]' prefix implies administrative context, but there is no mention of prerequisites, exclusions, or when clearing vs. showing 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?

Without annotations, the description carries the burden for behavioral disclosure. It notes '@slow' as a performance characteristic but does not mention other behavioral aspects such as how data is fetched, whether it provides real-time or cached data, or any permission requirements. The output schema may cover return format, but the description itself offers limited behavioral insight.

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

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

The description is concise, uses a clear structure with a summary line and a 'USE WHEN' section, and every sentence adds value. It front-loads the core purpose without unnecessary elaboration.

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 (10 optional parameters) and the presence of an output schema, the description covers the main purpose and usage scenarios effectively. However, it omits guidance on how parameters interact (e.g., whether framework and platform are mutually exclusive), and the '@slow' hint could imply performance constraints without elaboration. Still, it is largely complete for an agent to decide when to invoke 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 parameters are fully documented in the schema. The description does not add further detail beyond the schema; it only lists examples of user intents. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function as a compliance posture assessment and lists specific outputs (framework pass/fail rates, failing controls, risk acceptances). It distinguishes from sibling tools by focusing on compliance frameworks and providing example queries in the USE WHEN section.

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 WHEN section provides explicit example queries covering common use cases (PCI compliance, compliance gaps, failing controls, risk acceptances, HIPAA, CIS, frameworks). However, it does not explicitly state situations where alternative tools (e.g., assess_risk, security_overview) should be preferred instead, so it falls short of 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?

With no annotations, the description must convey behavioral traits on its own. It includes '@slow' as a warning about latency and mentions 'deep-dive', implying heavy processing. However, it does not disclose whether the tool is read-only, the data sources accessed, or any rate limits, leaving behavioral transparency 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?

The description is exceptionally concise: a one-sentence summary followed by a short list of example queries. It is front-loaded with the core purpose, and every element—including the '@slow' note and examples—earns its place without 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?

Given the tool's complexity (12 parameters) and the existence of an output schema, the description is fairly complete. It clearly explains the tool's scope, provides realistic usage examples, and flags latency. It lacks any mention of edge cases or limitations beyond slowness, but the detailed schema and output schema compensate for most gaps, meriting a 4.

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

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

Schema coverage is 100%, with all 12 parameters already having detailed descriptions in the input schema. The tool description itself adds no additional parameter semantics beyond the schema, 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?

Description clearly states a specific verb ('Deep-dive investigation') and resource ('any security topic'), listing concrete examples like CVEs, threat actors, assets, and endpoint events. It also includes example queries that distinguish it from sibling tools (e.g., 'assess_risk', 'reports') by emphasizing broad investigation over focused assessment or reporting.

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 WHEN' section provides explicit example queries for when to invoke the tool, such as 'tell me about CVE-2024-3400' and 'are we exposed to Lazarus Group?'. This gives clear context on suitable scenarios, though it does not mention alternatives or when not to use it, preventing a score of 5.

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

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

The description notes '@slow', giving a performance warning. Without annotations, it doesn't explicitly state whether the tool is read-only or whether it modifies anything; the word 'planning' implies non-destructive but this is not explicit. Thus partial 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 with a clear summary, followed by usage examples. All content is useful and no redundancy.

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

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

With an output schema present and full parameter descriptions, the description's use cases and scope notes make it complete for most planning queries. Missing explicit information about limitations or interactions between parameters, but overall sufficient.

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

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

Schema covers 100% of parameters with descriptions, so baseline is 3. The description provides no additional parameter-specific semantics beyond the schema, so it stays at 3.

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

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

The description clearly states its role: 'Remediation planning — patch priorities, deployment status, mitigation coverage, program gaps.' This is a specific verb+resource and differentiates it from sibling tools like investigate or assess_risk by focusing on remediation planning.

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

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

Provides an explicit 'USE WHEN' list with natural language queries, making it clear when to invoke this tool. However, it doesn't mention alternatives or when not to use it, 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only lists actions without explaining side effects, permissions, rate limits, or what happens after execution. This is a significant gap for a multi-action 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 brief and front-loaded with a '[Reporting]' tag, but it's terse to the point of omitting necessary context for a tool with 7 parameters and 6 actions. It's concise but under-specified.

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

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

Given the tool's complexity (multiple actions, 7 params), the description fails to provide enough contextual information. The schema covers parameter details well, but the description doesn't explain the purpose of each action, usage sequence, or operational dependencies. Output schema may cover return values, but operational context is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond repeating the action list, which is already fully described in the schema's action 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 identifies the tool as handling report operations and enumerates the supported actions (list, templates, generate, status, download, delete). This clearly distinguishes it from the security-focused sibling tools. However, it doesn't elaborate on what each action does, so it's clear but not fully detailed.

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 for any report-related task by listing the available actions, but it doesn't explicitly state when to prefer this tool over alternatives or when to use each action. No exclusions or alternative references are provided.

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

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

Since no annotations are provided, the description carries the full burden. It discloses the performance trade-off ('@slow when quick=False') and the general content of the briefing (scanner health, findings, risk trends), but it does not explicitly state that the tool is read-only, nor does it mention authentication requirements, rate limits, or other side effects. This is moderate disclosure but leaves gaps.

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

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

The description is concise and well-structured, opening with a clear title and purpose, followed by a compact definition of the summary content, and then a focused list of usage examples. There is no redundancy; every sentence adds value.

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

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

Given the complexity of the tool (10 parameters, output schema), the description provides a high-level purpose and usage triggers, which is sufficient for an agent to decide when to invoke it. It does not repeat parameters that are fully documented in the schema, and the output schema covers return values. It could mention the configurable periods explicitly (daily/weekly/monthly) but these are inferred from the description and schema.

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

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

The input schema has 100% description coverage for all 10 parameters, so the baseline is 3. The description does not add additional meaning beyond the schema, only referencing 'quick' indirectly through the performance note. All parameter details are already fully documented in the schema.

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

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

The description clearly states the tool's function as a 'Security briefing' that provides daily/weekly/monthly summaries of scanner health, findings, and risk trends. The 'USE WHEN' examples ('morning briefing', 'security overview', 'scanner status') distinguish it from sibling tools like investigate or reports, which focus on deeper analysis or custom reporting.

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 usage scenarios with 'USE WHEN' trigger phrases, signaling appropriate contexts such as morning briefings and weekly retrospectives. However, it does not state when not to use the tool or explicitly mention alternative sibling tools, so it offers clear context but lacks exclusions.

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