Изменить ставку группы объявлений

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

Goes well beyond the readOnlyHint=false/idempotentHint=true annotations by explaining the value is a replacement, not an increment ('replaces the current bid, not adds to it, so calling again is safe'). It discloses the paymentModel-dependent unit semantics, the manual-bid prerequisite, and the return payload (API confirmation plus apiPointBalance), deepening the agent's understanding of side effects and dependencies.

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?

Dense but efficient — every sentence earns its place, covering idempotency, prerequisites, returns, and cross-references to sibling tools without fluff. The Russian original is long and slightly run-on, reading as one wall of text rather than structured points, but it remains well under a reasonable length for the depth of context delivered.

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-param tool with no enums or nested objects, the description is thorough: constraints, idempotency, side effects, return value, and negative capabilities are all covered. Minor gaps remain — no explicit mention of auth requirements, concurrency, or rate limits — though the openWorldHint and lack of an output schema mean the description covers the critical call/decision logic fully.

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 baseline is 3, but the description adds notable meaning beyond the schema: it explains the price unit depends on the group's paymentModel (rubles per 1000 impressions for CPM vs. per click for CPC), and points to list_groups as the source for groupId. This is genuinely useful enrichment, though the schema already carries most of the burden.

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 opens with a specific verb+resource: 'Sets a bid for one ad group (called price in the API) in rubles,' which states exact action, target, and unit. It distinguishes itself from the sibling change_group_budget by name, and clarifies the scope ('one ad group') so the agent cannot confuse it with campaign-level operations.

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?

Provides explicit when-to-use conditions ('only groups with manual bid management accept it') and names the exact alternative for budget changes ('for that there is change_group_budget'). It also enumerates what the API cannot do (pause, resume, delete, change budget), both excluding irrelevant cases and routing the agent to the correct sibling tools.

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