Карточка товара и КБЖУ

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral detail beyond annotations: it lists the returned product fields, explains that КБЖУ is given both per 100 g and per package, and notes that in some chains КБЖУ exists only as text and is parsed. This is useful context not available from the annotations alone.

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?

Two sentences: sentence on the card contents and sentence on the source of good_id plus КБЖУ units and parsing behavior. Every part earns its place; there is no unnecessary repetition.

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?

The tool has one required parameter and an output schema, so the description is nearly complete. It covers the key data fields, the source of the main parameter, and the units. The only missing piece is an explanation of optional app_id/point_id, but they are non-essential and defaulted.

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 0%, so the description must compensate. It does explain the only required parameter, good_id, by indicating that it comes from grocery_search() or grocery_plan_order(). However, app_id and point_id are left undefined, and their semantics are not clarified beyond their names and defaults.

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 clearly identifies the tool as retrieving a product information card (состав, КБЖУ, вес, срок хранения, производитель), which is distinct from sibling tools like grocery_search, grocery_plan_order, and grocery_add_to_cart. It also clarifies that this is the 'good info' lookup rather than a search or ordering operation.

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?

It provides direct usage guidance: good_id must come from grocery_search() or grocery_plan_order(). This tells the agent when to call this tool and where to obtain the required input. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls just 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.