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

Annotations already establish the read-only, idempotent, non-destructive safety profile, so the description's job is to add operational behavior — which it does abundantly: non-OPERATIONAL places are filtered out unless includeClosed=true, observations are returned 'newest first, each with the source that reported it,' and data_as_of is null when unsupported. Provenance notes ('as accessed on', dated source citations) further characterize the data. Nothing contradicts the annotations.

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?

The essential call pattern is front-loaded in the first clause, and nearly every parenthetical earns its place ('business phones are public', 'Google listing fetch date when supported; otherwise null'). However, the return-field enumeration is a single dense run-on paragraph that would be significantly easier to parse as grouped bullets; its length is justified only because there is no output schema.

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 full burden of explaining the return value, and it does so exhaustively — field by field, covering ordering, provenance, null semantics, and the OPERATIONAL filtering rule. Remaining gaps: no behavior specified for not-found lookups, no explicit statement that slug takes precedence over name+city, and the exact inputs required for the name+city path (both together?) are only implied.

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 75%, and the description compensates for exactly the one uncovered parameter: includeClosed has only a type/default in the schema, while the description explains its effect on the OPERATIONAL filter. It also adds the slug semantics (tail of the ranked.ng/place URL) beyond the schema's example. For name and city it mostly restates the schema's pairing constraint, adding little new meaning.

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 opens by defining the resource precisely — 'One business listing from the production database, by slug... or by name + city' — and the field enumeration confirms a single-record lookup. It differentiates itself from plural/aggregate siblings (ranked_rankings, ranked_stats, ranked_hubs), but it never explicitly distinguishes itself from the closest sibling, ranked_find_business, so that contrast must be inferred rather than stated.

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 implied by the access pattern: an agent should call this when it already has a slug (the tail of a ranked.ng/place URL) or a name+city pair. The description also gives the conditional for includeClosed (non-OPERATIONAL places are excluded unless true). However, there is no explicit when-not-to-use guidance, no routing to ranked_find_business or ranked_rankings, and no statement about which lookup key takes precedence when both are supplied.

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