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

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and does so well: it explains that a request for a STALE key resolves to the current Provider, that the returned key is always canonical, and that Vendor keys require a Market-tier key. These are non-obvious behaviors beyond 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?

It is front-loaded with the core action, but the body is extremely long and dense with field-level jargon (smp_tenants, smp_hosted_by, sub_providers, hostname_count) that reads as output documentation. Some of this is warranted by the absence of an output schema, but the volume hinders quick scanning for tool selection.

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 correctly assumes the job of describing returns, and it covers both branches (Provider and Vendor), key resolution behavior, and the tier prerequisite. It is complete enough to call correctly, with the only gap being the lack of explicit sibling routing.

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 supplies key examples, so baseline would be 3. The description adds genuine meaning beyond the schema: the two key forms select different return shapes (Provider vs Vendor detail), stale keys silently resolve, and Vendor keys carry an authorization requirement.

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 gives a specific verb+resource and, unusually, defines what an 'access point' actually is (a Provider's detail) and distinguishes it from the Vendor branch. It clarifies the two key namespaces (c-/o- vs v-), which helps separate it from the many siblings, though it never explicitly names a sibling like get_provider or list_access_points.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative, despite a dense field of similar siblings (get_provider, get_public_provider, get_seat, list_access_points). The only routing hints are implicit in the return-field descriptions and the tier note for Vendor keys.

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