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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes well beyond that: it discloses the 20-calls-per-day trial quota shared across three tools, that each answer reports remaining calls, the ranking strategy (official shared words first, pinned multilingual mpnet embedding as tie-breaker/synonym handling), the returned fields, the TARES data version and index provenance. That is exactly the kind of context annotations cannot carry.

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 purpose sentence ('Find Swiss customs tariff lines from a description of the goods...') is buried after two preamble sentences about the free trial and disclaimer that largely duplicate the title. Every sentence is informative, but front-loading the quota notice over the actual function makes the opening less efficient for an agent scanning for purpose.

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, the description carries the return-value burden and does so: 8-digit code, official path, relative score, data version, provenance, plus an always-inlined non-official disclaimer. Trial limits and verification expectations are also covered. Only minor gaps remain (error/empty-result behavior, meaning of the relative score scale).

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 67%: lang and query carry schema descriptions, top_k is bare (only default/min/max). The description reinforces the query semantics (goods description or 2-8 digit tariff number) and lang semantics (returned designation language vs. all-language search), but adds nothing for top_k or for ranking/truncation behavior of results. Baseline 3 is appropriate given the schema does most of the work.

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 names a specific verb and resource: it finds Swiss customs tariff (TARES) lines from a goods description or a tariff number, with multilingual indexing detail. It is clearly distinguishable from finma_search and classify_text in kind, though it never distinguishes itself from the sibling tariff_lookup, which is the tool most likely to be confused with it. Therefore clear but without full sibling differentiation.

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 context is implied by the input type (a goods description or tariff number) and it adds a verification step ('check every result on the official tariff at xtares.admin.ch before use'). However, it never says when to prefer this over tariff_lookup for a plain number lookup, or over classify_text, so the agent must infer routing. Implied usage only.

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