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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real context beyond them — the FFIEC Call Report schedules (RC-B, RC-C, RC-E memoranda) that source the data, inclusion of MDRM codes per line for lineage, and explicit units ($000s for dollars, percentages for ratios). It still doesn't say whether a single cycle window or historical periods are returned, but the added behavioral context is meaningful.

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?

Content is front-loaded: the primary payload (buckets, gap, cumulative gap, asset share, deposit betas) comes first, followed by source attribution and then units. Every clause earns its place — the MDRM and source notes support data lineage, and the unit sentence prevents thousand-vs-million misreads.

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 no output schema, the description carries the burden of explaining returns, and it does: four buckets, gap, cumulative gap, share of total assets, deposit betas across the last hiking and easing cycles, and per-line MDRM codes. What remains unstated is the bucket boundary definitions and whether multiple periods or a single snapshot are returned — minor but real gaps for an analyst 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?

There is a single required parameter, rssd_id, fully documented in the schema (100% coverage) as a Federal Reserve RSSD id with an example. The description contributes nothing about it — no format hints, no error behavior for unknown ids. With the schema doing all the work, the baseline 3 applies.

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 concrete analytical resource: repricing/maturity buckets for securities and loans against time deposits, plus gap, cumulative gap, asset share, and deposit betas. That is far more specific than the title alone and lets an agent recognize the tool's output. It does not, however, contrast itself with siblings such as rates_deposit or rate_environment, leaving that differentiation to inference.

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?

Usage is only implied: an agent can infer this is the tool for repricing gap and deposit beta analysis from the content it returns. There is no explicit statement of when to prefer it over related rate/deposit tools, no prerequisites, and no exclusions. Adequate but with a clear guidance gap.

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