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

Goes well beyond the annotations: discloses that KYC verification is required for purchase finalization and that the agent never completes transactions, that incomplete products appear only in `pominiete_bez_danych`, that query interpretation is echoed in `interpretacja_zapytania`, and that unit-sold items carry per-ounce pricing with a minimum order value. Annotations already cover read-only/idempotent safety, so this is substantial added context.

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 purpose, but it is a single dense block that repeats query-parsing details already present in the `query` schema field. Three trailing sentences of legal/educational disclaimer boilerplate ('nie stanowią porady inwestycyjnej', 'nie rokuje przyszłych cen') consume space without helping an agent select or invoke the tool.

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 10 parameters and no output schema, the description carries return-shape information well (`produkty`, `pominiete_bez_danych`, `interpretacja_zapytania`, `cena_24h`, `cena_calkowita_min`) and explains sort order. The gaps are pagination and the role of `limit`, which are not covered anywhere.

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 70%, and the description meaningfully extends it, especially for `query`: weight parsing with ±2% tolerance, whole-token matching ('100 g' not matching '1/100 oz'), Polish/English aliases and coin names. It leaves `limit` and `masa_g_min`/`masa_g_max` unaddressed, and the Srebro vs Srebro VAT distinction is already in the schema.

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 a specific verb+resource: a catalog search over IDFMETALE investment metals, enumerating the filterable facets (metal, form, purity, mint, weight, availability, price range). It partially differentiates from siblings by noting the returned amounts match get_live_price, though it never contrasts itself with get_product or check_availability.

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?

Usage is implied rather than stated: the description explains sorting differences with and without `query` and notes that products missing attributes are excluded, which hints at how to query. But there is no explicit 'use this instead of X when Y' guidance against the eight sibling tools, and no stated exclusions.

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