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

Annotations already declare readOnly/idempotent/closed-world, and the description adds real substance beyond them: it discloses the fallback broadening logic (same buyer+sector first, else same kind of work in the nearby district), that it reports its sample size, that it will not read tender documents, and that it is free during beta. The fallback-and-sample-size disclosure is exactly the kind of trait an agent could not infer from the schema.

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?

Front-loaded with the decision question and the two input modes before the long output enumeration, which is the right order. The lead 'Free during beta.' is a commercial aside taking the highest-attention slot, and the output list is a dense run-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?

With no output schema and all four parameters optional, the description carries the full burden and does: it spells out what the analysis returns, the fallback comparison scope, the sample-size disclosure, and the document-reading limitation. An agent can decide whether to call it and how to shape inputs without further information.

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 baseline is 3; the description adds the grouping semantics that the schema does not: tender_id alone, versus the buyer + cpv + country alternative path, with tender_id accepting either an id or a pasted link. It does not explain the sector/country interaction further, so it lands above baseline rather than at the top.

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?

Opens with the exact decision it answers ('Should I bid, and at what price?') and a specific verb+resource: analysing comparable past contracts for a tender or buyer+sector. It enumerates the concrete outputs (bidder counts, single-bid share, winner discount to estimate, price range, incumbents, frequent bidders with win rates, direct-award rate, recent awards), so it is unmistakably distinct from siblings like award_history or competitor_profile.

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?

Explicitly states the two entry paths — an open tender_id (sourced from search_tenders/match_company or a pasted link) or a buyer+sector pair — which routes the agent to the right prerequisite tools. It also carves out a negative scope ('Does not read the tender documents'). Missing is an explicit statement of when to prefer a sibling tool (e.g. competitor_profile for pure competitor questions).

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