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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds substantive non-obvious behavior beyond that: results carry a computed `next` affordance block containing the sub-resources that exist for this entity and the exact tool call that retrieves each, plus the ranked/top-sample semantics and the include_next=false way to disable it. This is richer behavioral disclosure than simply echoing the annotation. It stops short of 5 because it doesn't address failure modes (e.g., unknown slug) or pagination of the sample.

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 with zero filler. The core scope is front-loaded in the first sentence, the alternative routing sits in the second, and the `next` behavior/override in the third. Each sentence earns its place and the most decision-relevant information comes first.

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?

Despite having no output schema, the description discloses the key dynamic aspect of the response (`next` with computed sub-resources and exact follow-up tool calls) and points to view=full / find_providers for deeper data. The schema fills in view and limit semantics. Minor gaps remain — the shape of the region metadata object and error behavior for invalid slugs — but an agent has enough to invoke the tool correctly and interpret its result.

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 80% (view, limit, context, include_next all documented in the schema; only slug lacks a description). The description adds marginal context on top: it clarifies that limit selects a 'top sample' that is 'ranked, with the total,' and that include_next controls the `next` block. This is useful but modest enrichment of already-documented parameters, so 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 opens with a specific, scoped statement: 'One region: metadata + a top sample of its member providers (ranked, with the total).' This names the resource, the return shape, and the ranking behavior. It also distinguishes itself from siblings by referencing find_providers for the full list and get_api/get_provider for single entities, so an agent can tell get_region apart from find_regions, get_region_leaders, and get_provider without opening schemas.

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?

Explicit routing guidance is present: 'Use find_providers?region=slug for the full list, or view=full here.' This names the alternative tool, the condition that selects it (need the full provider list vs. a top sample), and the in-tool fallback. The view parameter's schema description adds further routing to get_api/get_provider for a single entity. Nothing about when to use the tool is left to inference.

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