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

Beyond the read-only and non-destructive annotations, it discloses that suppliers are grouped by legal identifier, results are built from awarded OCDS tenders, and win-rate and competitor insights depend on published bidder lists. It also warns that framework agreements skew average bidder counts, explains that empty matches include an explanatory note, and states the identified-agent-key requirement with free self-service enrollment.

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 purpose is front-loaded and the description contains little filler, with each caveat supplying practical operational or interpretive context. However, the long opening sentence and nested parentheticals make it dense; separating invocation, metric interpretation, data behavior, and access into shorter sentences or bullets would improve scanability.

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 read-only analytical tool with an output schema, it covers the essential data source, award-based scope, identity grouping, conditional metrics, statistical caveat, empty-match behavior, and authentication prerequisite. The main remaining gaps are the behavior of limit and preferred_language, identifier and name-matching rules, and explicit routing relative to sibling tools.

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?

With 0% schema description coverage, the description substantially compensates for the key inputs: supplier_id may be a tax identifier such as a Chilean RUT or an identifier seen in buyer_history, supplier_name is an alternative, and legal-identifier grouping clarifies identity resolution. It does not explain what limit caps, how preferred_language affects results, how names are matched, or which identifier takes precedence if both are supplied.

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 opening identifies a specific supplier-analysis task and enumerates wins, buyers, categories, competition when winning, win rate, and frequent competitors. Its supplier focus implicitly separates it from buyer_history, but it does not explicitly contrast itself with that or other siblings, so it falls just short of full sibling differentiation.

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?

"Use this to size up a supplier, your user's own company or a competitor" gives clear use cases, while the identifier guidance and instruction to read median_bidders first support correct invocation and interpretation. It does not explain when not to use the tool or route buyer, tender-search, or market-analysis questions to a sibling.

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