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

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context: three internal HTTPS reads, no issuer-level tool calls, no destructive side effects, and preservation of partial results if one internal call fails. This goes well beyond the annotations and gives the agent a clear runtime model.

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 well-structured and front-loaded: purpose, call plan, parameter constraint, behavioral guarantees, and usage triggers all appear in a logical, compact sequence. Every sentence contributes meaningful information without fluff or repetition of structured 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?

For a composite workflow with one optional parameter and an output schema present, the description is complete. It explains the underlying internal calls, parameter restrictions, behavioral guarantees, and usage triggers, leaving no significant ambiguity about when or how to invoke 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 covers the single parameter output_mode with 100% coverage, setting a baseline of 3. The description adds extra semantics by specifying 'only compact is accepted' and explicitly listing parameters that must NOT be passed (limit, offset, ticker, source_date, issuer filters), which helps the agent avoid invalid usage beyond the schema's additionalProperties:false.

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: a read-only composite workflow for risk and stress monitoring across the DeltaSignal issuer universe. It explicitly names the server-enforced call plan (readiness, top_stressed with limit 15, risk_distribution), which precisely distinguishes it from siblings like atlas7_pressure_board or deltasignal_top_stressed.

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 it when the user asks for risk monitoring, pressure board, stress board, top stressed overview, or current risk mix.' It also provides strong exclusions, warning not to pass limit, offset, ticker, source_date, or issuer filters because the preset owns its arguments internally.

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