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

The annotation readOnlyHint=true already indicates a safe read operation. The description adds that the provider is 'navigable to its seats and each seat's observed hosts,' providing context about the returned structure. However, it does not mention rate limits, pagination, or other behavioral details, so it only modestly extends the annotation.

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 two short sentences, front-loaded with the core purpose and a clarifying second sentence. It is concise with zero redundancy or unnecessary detail.

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 simple single-parameter read-only tool with no output schema, the description provides sufficient context: it identifies the resource and hints at the navigable structure. It could be more explicit about the response being a single provider object, but the get verb and slug parameter imply this.

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?

The input schema covers 100% of parameter descriptions, with 'slug' described as 'The curated provider slug.' The tool description repeats the 'curated provider' wording but adds no new semantics. Baseline 3 is appropriate given the high schema coverage.

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 clearly states the tool gets a 'curated provider' and elaborates that it is navigable to seats and observed hosts. This distinguishes it from siblings like list_providers and get_provider_sla, though it does not explicitly name them. The verb 'Get' and the specific resource make the purpose clear.

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 does not provide any guidance on when to use this tool versus alternatives such as list_providers or get_provider_sla. It implies usage through the slug parameter and 'navigable' wording, but there are no explicit when-to-use or when-not-to-use instructions.

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