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

Annotations only declare readOnlyHint/idempotentHint/non-destructive, so the description carries the real behavioral load and does: mandate scope (procurement.quote.prepare with a ceiling covering the total), the structured mandate_required response, the guarantee that it never invents prices, and the identified-agent-key access requirement. None of that is recoverable from 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?

Single dense paragraph, correctly front-loaded with the trigger, then arguments, then returns, then the mandate and access preconditions. Every clause is load-bearing, though the length and the trailing self-service signup URL make it heavier than ideal for quick scanning.

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 high-stakes, precondition-gated action tool, the definition covers what the agent must know before calling: mandate and ceiling, access key, input encoding, the readiness checks returned, and how to recover from mandate_required. An output schema exists, so the brief description of returned fields is bonus rather than padding.

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 does most of the work: tender_id, unit_prices with a concrete shape example and 'net unless prices_include_vat', quote_total as the VAT-included alternative, delivery_days, and supplier_id as the user's RUT. It still leaves preferred_language unexplained and doesn't state whether unit_prices and quote_total are mutually exclusive or how they interact.

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 artifact: it builds the quote kit the user's person needs to submit in Mercado Público, and explicitly scopes the boundary ('Andes cannot submit it'). This is unambiguously distinct from the research-oriented siblings (search_tenders, get_tender_detail, assess_fit).

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?

Opens with an explicit trigger ('Use this when your user decided to quote') and defines the blocked path: if no mandate exists the answer is mandate_required with approval_url and ask_user, and after approval you call again with the same arguments. It also states the fallback behavior for unpriced lines. The only omission is naming a sibling, which isn't needed here since no sibling overlaps.

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