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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral context: rate limits (30/hr free, 500/hr Pro), 404 behavior when the id is not found, sub-technique inherited_tactics flag, maturity levels, and ATT&CK bridging behavior. No contradiction with annotations. This goes well beyond the basic safety hints.

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

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

The description is longer than strictly necessary, but it is front-loaded with the primary purpose and each sentence contributes distinct value (ATLAS explanation, ATT&CK bridge, inheritance, usage guidance, errors, rate limits, output fields). Minor redundancy exists (e.g., listing example attack types is not essential), but the structure is logical and readable. Slightly verbose, so 4.

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 a rich output schema, the description is exceptionally complete. It covers what the tool does, when to use it, alternatives, error behavior, rate limits, inherited sub-technique behavior, and the full return field list. There are no significant gaps in context needed for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100% with technique_id format and examples fully documented in the input schema. The description does not add parameter-specific meaning beyond the schema, though it does reinforce the context (e.g., 'AML.T0051' LLM Prompt Injection). Baseline 3 is appropriate since the schema already handles parameter semantics.

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

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

The description opens with a specific verb+resource: 'Look up a MITRE ATLAS technique.' It distinguishes from siblings by explicitly naming bulk_atlas_technique_lookup for multiple techniques and describing ATLAS as the AI/ML adversarial attack catalog with examples like prompt injection and model evasion. This makes the tool's purpose unmistakable and distinct from related lookup/search 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 gives explicit when-to-use guidance: 'Use this tool when the user asks about AI/ML threats, LLM red-teaming, or adversarial ML.' It also names an alternative for multiple techniques: 'for multiple techniques in one call... prefer bulk_atlas_technique_lookup.' Additionally, it suggests pivoting to d3fend_defense_for_attack and CVE search via attack_reference_id, providing clear context for related follow-ups.

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