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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, and the description adds meaningful context on top: BETA status, the log-odds 1-10 ladder and its percentile interpretation, the caveat that counterparty is a "weak signal," and the explicit disclaimer that "a score is a prompt to look, not a finding of wrongdoing." That is unusually rich interpretive and epistemic context beyond structured fields.

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 entity, geography, and BETA status, then proceeds in a logical order. The long enumeration of output fields (base_rate, relative_risk, awards_scored, etc.) is dense and slightly list-like, but each term carries information an agent needs given no output schema.

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 carries the full burden of describing return values, and it does so comprehensively: both scores, their fields, behavior ratios, evidence awards, and top supplier relationships. It also sets expectations about calibration and signal strength, which is essential for correct downstream interpretation.

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%, so the id formats (DIR3/NIF/SIRET) and the country enum with ES default are already documented. The description nonetheless adds cross-tool meaning by telling the agent to resolve the id via procurement_buyers, which the schema cannot convey.

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 names the specific verb+resource ("Risk profile of a PUBLIC BUYER (a contracting body) in Spain or France") and immediately scopes it away from siblings: "never about a supplier or a tender." An agent can distinguish it from procurement_awards, procurement_relationship, or company_detail without opening any schema.

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?

It gives a clear usability condition (buyer-level risk in ES/FR) and an operational prerequisite: "Find the id with procurement_buyers." It also implicitly excludes supplier/tender use cases. It doesn't state when a buyer profile will be unavailable or how this complements procurement_relationship, so it stops short of full alternative-routing guidance.

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