Explain Sizing

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the exact decision chain applied (notional cap, gap halving above 1.2x ATR, weekend gross headroom) and that it surfaces house floors plus any deviation when overrides are supplied. It stops short of stating deterministic/purity guarantees or how overrides are keyed.

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, zero filler, with the core identity (mirror of the live C# risk engine sizing) front-loaded and the override/deviation behavior appended. The step list doubles as mechanism description rather than padding, though the run-on enumeration is 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?

With an output schema present, return-value explanation is not required, and the description covers the algorithm stages plus floor/override reporting for a 7-parameter financial calculator. Remaining gaps are minor: no statement of units, determinism, or that inputs must match the live engine's configuration to reproduce a size.

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 3 is the baseline; the description goes beyond the schema by linking mechanics to parameters — overnight_gap to 'overnight-gap halving', weekend_approaching/gross_exposure to weekend gross headroom, floor_overrides to house-floor deviation reporting. That causal linkage is real meaning the schema alone does not convey.

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 (explain/mirror) and resource (the live sizing algorithm) and enumerates exactly which computations it reproduces: ATR sizing, position-notional cap, overnight-gap halving, weekend gross headroom. This is unmistakably distinct from siblings such as validate_order, cost_check, or plan_rebalance, which compute or check rather than explain.

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 framing as a 'step-by-step mirror of the live C# risk engine' implies this is the tool to call when you want to understand or justify a size calculation, and the mention of reporting deviations with per-fund overrides implies a diagnostic use case. However, it never states when to use this versus a sibling like validate_order, nor does it name any alternative or exclusion.

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