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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely non-structural behavior: results carry provenance (source plus date) and unconfirmed points are marked with a caution that must be passed through to the user. That trust/uncertainty contract is exactly the kind of thing annotations cannot express; only the caching/cardinality behavior of the closed dataset is left unstated.

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 resource and its fields, then the trigger phrases, then the caution caveat — a sensible order. The English restatement duplicates the Russian text and is the main piece of low-value bulk, though it does aid non-Russian agents.

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 2-parameter read-only lookup with full schema coverage, annotations and an output schema, the description supplies what structured fields cannot: scope, trigger conditions, and the provenance/caution contract. Nothing an agent needs in order to call it correctly appears to be missing.

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 both parameters are already documented, including the model-name-to-brand fallback and the city/id identifiers. The description adds only the geographic scoping note ('по городам России'), which is modest additional meaning beyond 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?

The description names a specific resource (dealer and service points for a car brand in Russian cities) and enumerates the returned fields: name, role (official dealer / parallel import / service), address, phone, site, source and date. No sibling (get_sales, compare_models, calc_import_fees) covers this resource, so the agent can route to it without opening other schemas.

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?

Concrete trigger phrases are given — «где купить X в Москве», «есть ли дилер Zeekr в Петербурге» — which make the call condition unambiguous. There are no explicit exclusions or named alternative tools for adjacent queries, so it falls short of a 5.

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