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

With no annotations provided, the description carries the full behavioral burden. It helpfully discloses the return payload fields, the price currency (RUB), and the cost model ('Flat 5 points per successful run'), but it does not state that the operation is read-only, mention authentication requirements, rate limits, or error behavior. This is adequate for a simple read endpoint but leaves clear gaps.

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 two tight sentences: the first front-loads purpose and enumerates return fields, while the second supplies the pricing behavior. No sentence is wasted, and the critical identifier scope ('by id or URL') appears before the field list.

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 one-parameter getter with no output schema and no annotations, the description does what is needed: it identifies the required input shape, lists the returned data categories, and states the cost. It stops short of describing error cases or confirming read-only safety, but the core information an agent needs to call and interpret the tool is present.

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 description coverage is 100%, and the single parameter 'item' is already documented as a 'Listing ID or URL. e.g. 8132133298.' The description echoes 'by id or URL' but adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource: 'Get a full Avito listing by id or URL,' and enumerates the returned fields. This clearly distinguishes it from a generic search or seller endpoint in substance, but it never names the sibling search tool (run_avito_items_search) or explicitly contrasts this lookup-by-id/URL behavior with searching. Thus it is clear but lacks explicit 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?

The condition 'by id or URL' implies the tool is for direct lookups when an identifier is already known, and the sibling run_avito_items_search covers query-based discovery. However, the description never states when to prefer this tool over search, categories, or sellers, nor does it mention any exclusions. Usage is therefore only implicitly indicated.

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