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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. On top of that, the description discloses the data-integrity contract: only DCPI market-health has a temporal series, static dimensions are declared static, and coverage:unavailable is returned when no snapshot history exists. This goes well beyond what annotations express.

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?

Front-loaded with the trigger, then return shape, integrity notes, params, and alternatives in logical order. The INTEGRITY paragraph is lengthy but earns its place given the tool exists to prevent fabricated deltas. The 'Returns {...}' line is somewhat redundant since an output schema exists, and the all-caps emphasis is noisy — minor deductions.

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 tool with three-plus complex behaviors (temporal delta semantics, integrity constraints across static dimensions, input alternatives, and an output schema), everything an agent needs is present: when to call, what it returns, what happens on missing data, and where to route point-in-time questions. No critical guidance is missing.

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%, so baseline is 3. The description adds value by making the mutual-exclusion relationship explicit ('facility_id OR market') and glossing the since format and default — a relationship not encoded in the schema's per-parameter docs, which treat each parameter independently. Minor deduction because most parameter detail is already in the schema.

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?

Uses a specific verb-resource pair (get/return facility risk delta), distinguishes the temporal ask from static prediction, quotes two natural-language triggers, and directly contrasts itself with three sibling tools (get_composite_site_score, get_disaster_risk, get_climate_intel). It is unambiguous what this tool computes and how to tell it apart from alternatives.

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?

Opens with an explicit 'Use when a user asks what has CHANGED' trigger and example queries, then closes with an explicit when-not-to-use statement pointing to sibling tools for point-in-time risk. It even warns against misuse by stating the static dimensions 'never' get a fabricated delta. No gap in routing exists.

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