Изменить бюджет группы объявлений

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

The description discloses that the budget replaces the current value (not adds to it), making repeated calls safe, which aligns with the idempotentHint annotation. It also mentions the API's refusal for non-manual groups and that it returns confirmation plus apiPointBalance. While annotations already indicate idempotency and non-destructiveness, the description adds specific behavioral details about replacement semantics and API restrictions, which is valuable. No contradiction with annotations.

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 concise and front-loaded with the core action and key constraint (minimum 1). It then provides important behavioral details and usage guidance without unnecessary fluff. It's slightly longer than necessary but each sentence adds value, covering replacement semantics, manual management requirement, return value, and exclusions. Well-structured.

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?

Given the tool's complexity (2 params, no output schema, no nested objects), the description covers the essential aspects: what it does, constraints, prerequisites, and what it doesn't do. It also suggests a related tool for checking current budget. The only minor gap is not describing the exact format of the confirmation response, but that's not critical for invocation. Overall, it's complete enough for an agent to use correctly.

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?

The schema already provides descriptions for both parameters (budget and groupId) with constraints and source hints. The description adds minimal extra meaning beyond the schema, such as clarifying that budget replaces the current value and that groupId comes from list_groups. Since schema coverage is 100%, the baseline is 3, and the description doesn't significantly enhance parameter understanding beyond what's already in 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 clearly states the tool's purpose: setting a budget for one ad group in rubles, with a minimum of 1. It specifies the resource (ad group) and the action (change budget), and distinguishes it from related tools like change_group_price and list_groups. The description is specific and unambiguous.

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 description explicitly states when to use this tool: for groups with manual bid management, and notes that the API rejects others. It also mentions that to change campaign budget, bid, or group status, other tools are needed, and suggests checking the current budget via list_groups first. This provides clear usage context and alternatives.

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