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

Beyond the read-only/idempotent annotations, it discloses important behavior: data lags months and every signal carries data_as_of, anomalous awards are excluded from totals and listed separately for verification, and anonymous access is limited to one market-wide signal per call with a free key raising the limit. This is exactly the kind of operational context annotations cannot convey.

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?

Purpose and the bid-selection use case are front-loaded, then the signal inventory, then parameter syntax, then access constraints — a logical order with no filler sentences. It is dense and the long signal enumeration runs on, but nearly every clause carries information an agent needs.

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?

Despite an output schema existing, the description still explains the shape of each signal (neutral statement, number, period-over-period change, supplier implication, suggested_next_calls), plus data provenance (OCDS) and freshness caveats. For a five-parameter, multi-signal analytics tool this is sufficient to call it correctly.

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 0%, so the description must compensate. It does so well for 'category' (UNSPSC code vs. name, with examples) and 'period' (last_12m default, year, quarter formats), and implicitly for 'signals' via the enumerated signal list. 'limit' and 'preferred_language' are never explained, leaving part of the five-parameter surface undocumented.

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?

States a specific verb and resource ('understand a public procurement market') and enumerates the concrete outputs (supplier concentration, HHI, single-bidder share, live Compras Ágiles, amount_anomalies). This is clearly distinct from siblings like search_tenders or assess_fit, which operate on individual tenders rather than market-level aggregates.

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?

Gives a clear when-to-use framing: 'before choosing where to bid', which positions it upstream of assess_fit and search_tenders. It does not explicitly state when NOT to use it or name sibling tools as alternatives, so guidance is strong but not complete.

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