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

Annotations already mark it read-only and idempotent, and the description adds meaningfully beyond that: it warns that tender_value is the ORIGINAL ASKING PRICE, not money spent, and that cancelled or unsuccessful tenders still contain a populated tender_value. It also clarifies the OCDS award/contract interpretation and that text is largely Ukrainian, which materially affects how the agent reads results.

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 long but dense, and every section carries useful semantics: return fields, the asking-price caveat, award/contract interpretation, language note, and source of the input id. It is front-loaded with the core purpose, and the detail is justified by the lack of an output schema, though a few commas and clauses make it slightly harder to parse than needed.

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?

Given there is no output schema, the description carries the full burden of explaining the return shape, and it does so thoroughly: tender metadata, buyer info, periods, line items, award/contract stages, and the critical monetary interpretation. It also names the sibling tools that supply the required id and notes the language of the returned text, covering everything needed to invoke 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?

The schema already documents the single id parameter at 100% coverage, so the baseline is 3. The description adds value by restating the 32-char format and explicitly warning it is not the human-visible tenderID like 'UA-2026-...', reducing the risk of passing the wrong identifier.

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 opens with a specific verb-resource pair: 'Full detail for a single Ukraine ProZorro tender by id.' It enumerates the exact returned fields and distinguishes it from sibling tools by noting it consumes ids from prozorro_recent_tenders / prozorro_search_tenders, so an agent can identify what this tool is for.

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 explicitly states the tool accepts the 32-char tender id from prozorro_recent_tenders / prozorro_search_tenders, indicating when it should be selected: after a list/search has produced a tender id. It does not literally say 'use x for listing, use this for details,' but the routing is clear enough from the context.

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