Изменить цены варианта

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

Annotations already declare readOnlyHint=false/not read-only, destructiveHint=false, and idempotentHint=true. The description adds important context: only price and compareAtPrice are affected, compareAtPrice:null removes the strike-through price, failures arrive as userErrors, and the call is limited to one product. It does not repeat annotation data, and no contradiction exists.

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?

Every sentence carries distinct information: main function, scope limit, value format, null semantics, exclusions, prerequisite, and error behavior. It is dense but well-structured and does not restate the title or schema.

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 description covers all necessary context for a simple two-parameter write tool: required parent id, variant id format, value format, null handling, limits, and error reporting. With no output schema and 100% schema coverage, nothing essential is 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 the schema documents both parameters. The description adds semantic value beyond the schema: amounts are decimal strings in shop currency, compareAtPrice:null clears the old price, and only price fields are changed—not other variant attributes.

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 uses a specific verb ('Задаёт') with a clear resource: prices and compareAtPrice for variants of one product. It explicitly states what it does NOT change (SKU, barcode, options), which distinguishes it from sibling tools like update_product and graphql_request.

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 explicitly says when to use this tool (set price/compareAtPrice on variants) and when not to (other variant fields via graphql_request). It also specifies the prerequisite: parent product id from list_products/get_product.

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