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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: servers whose tools could not be enumerated are reported in 'coverage.not_enumerable' rather than silently counted as zero. It also explains the semantics of 'first-party' vs 'derived' provenance, adding transparency beyond a simple data list. This covers an important edge case and clarifies the data's meaning.

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 five sentences long, but each sentence contributes value: it states the purpose, defines provenance terms, gives usage guidance, and describes an edge case. It is front-loaded with the core function. While not minimal, it is well-organized and not excessively verbose for the information conveyed.

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 five parameters and no output schema, the description covers the essential content (tools, operation, auth, provenance, and the not_enumerable case) but does not describe the response format or pagination behavior. It is adequate for a caller to understand what to expect, but not fully complete given the complexity and lack of annotations or output schema.

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 low (40%). The description compensates by explaining the 'provenance' parameter in depth, clarifying the two enum values and recommending a specific filter. However, it adds nothing about 'slug', 'page', or 'limit' beyond what the schema provides (which is nothing for these). It covers the key parameter but leaves the others to be inferred from common pagination patterns.

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 a specific verb-resource: 'Every MCP tool a provider ships, with the operation each one wraps and its auth.' This clearly identifies the tool's function and distinguishes it from siblings like get_provider_operations by focusing on tool enumeration with provenance. No tautology; the purpose is explicit and unambiguous.

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 gives clear usage context: 'Filter with provenance=first-party for a true picture' and explains why derived tools overstate adoption. This tells the agent when to use this tool and how to get the desired result. However, it does not explicitly name alternative tools or state when NOT to use this one, so it lacks exclusionary guidance.

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