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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: it 'performs a bounded internal fan-out, has no destructive side effects, and preserves partial results if one required internal call fails.' It also reveals that the tool 'server-enforces the complete morning brief call plan' with fixed limits, and that output_mode is restricted to compact. This discloses failure tolerance and internal argument ownership not visible in annotations.

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

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

The description is dense but well-structured: a purpose sentence, a parameter/behavior sentence, and a usage sentence. Every sentence carries essential information without fluff. It is slightly long but appropriate for a composite workflow that needs to explain its internal composition and constraints. The front-loaded first sentence immediately establishes purpose.

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

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

An output schema exists, so return value details are covered elsewhere. The description covers the tool's composite nature, fixed internal call plan, exact limits, parameter restrictions, failure behavior (partial result preservation), read-only/idempotent nature, and explicit use cases. It also distinguishes this tool from deep-dive alternatives. For a complex composite tool, this is a complete and self-sufficient 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 coverage is 100% for the single output_mode parameter, so the baseline is 3. The description adds meaning beyond the schema by specifying 'optional output_mode=compact only' and explicitly forbidding 'limit, offset, ticker, source_date, or issuer filters' because 'this preset owns exact arguments internally.' This helps the agent understand not just the schema's allowed properties but also the intended usage constraints.

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+resource+scope: 'use this read-only composite workflow tool as the default first-pass DeltaSignal ATLAS-7 daily scan.' It explicitly enumerates the internal calls (readiness, daily_changes, risk_distribution, top_stressed, alpha_opportunities, alpha_opportunities_audit) and distinguishes itself from sibling deep-dive tools by saying 'sell company-report or deep-brief issuer reports separately.' This leaves no ambiguity about 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 explicit when-to-use: 'Use it for morning brief, daily brief, daily scan, current risk board, and newsroom first-pass requests.' It also tells when not to use it: 'sell company-report or deep-brief issuer reports separately when the user wants drilldown explanation.' It further warns against passing parameters like limit, offset, ticker, source_date, or issuer filters, clearly stating the preset owns arguments internally.

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