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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does mention that results carry a `next` block with sub-resources and tool calls, and that include_next=false omits it—useful behavior. However, it does not explicitly state that the tool is read-only, mention authentication or rate limits, or clarify side effects. This is a modest disclosure but not comprehensive.

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 description is three sentences, front-loaded with the main purpose, then the alternative, then the key behavioral note. Every sentence earns its place with no fluff or repetition. It is highly concise and well-structured.

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 5 parameters but no output schema and no annotations, the description covers the core purpose, the alternative, and the notable `next` block behavior. It tells the agent what is returned (metadata, site link, sample providers, total) and how to control output via include_next. It could mention the `context` parameter or error cases, but the schema covers context, and the description is otherwise complete for a read operation.

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%, so parameters are already well documented. The description adds context by linking `view=full` to the alternative find_providers and clarifies that `include_next` controls the `next` block. This goes slightly beyond the schema, but most parameter meaning is already in the schema, so the description adds limited extra value.

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 precisely that the tool returns metadata, a dedicated site link, and a top sample of member providers with a total count. It clearly identifies the resource (area) and what is included, and it distinguishes itself from find_providers by noting that helper returns the full list. This is a specific, informative purpose statement.

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?

The description explicitly tells the agent when to use an alternative: 'Use find_providers?area=slug for the full list, or view=full here.' This gives clear context on how this tool differs from the sibling and when to prefer the alternative. However, it does not mention other related siblings like get_area_leaders, so it misses some exclusion guidance.

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