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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond them: the fixed 90-day lookback window and the crucial note that a null citation rate means unmeasured rather than zero, which prevents a serious misreading of results.

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 short sentences, front-loaded with the scope, then the null-value caveat, then the slug pointer. Every sentence carries information; the phrasing is slightly terse ('Recorded 90-day...') but not wasteful.

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 two-parameter read-only lookup with no output schema, the definition covers scope, the time window, and one important return-value caveat, which is more than most. It stops short of describing the overall response shape, but the essential calling information is present.

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% and the schema already gives slug patterns plus examples, so the baseline would be 3. The description adds value at the parameter level by explaining that metro and service take slugs obtained from list_local_markets, and by noting service is optional.

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 states a specific resource and scope: 90-day AI recommendation data for local firms within a metro, optionally narrowed to one service. That is enough to distinguish it from list_local_markets, which is named, though the boundary with get_local_factsheet and get_confirmed_entity is left unstated.

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?

It explicitly routes slug discovery to list_local_markets for valid slugs, which is a concrete precondition. It does not explain when to prefer this tool over the other local-data siblings, so the alternative-selection guidance is partial.

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