Создать кампанию (ad_plan)

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

Annotations already establish this is a non-read-only, non-idempotent, open-world write with no destructive semantics; the description adds substantial constraints beyond that — budgetLimit vs budgetLimitDay mutual exclusivity, the extra.ad_object_type/ad_object_id requirement for site campaigns, and the status="blocked" recipe for creating without launching. It adds real value over the annotations, but it does not cover throttling or what a successful call returns (the campaign id), which an agent would need for follow-up calls.

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 operational content, and the core constraint (VK won't create an empty campaign) is front-loaded. However, it is one dense paragraph with several distinct rules (extra passthrough, adGroups shape, URL binding, budget exclusivity, status blocked) run together, making it harder to scan than a lightly structured version would be.

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 complex create operation with nested objects, no output schema, and high schema coverage, the description covers almost all invocation-time rules (required group structure, URL binding, budget exclusivity, blocked status). The main gaps are the return value/id of the created campaign and any rate-limit expectations, which matter for chaining into create_ad_group.

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%, so descriptions already document each parameter, which sets the baseline at 3 even though the description adds genuinely useful cross-parameter meaning: required adGroups structure (name, package_id, targetings, priced_goal for max_goals), the

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?

States a concrete verb+resource ('Создаёт кампанию (ad_plan)') and immediately clarifies the non-obvious scope: the campaign is created together with its first ad groups, not standalone. It explicitly hands off to the sibling 'create_ad_group' for groups added later, so an agent can separate this from update_ad_plan and create_ad_group without reading schemas.

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?

Gives explicit when-and-how guidance: VK rejects an empty campaign, so adGroups must carry new groups; subsequent groups go through create_ad_group. It also prescribes the practical path of copying ad_object_id/package_id/priced_goal from existing entities via list_ad_plans/list_ad_groups, and names the concrete failure mode (invalid_package) if the URL binding is missing.

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