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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-obvious behavior: a synthetic example runs when request is omitted, every intermediate figure is returned, and rights must be externally verified because the tool does not check a licence. That last caveat is exactly the kind of context annotations cannot convey.

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?

Three sentences, each carrying distinct information: what is computed, what happens with no input, and what is required with input. The core identity is front-loaded and nothing is redundant.

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 explanation is not needed despite the "every intermediate figure" claim. However, for a tool whose request object holds up to 100,000 trades with roughly twenty jargon-heavy fields, the description leaves an agent without guidance on constructing the payload — the biggest remaining gap for a calculation of this complexity.

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 0%, and the description only explains the two top-level parameters: request present vs. omitted, and rights_confirmed=true when supplying data. The large nested request payload (asset_class, nica, mpor_business_days, hedging_set, shift, option, rating, etc.) gets no semantic explanation at all, leaving domain-specific fields to be inferred from terse names.

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?

States a specific verb+resource: Basel SA-CCR exposure at default for a single netting set, with the CRE52 reference pinning the exact regulatory calculation. It is clearly distinguishable from generic exposure tools by the SA-CCR/CRE52 framing, though no sibling tool is named explicitly.

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?

"Omit the request to run the shipped synthetic example instead" gives an explicit condition for the no-argument path, and the permission/rights_confirmed rule gives a precondition for the data-supplied path. It stops short of naming alternative tools for related exposure measures, so it is strong but not fully routing-aware.

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