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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent knows this mutates remote state, but the description adds nothing behavioral. It does not say whether existing callouts are replaced or appended, whether the extension applies account-wide or to specific ads, or what happens on partial failure — important for a write tool.

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?

A single front-loaded sentence with no filler. However, its brevity reflects under-specification rather than disciplined brevity, which keeps it out of the top band.

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 mutation tool with no output schema and only two parameters, the description leaves critical context missing: the required callouts array is the only argument, yet nothing explains what entity the extensions attach to or whether the call is additive or replacing. The dry_run capability is only discoverable from the schema, not the description.

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%: both the callouts array (1–25 chars) and the dry_run flag are fully documented in the schema, including the dry-run read behavior. The description only restates the 25-character limit already in the schema, so baseline 3 applies.

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 gives a specific verb and resource ("Создать уточнения (callouts)") and narrows the ambiguous tool name 'ad_extensions' down to callouts specifically. It does not distinguish itself from the sibling pair list_ad_extensions / delete_ad_extensions, but the scope of what is created is 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?

There is no guidance on when to create callouts versus other extension types (sitelinks, vcards) represented by sibling tools, nor any preconditions such as campaign/ad scope. The agent must infer usage entirely from the tool name.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds valuable domain semantics for the modifier value (100 = unchanged, 0 = disables impressions for the segment). It says nothing about permissions, reversibility, or whether existing adjustments are overwritten — and the 100 semantics largely duplicates the bid_modifier schema field.

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 tight sentences with no filler, and the core action plus the counterintuitive coefficient convention (0 disables, not zeroes the bid) is front-loaded.

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 rich schema covers all four parameters, but for a mutation tool with no output schema the description should still say when to use it versus set_bid_adjustments and whether repeated calls overwrite. Adequate but with real gaps around the sibling boundary.

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 the nested type/gender/region/income fields are already fully documented in the schema. The description's coefficient explanation adds marginal value beyond that, warranting the baseline 3 rather than more.

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: creating bid adjustments on campaigns or ad groups. The scope is clear enough to act on, but it never distinguishes itself from the closely named siblings set_bid_adjustments and get_bid_adjustments, leaving the create-vs-update boundary ambiguous.

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?

There is no when-to-use guidance and no named alternative, despite three sibling tools (set_bid_adjustments, get_bid_adjustments, delete_bid_adjustments) operating on the same resource. An agent must guess whether to call this or set_bid_adjustments when a coefficient already exists.

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

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

Annotations already declare readOnlyHint=false (a mutation) and openWorldHint=true, covering the safety profile. The description adds nothing beyond the action itself: no note that keywords are appended rather than replacing, no mention of dry_run validation mode, and no auth/rate-limit context. It does not contradict the annotations but contributes no behavioral value.

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?

A single front-loaded sentence with no waste. It is efficient, though arguably too sparse for a mutation tool with a notable dry_run parameter.

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 mutation tool with no output schema, the description is thin: it does not explain return behavior, the effect of dry_run, or how appended keywords interact with existing ones. The rich schema covers parameters, but the description leaves behavioral completeness largely unaddressed.

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 the schema already documents ad_group_id, keywords (including the minus-word hyphen convention), and the dry_run behavior. The description adds no parameter-level meaning beyond the schema, which is the baseline-3 case when the schema does the heavy lifting.

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 states a clear verb and resource ("Добавить ключевые фразы" = add key phrases) plus the target ("в группу объявлений" = to an ad group). It is understandable in isolation, but it does not distinguish itself from close siblings such as update_keywords, manage_keywords, or add_negative_keyword_shared_sets, so the agent cannot tell precisely when this is the right tool versus those.

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?

There is no guidance on when to use this tool versus alternatives, no preconditions (e.g. the target ad group must exist), and no mention of the dry_run capability. The agent is left to infer usage entirely from the name and schema.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write/open-world nature is covered. The description adds nothing behavioral: no mention of the dry_run preview path, permissions, or side effects on existing lists. For a mutation tool it leaves the operational profile entirely to the schema.

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?

A single front-loaded sentence with no filler. It is efficiently sized, though its brevity is as much under-specification as conciseness.

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 rich schema carries most of the load, but a create-style mutation tool benefits from stating prerequisites and the dry_run preview option, neither of which appears in the description. The definition is adequate but not complete for the operation it performs.

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%, including detailed enum semantics for type, operator, and membership_life_span, so the baseline is 3. The description only loosely gestures at the type parameter ('целей Метрики, сегментов или интересов') and adds no format or constraint detail beyond 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 states a specific verb ('Создать') and resource ('условие ретаргетинга'), and names the sources (Метрика goals, segments, interests), which aligns with the sibling set. It does not, however, distinguish itself from the other retargeting siblings (update_retargeting_lists, delete_retargeting_lists), so sibling differentiation is only implicit via the verb.

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 says what the tool does but gives no when-to-use guidance, no prerequisites (e.g. account context), and never mentions alternatives such as update_retargeting_lists or set_audience_targets. An agent must infer routing from the name alone.

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

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

Annotations only give readOnlyHint=false and openWorldHint=true. The description carries the rest of the burden for a mutation tool but says nothing about side effects, permission/auth requirements, rate limits, or what happens on partial failure. It never mentions the dry_run safety path that the schema exposes.

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?

A single front-loaded sentence with no filler; the essential verb+resource+scope comes first. It is terse to the point of omitting useful invocation context, but nothing is wasted.

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 mutation tool with no output schema and thin annotations, the description is only minimally sufficient. The schema fully documents parameters, but the description omits mutation semantics, the dry_run option, and any preconditions an agent would want before writing.

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 baseline is 3. The description only reinforces the region_ids/get_regions link already documented in the schema and adds no syntax, constraint, or interaction detail beyond it.

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 specific verb+resource ('Создать группу объявлений в кампании') and adds a scope qualifier (region targeting). It is identifiable against siblings like create_campaign or create_text_ad, though it doesn't explicitly name a near alternative.

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 parenthetical '(см. get_regions)' implies you must fetch region codes first, which is usable guidance. However, there is no when-to-use/when-not statement, no mention of required preconditions such as an existing campaign or dry_run for validation.

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

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

Annotations cover only readOnlyHint=false and openWorldHint=true; the description adds the crucial behavioral facts the annotations do not: there is no sandbox, the campaign is created in a live account, and it will only spend money after moderation and enabling. It does not describe error modes or what a dry_run response actually contains, so it falls just short of a 5.

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?

Front-loaded with the core action, then constraints, then the safety warning — every sentence carries information. It is somewhat dense and the warning block could be tightened, but nothing is filler.

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 9-parameter mutation tool with no output schema and open-world annotations, the description supplies the missing risk context (production account, spend after moderation, dry_run flag, draft guidance) that an agent needs to call it safely.

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 the schema already documents all nine parameters (including dry_run, time_zone and tracking_params semantics). The description only adds the currency unit for budget ("Бюджет в рублях") and restates the type restriction already in the schema's type description.

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 ("Создать новую текстово-графическую кампанию") and immediately narrows scope to text-graphic campaigns only, which cleanly separates it from update_campaign, manage_campaigns and create_ad_group. An agent knows exactly what artifact this produces.

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 states explicit when-not conditions: smart banners, dynamic ads and unified performance campaigns cannot be created via this API/server and must be made in the Директ UI. It also gives an operating instruction (keep test-created campaigns as drafts) that directly shapes how the tool should be used.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, and the description adds nothing beyond restating schema constraints. It does not say what happens on success, what errors look like, whether the operation is reversible, or what dry_run accomplishes (already documented in the schema).

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?

A single, front-loaded line with no filler and the verb leading. It is efficient, though the field listing duplicates schema content rather than adding information.

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?

With annotations covering safety and 100% schema coverage, the description only needs to complete the picture, but it omits where the ad sits (ad_group_id), whether title2 is optional, and any usage context. Adequate but with clear gaps.

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 the schema already documents every parameter, including lengths and dry_run. The description simply mirrors the title/title2/text/href constraints, adding no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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 specific verb (Создать) and resource (текстовое объявление), and enumerates the content fields, so an agent can distinguish it from update_text_ad and the campaign/ad-group creators. It lacks an explicit contrast with sibling tools, keeping it short of a 5.

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?

There is no when-to-use guidance, no mention of prerequisites (an existing ad group), and no reference to alternatives like update_text_ad or manage_ads. The agent must infer the entire context from the name and schema.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is externally covered. The description adds the 'Необратимо' (irreversible) warning, which reinforces but does not go far beyond the destructive hint, and says nothing about permissions, batch limits, or the dry_run option.

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 short sentences with the destructive warning front-loaded via an emoji flag; nothing is redundant. It is efficient, though arguably too terse for a destructive operation.

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?

Annotations cover the safety profile and the schema fully documents both params, so structural coverage is adequate. However, for a destructive, open-world delete with no output schema, the description omits any usage context or mention of the dry_run safeguard, leaving a clear gap.

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 both parameters (ad_extension_ids, dry_run) are already fully documented in the schema. The description only restates 'по ID' and adds no syntax, batching, or dry_run semantics beyond the structured data, making baseline 3 correct.

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 specific verb (Удалить) and resource (уточнения) with scope (по ID), so the agent knows exactly what is removed. It does not explicitly differentiate itself from siblings like add_ad_extensions or list_ad_extensions, but the verb makes the intent 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?

No when-to-use guidance and no reference to alternatives such as list_ad_extensions or add_ad_extensions. The available dry_run safety path is not surfaced in the description at all, leaving the agent no routing or precondition guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the explicit warning '⚠️ Необратимо' (irreversible), which reinforces destructiveness but is largely redundant; it does not mention dry_run availability, authorization requirements, or batch limits beyond what the schema provides.

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 short, front-loaded sentences with zero waste. The core action and the critical irreversible warning are delivered immediately without unnecessary elaboration.

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 a simple delete operation, full schema coverage, and annotations that already declare destructiveness, the description provides the essential context (what is deleted, permanence). It could mention dry_run or usage scenarios, but the structured fields cover those adequately for a basic call.

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%, with both ad_group_ids and dry_run fully documented in the schema. The description only restates 'by their ID' which is already covered, so the baseline of 3 applies when structured fields do the heavy lifting.

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 states a specific verb ('Удалить' / delete) and resource ('группы объявлений' / ad groups) and clarifies the scope ('по их ID' / by their ID). It clearly distinguishes this tool from siblings like list_ad_groups, create_ad_group, or other delete_* tools for different resources.

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 offers no guidance on when to use this tool versus alternatives, nor does it mention the dry_run parameter or any prerequisites. It only states what the tool does and that it is irreversible, leaving the agent to infer usage context.

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

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

Annotations already declare destructiveHint=true, so the agent knows the operation is destructive. The description adds genuinely new behavioral context beyond that: the bid slice reverts to its base value and the deletion is irreversible. It does not mention auth requirements or batch limits, but for a delete tool this is solid added value.

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 short sentences, front-loaded with the action, and every clause carries information (what is deleted, by what key, side effect, irreversibility). No filler.

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 destructive, no-output-schema tool whose annotations and schema are already rich, the description covers the critical irreversible side effect. It omits any note on dry_run as the safe pre-check and on partial-failure behavior across a large ID list, which are minor gaps.

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% and both parameters are fully documented in the schema, including the dry_run semantics and the source of adjustment_ids. The description only restates that deletion is by ID, adding no meaning beyond the schema, so the baseline 3 applies.

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 specific verb+resource (delete bid adjustments) with the keying method ('по их ID'), which is unambiguous. It does not explicitly name siblings like set_bid_adjustments or add_bid_adjustments, but 'delete' is distinct enough to separate it from the other bid-adjustment tools.

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 gives no when-to-use guidance, no mention of the dry_run verification path, and no prerequisites or alternatives. The only routing hint ('ID берутся из get_bid_adjustments') lives in the schema, not the description.

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

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

Annotations already declare destructiveHint=true, so credibility goes to what's added beyond them: irreversibility and a non-obvious partial-failure model where an individual failure returns a ❌ string while the remaining IDs are still deleted. This response-shape disclosure is valuable, especially with no output schema.

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 tight clauses, front-loaded with the action and scope, followed by the two highest-value caveats (irreversibility, partial failure). No filler.

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 destructive batch delete with no output schema, the description adequately covers the irreversible nature and the surprising error behavior. It stops short of noting the dry_run alternative or bounds (maxItems 1000), but those live in the schema.

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 the schema already documents both dry_run and retargeting_list_ids, including that IDs come from list_retargeting_lists. The description confirms the ID-based targeting but adds no syntax or bounds beyond the schema, so the baseline 3 applies.

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 specific verb+resource ('Удалить условия ретаргетинга и подбора аудитории по ID') that an agent can immediately distinguish from the list_/add_/update_retargeting_lists siblings. Scope (by ID) is explicit.

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 delete action against retargeting/audience conditions is self-evident, and the source of IDs is implied via the schema. However, the description never states when to reach for this tool vs. update_retargeting_lists or list_retargeting_lists, nor any prerequisites, so it only implies usage.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds a non-obvious behavioral constraint beyond the annotations: deletion fails if the set is attached to an ad. It doesn't describe the return shape, but that is acceptable for a delete tool with no output schema.

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 tight sentences with the action stated first and the key caveat second. No filler, nothing wasted.

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 destructive delete with no output schema, the description covers the operation and the main failure condition, and annotations cover the risk profile. It could go further by pointing to list_sitelinks for ID discovery, which the schema mentions but the description itself omits.

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 both parameters (sitelink_set_ids and dry_run, including a 1–1000 item bound) are fully documented in the schema. The description only echoes 'by ID' and adds no syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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 states a specific verb and resource (delete sitelink sets by ID), which unambiguously distinguishes it from its siblings list_sitelinks and set_sitelinks. An agent can immediately tell this is the removal operation for sitelink sets.

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 an important exclusion — Direct won't allow deleting a set that is bound to an ad — which is genuine usage guidance. However, it never names alternatives (e.g. unlink via update, or use list_sitelinks first to find IDs) nor explicitly states the when-to-use condition, so guidance is implied rather than complete.

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

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

Annotations already declare destructiveHint=true, but the description adds real behavioral context beyond them: deletion is irreversible, and a per-vcard failure returns a ❌ string while the remaining vcards are still deleted. This partial-failure semantics is exactly what an agent needs and is not in the 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?

Two sentences, zero filler, with the irreversible-deletion fact front-loaded ahead of the failure-mode detail. Efficient and 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?

With no output schema and annotations covering only the safety profile, the description usefully discloses the response shape on partial failure (❌ string) and the irreversibility. Only the dry_run parameter behavior is left entirely to the schema.

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 the baseline is 3. The description mentions ID-based targeting but adds no detail on the dry_run parameter or ID format beyond what the schema already documents.

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 states a specific verb+resource ('Удалить визитки по ID') and its scope, clearly distinguishing it from the sibling list_vcards and the many non-delete siblings. An agent can identify the operation without opening the schema.

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?

Usage is implied by the verb 'delete' and the 'по ID' qualifier, and the schema points to list_vcards as the ID source, but the description itself names no alternative or explicit when-to-use/when-not condition. Adequate but with a clear gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows the safety profile without the description. The description adds that data comes through Live API v4 and what fields are returned, but says nothing about auth requirements, rate limits, or behavior for multiple logins.

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?

One compact sentence with the resource front-loaded and no filler. It is perhaps slightly terse to the point of omitting useful context, but nothing is wasted.

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?

With no output schema, the description does useful work by naming the returned fields (Amount, Currency). However, for a financial-query tool it omits how the optional logins array affects the response shape and any limits on how many accounts can be queried at once.

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% and the single optional 'logins' parameter is documented in the schema itself (agency-token logins, defaults to the token's own account). The description adds nothing about parameter semantics, so the baseline 3 applies.

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 specific verb and resource ('Баланс и финансовая информация аккаунта') and even names the returned fields (Amount, Currency), which is more than most sibling names imply. It does not explicitly differentiate itself from sibling read tools such as get_statistics, but the resource is 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?

No indication of when this tool should be used versus alternatives, no prerequisites, and no note about whether an agency token context changes the call. The only usage hint is buried in the schema, not the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds that results span several targeting dimensions, but says nothing about pagination, default limits, or ordering, which is the behavior an agent would still wonder about.

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?

A single front-loaded sentence that opens with the action and immediately lists what is returned. Efficient, though the trailing category enumeration is somewhat long.

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 7-parameter paginated read with no output schema, the description covers the domain well but omits pagination behavior and how the levels/ad-group/campaign parameters interact. Annotations cover safety, and the schema covers parameter mechanics, so the gap is moderate rather than severe.

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 all seven parameters are already documented in the schema. The description's category list loosely maps to the types enum but adds no syntax or format detail beyond it, making the baseline 3 appropriate.

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 names a specific verb (Получить = Get) and resource (bid adjustments), and scopes it to campaign or ad-group level while enumerating the adjustment families (devices, gender/age, audiences, regions, income, placement). The read verb implicitly separates it from set/add/delete siblings, though it never names them explicitly.

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 states only what is returned, with no indication of when to call this versus add_bid_adjustments/set_bid_adjustments/delete_bid_adjustments or any workflow context such as reading current adjustments before modifying them. Usage is left entirely to inference from the verb.

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

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

Beyond the readOnly/openWorld annotations, the description discloses non-obvious behavior: MCBANNER campaigns come back empty by ID, empty results do not mean an invalid ID, and the GoalId 13 strategy sentinel semantics. These are exactly the caveats that prevent misdiagnosis of a successful call.

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?

Purpose is front-loaded and the field list plus caveats each carry information; nothing is filler. It is somewhat dense and long, but the length is justified by the domain-specific edge cases.

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?

No output schema exists, so the description must carry the return shape, and it does so comprehensively (fields returned, nested PriorityGoals semantics, attribution, counters). Combined with the empty-response and MCBANNER caveats, an agent has everything needed to call and interpret this tool.

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?

Only one parameter and schema coverage is 100%, so the schema already documents campaign_id fully (pattern, decimal string). The description's ID-related notes concern interpreting output (PriorityGoals.Items[].GoalId) rather than adding syntax for the input, so baseline 3 applies.

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 specific verb+resource ('детальная информация о кампании по ID') and then enumerates the returned content (budget, status, dates, stats, UTM, PriorityGoals, Metrica counters, attribution). The 'по ID' scope makes it clearly distinct from list_campaigns in the sibling set.

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 clear context for when results appear empty (MCBANNER campaigns are not returned by the API) and warns that an empty response does not imply a bad ID, which is real usage guidance. It does not, however, explicitly route the agent to list_campaigns to obtain an ID.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read. The description adds only the word 'текущие' (current), which hints the result reflects live state, but says nothing about pagination, result size, or what happens with unknown IDs.

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?

One short, front-loaded sentence with no waste. It is tightly scoped, though its brevity borders on under-specification for a retrieval tool.

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?

With one parameter, 100% schema coverage, and annotations covering the safety profile, the essentials are present. However, with no output schema, the description leaves the agent guessing about the shape and volume of the returned negative-keyword data.

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% and there is a single well-documented parameter, so the baseline is 3. The phrase 'по их ID' merely restates the campaign_ids parameter without adding format or constraint detail beyond 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 states a specific verb and resource ('получить минус-фразы кампаний'), so an agent knows it reads campaign-level negative keywords. It is distinguishable from the sibling set_campaign_negative_keywords, though it never names that sibling explicitly.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g., needing campaign IDs that already exist), and no routing to alternatives such as list_keywords or set_campaign_negative_keywords. Usage is only implied by the verb.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that dictionaries mode returns only the current server time when timestamp is omitted — but omits return shape, limits (e.g. maxItems 50000) or rate-limit behavior.

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?

A single front-loaded sentence that leads with the primary resource set and appends the dictionaries special case. No filler, though cramming three distinct modes into one clause reduces scannability slightly.

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 6-parameter, mode-driven tool with no output schema and no return-value documentation, the description covers the modes but not what the response contains or how field_names interacts with the ID filters. Adequate but leaves meaningful gaps for a polling/change-detection tool.

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 the schema already documents mode, timestamp requirement per mode, and each ID list. The description largely restates the mode=dictionaries behavior rather than adding new semantics, so the baseline of 3 is appropriate.

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 ('Проверить изменения') and the resources covered (campaigns, groups, ads, dictionaries), and explicitly names mode=dictionaries. It is distinguishable from siblings like get_statistics or list_campaigns, though the mapping to the 'objects' mode is left implicit.

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?

Usage is implied: use it to poll for changes since a given time. However, it never says when to prefer this over sibling reads such as get_campaign/get_statistics, nor does it state exclusions or prerequisites (e.g. that it is a change-feed rather than a full fetch).

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

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

Annotations only declare readOnlyHint and openWorldHint. The description adds real behavioral context beyond them: all values are in rubles, what Bid vs Price mean, and the critical caveat that autostrategy campaigns (WB_*, AVERAGE_CPA/CPC) make bidding inapplicable. It does not discuss pagination behavior, which is a minor gap.

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 and front-loaded, leading with what is returned before scoping and caveats. It is long, but nearly every clause carries operational value; the position-range enumeration is the only slightly verbose stretch.

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?

There is no output schema, so the description carries the burden of explaining return fields (Bid, Price, positions, currency) and does so thoroughly, plus it covers the manual-vs-autostrategy prerequisite. Nothing an agent needs to call it correctly 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 baseline is 3, but the description adds meaning the schema does not: the three ID-array parameters are mutually exclusive by level ('отбор по одному уровню'), which tells the agent not to combine keyword_ids, ad_group_ids, and campaign_ids.

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 specific resource and scope: auction pricing (Bid/Price) per position P11–P14 and P21–P24, competitor bids and minimum entry price. It also distinguishes itself from set_keyword_bids and get_strategy by naming them and the condition that separates them.

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?

Explicitly says selection works at one level (keywords, groups, or campaigns), that price is viewable for any campaign but bidding only applies under manual management, and routes the agent to get_strategy to check, noting set_keyword_bids is useless under autostrategies. When-to-use, when-not, and alternatives are all present.

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

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

readOnlyHint and openWorldHint already declare the safe, external-read nature, so the safety profile is covered. The description adds useful domain facts beyond annotations — the magic code 225 = Россия and that with_parents distinguishes same-named cities — but return/pagination behavior is left to be inferred.

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?

Three short, front-loaded fragments with no filler: resource first, then filter hint, then the with_parents behavior. Efficient and easy to scan, though telegraphic rather than fully 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?

For a read-only reference lookup with 100% schema coverage and no output schema, the description supplies enough context (what the regions are, the key code, the special with_parents toggle). Nothing essential to a correct call is missing, though a note on result shape would round it out.

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 all three parameters are already documented in the schema, making 3 the baseline. The description largely restates the with_parents semantics already present in the schema; the 225 = Россия fact is extra context but not tied to a specific parameter.

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 names the resource concretely — a reference of region codes (GeoRegions) — and frames its purpose (для таргетинга), so an agent knows this is a lookup tool rather than a campaign mutator. It does not explicitly contrast itself with any sibling, but the resource is clear enough to disambiguate from the surrounding campaign tools.

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?

Usage is only implied: 'для таргетинга' and 'Фильтр по названию' suggest when the tool is relevant, but there is no explicit when-to-use/when-not and no named alternative (e.g. get_time_targeting or get_campaign). Adequate but leaves the agent to infer the trigger conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only that queries are 'actual' but omits pagination, authentication, response format, or other behavioral traits beyond what annotations provide.

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 a single, front-loaded sentence with no filler or redundancy. Every word contributes to stating the tool's purpose and use case.

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 read-only report tool with fully documented parameters and safety annotations, the description conveys the core purpose. However, it omits usage details and expected output information, and since there is no output schema, more context could have been provided.

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?

With 100% schema description coverage, the schema fully documents all four parameters, including the optional fields list and date formats. The description provides no additional parameter meaning, so the baseline of 3 is appropriate.

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 specific verb (report) and resource (actual search queries) with its analysis purpose, distinguishing it from keyword-management siblings. However, it does not explicitly name alternative tools for related tasks, so it falls short of a 5.

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 gives a clear use case: for analyzing search queries and adding negative phrases. It provides context but does not mention when to use alternatives or any exclusions, so 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is covered structurally. The description adds useful context beyond that: money is returned in rubles, output is TSV, and the backing service is ReportService. It does not disclose limits on campaign count, date-range constraints, or any rate limits.

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?

A single dense sentence with the resource and metric list front-loaded and no filler. The trailing '(ReportService, TSV)' parenthetical is compact and informative, though slightly implementation-flavored for a description.

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?

With no output schema, the description does double duty and partially covers it by listing the metric columns and the TSV format. However, it omits how many campaigns can be queried at once, any date-range limits, and whether results are aggregated or per-day, leaving gaps for a reporting tool.

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% (all four parameters documented, including default fields and the ruble note), so the schema carries the parameter burden. The description's 'расход (руб)' only echoes what the schema already states about currency. Baseline 3 is appropriate.

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 specific verb+resource ('Статистика кампаний за период') and enumerates the metrics returned (показы, клики, расход, CTR, CPC). It is clearly distinguishable from sibling tools like get_campaign or list_campaigns, which manage entities rather than report metrics. No explicit sibling differentiation is needed here since none of the siblings are statistics tools.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g. campaign must exist), and no exclusions. The period and campaign scope are implied only by the required parameters, not by the description text.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description goes further with non-obvious domain behavior: that GoalId in BiddingStrategy can be a service value (13 = key goals, 12 = engaged sessions) and that the Direct API never returns goal names. This is real added context beyond the 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 purpose is front-loaded in the first sentence, followed by dense but relevant detail on return fields and the service-GoalId gotcha. Slightly long for a one-parameter read, but every sentence carries domain value rather than filler.

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?

With no output schema, the description carries the burden of explaining returns and does so with concrete field paths (TextCampaign.PriorityGoals.Items[].GoalId, CounterIds) and the Value-in-rubles detail. Coverage is strong; pagination/error behavior is not addressed but is minor for this call.

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% for the single campaign_id parameter, so the schema already documents it fully. The description adds nothing about the parameter itself, matching the baseline-3 rule when the schema does the work.

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 specific verb ('Получить') and resource (current impression strategy of a text-graphic campaign) and enumerates what comes with it: PriorityGoals, counters, attribution model. An agent can immediately tell this apart from set_strategy and from get_campaign.

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?

Usage is only implied: it reads the current strategy, so it is the read-side counterpart of set_strategy. There is no explicit when-to-use/when-not guidance and no named alternative for the cases where get_campaign would suffice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — no mention of permissions, rate limits, or response shape — but it does scope what the resource contains, which is mild added value.

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?

A single compact sentence with the resource stated first and no filler. It is well front-loaded, though as a fragment it stops short of fully specifying the tool's behavior.

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?

With no output schema, the description usefully enumerates the fields the resource exposes (time zone, weekday hours, hourly coefficients, holidays), effectively standing in for a return-value description. For a one-parameter read-only getter this is close to complete; only the retrieval framing 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 description coverage is 100% with a single documented campaign_id parameter (pattern and format included), so the schema already carries the semantics. The description adds nothing about the parameter, making the baseline 3 appropriate.

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 names a specific resource (campaign time targeting) and enumerates its components: time zone, display hours per weekday, hourly coefficients, and holiday settings. Combined with the get_ prefix it is distinguishable from the sibling set_time_targeting, but the description never states the retrieval action explicitly — it is a noun phrase describing the resource rather than a verb+resource statement.

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?

There is no guidance on when to use this tool versus set_time_targeting or the other campaign getters, and no prerequisites (e.g. needing campaign_id to exist) are mentioned. The read-only nature must be inferred entirely from the name and annotations.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds real behavior beyond that: links are overwritten wholesale, a campaign-level link cascades to all ad groups, and an empty set_ids removes all links. It doesn't mention permission requirements or error behavior, keeping it from a 5.

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?

Three short sentences, front-loaded with the action and scope, then the cascade rule and the clearing rule. Every sentence carries distinct information with zero filler.

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 mutation tool with no output schema, the description covers overwrite semantics, the campaign-to-ad-group cascade, and the clearing case, and annotations cover the safety profile. Gaps remain around permissions and failure behavior, but nothing essential to calling it correctly 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 description coverage is 100%, so the schema already documents set_ids, campaign_ids, ad_group_ids, and dry_run (including the 'empty array clears all' semantics). The description's 'Пустой set_ids очищает привязки' largely restates what the schema says, adding little. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb+resource: replace ('Заменить') the links ('привязки') of shared negative keyword sets ('общих наборов минус-фраз') on campaigns and/or ad groups. That distinguishes it from manage_negative_keyword_shared_sets (manages the sets themselves) and set_campaign_negative_keywords. It stops short of naming those siblings explicitly, so an agent must infer the boundary.

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 gives the key usage semantics (campaign-level link cascades to all its ad groups; empty set_ids clears links), which implies when the tool applies. However, it never states when to prefer this over set_campaign_negative_keywords / set_ad_group_negative_keywords or manage_negative_keyword_shared_sets, so routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that returned items include statuses and text, but says nothing about pagination behavior despite limit/offset parameters, leaving a meaningful gap for a list tool with no output schema.

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?

A single short, front-loaded sentence with no filler. It is efficient, though arguably too terse to earn full marks given the tool's five-parameter surface.

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 five-parameter, zero-required list tool with no output schema and only readOnly/openWorld annotations, the description is minimal. It hints at return content (statuses and text) but omits pagination behavior and the relationship between the states and statuses filters, leaving the agent to rely wholly on the schema.

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 every parameter (limit, offset, states, statuses, ad_extension_ids) is already documented in the schema. The description adds no syntax, format, or filter semantics beyond that, so the baseline of 3 applies.

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 states a specific verb ('Получить') and resource ('уточнения (callouts)'), and the bilingual gloss disambiguates the term. It does not explicitly distinguish itself from the add_ad_extensions/delete_ad_extensions siblings, but the read/list nature is clear from the name and description together.

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 offers no guidance on when to use this tool versus alternatives such as add_ad_extensions, delete_ad_extensions, or the sitelink listers. No prerequisites or exclusions are stated; usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is covered by structured data. The description adds that results are scoped to selected campaigns and enumerates returned fields, which is modest extra context but doesn't discuss pagination or result size limits beyond what the schema covers.

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?

A single short sentence, front-loaded with the resource and scope. Nothing wasted, though the field list is a bit thin for the space allotted.

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 read-only list tool with full schema coverage and annotations covering safety, the description is minimally adequate. It lacks explicit guidance on pagination behavior, expected result volume, or how it relates to sibling list tools, but nothing essential for a correct call 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 description coverage is 100%, so all three parameters (campaign_ids, limit, offset) are already documented in the schema, including pagination semantics for offset. The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

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 verb+resource: lists ad groups of selected campaigns and the fields returned (names, regions, statuses). Clear purpose, though it doesn't explicitly distinguish itself from sibling list tools like list_campaigns or list_ads beyond the resource name itself, which is fairly self-evident.

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?

No when-to-use guidance, no prerequisites, no mention of alternatives. The agent must infer from the name alone that this is the read-side complement to create_ad_group/delete_ad_groups.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses two non-obvious behavioral traits: the result set silently omits ads whose copy is neural-network generated (and no signal of this appears in the response), and the moderation rejection reason surfaces in StatusClarification. This is exactly the kind of context annotations cannot carry, and it warns the agent not to infer absence from the output.

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 front-loaded: the returned fields come first, then the filtering constraint, then the incompleteness caveat. Every sentence carries information, though the paragraph is heavy and the caveat about neural-network ads could be tightened without losing meaning.

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?

With no output schema, the description carries the return-value burden and does so: it names the fields, where the rejection reason lives, and critically warns that the list can be incomplete in a way invisible to the caller. An agent has everything needed to call and correctly interpret the result.

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 already documents limit, offset and ad_group_ids. The description adds a genuine constraint not in the schema: ad_group_ids is the only selector and ad-ID lookup is not supported, which clarifies how the parameter must be used.

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 specific verb+resource (listing ads within ad groups) and enumerates the returned fields (titles, texts, links, statuses, type/subtype, sitelinks, vcard, image). It is clearly distinguishable from write-oriented siblings like manage_ads, moderate_ads and create_text_ad, and from list_ad_groups by its resource scope.

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 clear scoping rules — selection is by group only, not by ad ID, and archived ads are returned alongside active ones — plus a caution to cross-check the Direct UI for completeness. It stops short of explicitly naming a sibling alternative for other lookup modes, but the context for when this tool applies is unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing further — no pagination behavior, no indication of whether multiple filter IDs are combined with AND or OR, and no note on result size.

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?

A single front-loaded sentence with no wasted words; the verb and the filter dimensions arrive immediately.

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 an 8-parameter listing tool with no output schema, the description omits how results are returned, how paging works (the offset/limit pair is only explained inside the schema), and whether supplying no filter IDs is valid. Given no annotations beyond read/open-world, this is under-specified.

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 every parameter (limit, offset, states, and the five ID-array filters) is already documented in the schema. The description's mention of campaign/group/retargeting/interest IDs mirrors the schema rather than extending it, so the baseline 3 applies.

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 specific verb ("Получить") and resource ("условия нацеливания на аудиторию"), plus the four ID dimensions it can be queried by. It does not explicitly name the sibling set_audience_targets, but the get-vs-set distinction is readable from the name and title.

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?

There is no when-to-use guidance, no statement of prerequisites (e.g. at least one filter ID), and no pointer to set_audience_targets for modifications or to list_retargeting_lists for resolving list IDs. Usage must be inferred entirely from the verb.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only that profiles are 'доступные' (available), which hints at access scoping, but does not disclose pagination, rate limits, or return format. With annotations covering the basics, this is a minimal addition. Score 3.

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?

A single sentence with no wasted words, front-loading the verb and resource. Appropriately sized for the tool's simplicity. Score 5.

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 list tool with three optional parameters, no output schema, and annotations covering safety, the description is adequate but minimal. It does not explain pagination or the shape of returned profiles, leaving some gaps. Score 3.

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 all three parameters are already documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 applies.

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 states a specific verb ('Получить') and resource ('доступные профили организаций из Яндекс Бизнеса'), making the tool's purpose clear. It does not explicitly differentiate from sibling tools, but the domain (business profiles) is unique among the siblings. Score 4.

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?

No guidance is provided on when to use this tool versus alternatives or in what contexts. The description only says what it does, not when to invoke it. Score 2.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the description goes beyond by disclosing a non-obvious behavioral boundary: MCBANNER campaigns are absent by API design, not by filter or auth failure — an important trap for an agent. It also discloses currency units and the default projection, though it says nothing about rate limits or result caps beyond the schema.

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?

Four sentences, front-loaded with purpose then progressively adding field behavior and the API-boundary caveat. Each sentence carries information, though the default-field enumeration slightly overlaps the schema text.

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?

With no output schema, the description compensates by stating what is returned by default, how to widen the projection, and which campaigns will never appear. For a 5-parameter, read-only list tool this covers everything an agent needs to invoke it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: budgets are denominated in rubles (relevant to DailyBudget/Funds), the default returned field set, and the purpose of 'fields'. The default-field list is partly duplicated from the schema, keeping it from a 5.

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 specific verb and resource ("Список рекламных кампаний Яндекс.Директ") plus the supported filter dimensions (status and type). The plural 'список' clearly separates it from the singular get_campaign sibling without needing further contrast.

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?

Explains how to operate the tool: default field set applies, and other CampaignFieldEnum fields must be requested explicitly via 'fields'. It also sets expectations that MCBANNER campaigns are never returned. It lacks explicit when-to-use-vs-alternative routing (e.g. vs get_campaign or manage_campaigns), so it stops 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context such as pagination behavior, authentication needs, rate limits, or what happens with large limits/states filters. It only restates the purpose.

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?

A single front-loaded sentence that states the action and resource with no filler, repetition, or wasted words. It is appropriately sized for its scope.

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 six-parameter list tool with no output schema, the description lacks routing information to separate it from manage_dynamic_targets and does not summarize return content or filtering behavior. Although the schema and annotations provide structured details, the description itself is too thin to fully guide selection and invocation.

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 all six parameters (limit, offset, states, ad_group_ids, campaign_ids, dynamic_target_ids) are fully documented in the schema. The description does not mention any parameters or add semantic meaning beyond what the schema provides, warranting the baseline score.

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 specific verb 'Получить' (get) and a clear resource 'условия нацеливания динамических текстовых объявлений' (targeting conditions of dynamic text ads). It does not explicitly differentiate from the sibling manage_dynamic_targets beyond the tool name, but the purpose is otherwise clear.

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?

No guidance on when to use this tool versus manage_dynamic_targets or list_audience_targets. There are no exclusions, prerequisites, or context signals in the description; usage must be inferred entirely from the name and sibling list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about what data is returned (sources, processing statuses, related campaigns), but says nothing about pagination, filtering behavior, or result limits beyond what the schema implies.

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?

A single, efficient sentence with no filler and the resource front-loaded. It is appropriately sized, though minimal enough that it leaves room for additional usage context.

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 read-only list tool with annotations covering safety and 100% schema coverage, the essentials are present. However, with no output schema, the description's brief enumeration of returned fields is thin and pagination behavior (offset/LimitedBy) is left unaddressed.

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 limit, offset, and feed_ids are already fully documented in the schema. The description adds no additional parameter meaning or syntax, matching the baseline 3 when the schema does the heavy lifting.

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 specific verb ('Получить') and resource ('товарные фиды') and enumerates what it returns (sources, processing statuses, related campaigns). No sibling tool covers feeds, so there is no alternative to disambiguate from, but the scope is clear.

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 offers no when-to-use guidance, prerequisites, or conditions. It only describes output content, leaving the agent to infer that this is the unfiltered account-level feed listing on its own.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that: a narrow default field set is returned unless the caller expands it via fields. It does not mention pagination or return shape, but with annotations present a 3 is appropriate.

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 compact sentences with the resource and purpose front-loaded, followed by the field-selection caveat. No wasted words, though the parenthetical field examples are borderline redundant against the enum in the 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?

For a read-only filtered-list tool with full schema coverage and no output schema, the essentials are present. However, it omits pagination/offset behavior and does not clarify how results relate to sibling listing tools, leaving modest gaps.

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 both the fields enumeration and the default field list are already documented in the schema. The description reinforces this by naming KeywordFieldEnum and example fields, but adds little the schema does not already provide. Baseline 3 applies.

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 states a specific verb and resource: keywords ("ключевые фразы") in ad groups, with the returned data types (phrases, bids in rubles, statuses). It is clearly a read/list operation distinguishable from add_keywords/update_keywords, though it does not call out those siblings explicitly.

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?

There is no explicit when-to-use guidance or reference to alternatives. The agent must infer that this is the read counterpart to add_keywords/update_keywords/manage_keywords purely from the verb in the name; the description provides no conditions, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the account-level scoping, with nothing about pagination behavior, result ordering, or that set_ids narrows the result set beyond the schema text.

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?

A single front-loaded sentence with zero filler. It is efficient, though arguably under-specified rather than ideally concise for a listing tool.

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 simple read-only list tool with a fully documented schema and readOnly annotations, the definition is minimally adequate. With no output schema, a note on what a returned set contains would have added value, but nothing essential to invocation 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 description coverage is 100%, so all three parameters (limit, offset, set_ids) are already fully documented in the schema. The description contributes no additional parameter meaning, which is the baseline case.

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 specific verb ('Получить') and resource ('общие наборы минус-фраз аккаунта'), so the agent knows exactly what it retrieves. It does not distinguish itself from the sibling manage_negative_keyword_shared_sets (which likely also lists/manages these sets) or from get_campaign_negative_keywords, leaving some ambiguity about scope.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as the campaign- or ad-group-level negative keyword tools. Usage is only implied by the verb.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, potentially unbounded read. The description adds little beyond restating that it retrieves rules and scope, but doesn't contradict annotations. It fails to disclose pagination limits (though maxItems hints at 10000), rate limits, or output structure.

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 a single, reasonably concise sentence with no wasted words. However, it is under-specified and front-loads only the general purpose, leaving key details (filtering, pagination) to the schema. It's efficient but lacks informative structure.

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 read-only list tool with full schema coverage and no output schema, the description covers the basic purpose but omits important context: that it supports filtering by type and specific IDs, and that it may paginate. Given the sibling tools include update/delete/add variants, more guidance on distinguishing this as the 'list' operation would improve completeness.

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 the schema fully documents all four parameters including limit, types enum, offset, and retargeting_list_ids. The description adds no parameter-specific information, which is acceptable given the high coverage. Baseline 3 is appropriate.

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 states a verb ('Получить') and resource ('условия ретаргетинга и подбора аудитории'), which gives a general sense of retrieval. However, it doesn't differentiate from siblings like list_audience_targets, list_dynamic_targets, or list_negative_keyword_shared_sets, all of which are also list operations. The scope is vague about what 'область применения' means in practice.

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?

No guidance on when to use this tool versus alternatives like list_audience_targets or list_dynamic_targets. There's no mention of prerequisites, pagination behavior, or when filtering by types is appropriate. The agent is left to infer usage context entirely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no note on pagination behavior, result volume, or permissions. It does not contradict the annotations, but contributes very little behavioral context.

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?

A single short sentence that is front-loaded with the action and contains no filler. It is efficient, though its brevity is partly the source of the missing usage and behavioral detail.

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 read-only list tool with zero required parameters, fully documented schema, and no output schema, the description is minimally sufficient. Annotations cover the safety profile, but nothing addresses result ordering or pagination beyond the offset parameter's own schema text.

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 limit, offset, and sitelink_set_ids are fully documented in the schema itself. The description's 'all or selected sets' mirrors the optional sitelink_set_ids filter but adds no syntax or format detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb ('Получить') and resource ('наборы быстрых ссылок') and clarifies the all-vs-selected scope. It separates itself from write operations like set_sitelinks/delete_sitelinks by verb alone, but never explicitly names a sibling, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus alternatives such as list_ad_extensions or set_sitelinks, no prerequisites, and no conditions. The 'all or selected' phrasing hints at filtering but is a description of scope, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the consumer context (set_time_targeting, create_campaign) and the filter capability; it does not cover the 50-item default limit behavior, pagination, or result size, which would be valuable given the maximum of 500.

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 short sentences, front-loaded with the resource and followed by the filter capability. Efficient, though the consumer list could be integrated more tightly and the sentence stops short of stating the retrieval action.

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 simple two-parameter read-only lookup with no output schema, the essentials (resource, filter, consumers) are present. But the description omits the default limit of 50 and the maximum of 500, which materially affect how an agent should call it, and does not clarify its relationship to get_regions.

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%, with both limit (default 50, max 500) and search (substring, case-insensitive, examples) fully documented in the schema. The description merely echoes the filter capability ('Фильтр по коду или названию') without adding format or syntax beyond what the schema already provides.

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 specific resource (time zone reference list) and its consumers (set_time_targeting, create_campaign), which helps position it against siblings like get_regions. However, it describes itself as a 'справочник' (reference/directory) rather than clearly stating the verb (list/retrieve), leaving the action implicit.

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?

Naming set_time_targeting and create_campaign implies this is a lookup to support those operations, giving useful context. But there is no explicit when/when-not guidance, no mention of the read-only nature in prose, and no differentiation from get_regions, which is a closely related sibling.

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

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

With readOnlyHint=true and openWorldHint=true, safety is covered. The description adds a key behavioral constraint: vCards cannot be created via API and must be created in the Direct interface. It does not detail pagination or return behavior.

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, front-loaded with purpose and retrieval modes, followed by the creation limitation. No redundant text; every sentence earns its place.

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 list tool with no output schema and read-only annotations, the description covers purpose, retrieval modes, and creation limitation. It lacks return format or pagination details, but the schema already handles all parameters.

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 the schema documents all four parameters including limit/offset and the ID arrays. The description mentions IDs and campaign associations in prose but adds no syntax or format beyond what the schema already provides. Baseline score of 3 applies.

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 specific verb ('Получить'/'найти') and resource ('виртуальные визитки'), and clarifies the two retrieval modes (by ID or via campaign ads). It does not name sibling tools to differentiate, but the resource is distinct.

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?

Explains two retrieval paths (by ID or via campaign ads) and explicitly notes that creation is not possible via API, directing the agent to the Direct interface. This gives clear when-to-use context and a when-not for creation, though it does not compare against sibling list tools.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so safety expectations are covered structurally. The description adds only that add operations carry base64 data, but does not disclose that delete is irreversible, what dry_run does behaviorally, or other operational traits beyond what annotations and schema already provide.

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 a single compact sentence that front-loads the core operations before the add-specific detail. There is no wasted wording or redundant preamble.

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 rich schema coverage and destructive/open-world annotations, the description is minimally adequate: it identifies the actions and notes the base64 requirement for add. However, it provides no usage guidance, no return-value context for get, and no behavioral notes on delete irreversibility or dry_run.

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 the input schema already documents all 7 parameters, including action, images, filters, dry_run, and pagination. The description repeats that add data is base64, which the schema also states, adding no extra semantic meaning.

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 states specific verbs (load, retrieve, delete) and a specific resource (ad images / AdImages), so an agent can distinguish it from sibling tools such as manage_ads or manage_campaigns. It covers all three action modes in the tool name and schema.

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 does not say when to prefer this tool over alternatives like manage_ads or list_ads, nor does it state when not to use it. It only notes that add requires base64 data, which is an operational detail rather than usage guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds per-action specificity — that only 'delete' is irreversible while suspend/archive are presumably reversible — which is genuinely useful beyond the blanket destructiveHint, but it says nothing about preconditions, quotas, or partial-failure behavior across multiple ad_ids.

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 terse fragments, action list front-loaded and the irreversible delete warning placed last for emphasis. Nothing is wasted, though it is arguably too sparse given the destructive, multi-action nature of the tool.

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 destructive multi-action tool with no output schema, the description is minimum viable: it names the actions and the one irreversible case. It omits dry_run's value as a preview mechanism (only in the schema), batch-size limits, and failure semantics, so an agent must lean entirely on structured fields.

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%: the action enum, ad_ids pattern, and dry_run semantics (including that reads still occur) are all documented in the schema itself. The description merely repeats the action list, adding no format or interaction detail beyond what the schema provides, so the baseline 3 is correct.

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 clear verb+resource ('Действие над объявлениями') and enumerates the six operations, so the agent knows this is a multi-action mutation tool. However it never distinguishes itself from the sibling 'moderate_ads', which overlaps with the 'moderate' action listed here, leaving an ambiguity an agent must resolve on its own.

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?

There is no explicit when-to-use guidance and no routing to alternatives: nothing says when to use manage_ads.moderate versus the standalone moderate_ads tool, and nothing clarifies whether the batch ad_ids should be handled here rather than via list_ads. The irreversibility warning is a caution, not usage guidance.

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

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

Annotations already flag destructiveHint=true, so the warning is partly pre-covered, but the description goes beyond them: it pinpoints that delete is the irreversible action and that campaigns with accumulated statistics cannot be deleted at all. This is genuine operational context not derivable from the annotation 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 short sentences: the action list first, then the destructive-constraint warning with a warning glyph. Zero filler and the riskiest information is deferred only slightly and clearly marked.

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 3-parameter mutation tool with full schema coverage, annotations, and no output schema, the definition covers purpose and the key destructive constraint. It does not mention dry_run semantics or batch size limits, which are left entirely to the schema, but nothing critical 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 description coverage is 100%, so action enum, campaign_ids pattern/limits and dry_run are all documented in the schema. The description only re-states that delete is irreversible, adding no new parameter detail; baseline 3 applies.

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?

Names a specific verb set (suspend/resume/archive/unarchive/delete) applied to the resource 'кампании', so the agent knows exactly which operations are covered. It does not differentiate itself from siblings such as update_campaign or create_campaign, though the enumerated action list makes overlap unlikely.

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 implicitly tells the agent to use archive instead of delete when a campaign has accumulated statistics — a real routing rule. However it gives no guidance on when to pick this bulk-action tool over update_campaign, list_campaigns, or get_campaign, and no preconditions for the other actions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that and the action enum: it omits the irreversibility of delete (only stated in the schema), the dry_run preview behavior, and any permission or rate-limit context.

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?

A single, well-formed sentence with no filler, and the operation list is front-loaded. It is efficient, though the extremely terse packaging leaves little for the agent to anchor on beyond the verb list.

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 multi-action tool with five parameters and action-conditional inputs, the description does not explain which parameters pair with which action, though the schema and annotations largely fill that gap and there is no output schema to worry about. Adequate but with a clear gap around action-to-parameter coupling.

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%, with every parameter, enum and constraint documented inline, so the schema does the heavy lifting and baseline 3 is appropriate. The description adds no additional meaning about how bids, targets or dynamic_target_ids are conditioned on the chosen action.

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 names a clear resource (динамические цели) and enumerates the concrete verbs (create, bid-change, stop, resume, delete) it supports, so an agent immediately knows this is the mutating counterpart to list_dynamic_targets. It is essentially the natural-language form of the action enum, so it does not distinguish itself from siblings beyond that, but the purpose is 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?

No when-to-use guidance is given: there is no mention of picking this over manage_campaigns, nor of the fact that action-specific arguments (bids for set_bids, targets for add, dynamic_target_ids for suspend/resume/delete) must be supplied. The description offers no context or prerequisites for correct invocation.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is largely covered. The description adds the useful '⚠️ delete is irreversible' warning, but says nothing about the dry_run preview path or bulk/atomicity behavior, which would be valuable for a destructive batch operation.

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?

Extremely front-loaded single sentence: resource, operations, then the irreversibility warning. Nothing wasted, though it is arguably under-specified rather than merely concise.

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 destructive 3-param mutation with no output schema, the description covers the operations and the irreversible-delete caveat but omits the dry_run safety valve and any indication of scope or auth requirements. Adequate but with clear gaps.

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 the schema already documents keyword_ids, action enum and dry_run semantics. The description merely restates the action values and does not add format, ID-source or dry_run guidance beyond the schema baseline.

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 clear resource (keywords) plus the three concrete operations (suspend/resume/delete), which is far more than a tautology. It does not, however, distinguish itself from near-neighbors like update_keywords, set_keyword_bids or add_keywords, so an agent must infer it is the state-change tool.

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?

No when-to-use or when-not-to-use guidance, and no alternatives named. The reader must infer from the verb list alone that this is for lifecycle state changes rather than edits or lots of other keyword tools in the sibling set.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, and the description adds nothing beyond them — it does not mention that delete is irreversible, what dry_run does, or any account/permission implications. Useful behavioral detail (dry_run semantics, irreversibility) lives only in the schema descriptions, not the prose.

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?

A single front-loaded sentence with no filler, stating the resource and the three supported operations. It is efficient, though arguably too terse for a destructive multi-action tool.

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 5-parameter destructive mutation with no output schema, one sentence is thin: it omits the conditional required parameters (set_ids for delete, add_sets for add, update_sets for update) and the dry_run safety valve. The rich schema and annotations partially compensate, leaving it adequate but incomplete.

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%: action, dry_run, set_ids, add_sets and update_sets are each documented in the schema, including conditional requirements. The description adds no parameter-level meaning, so the baseline 3 applies.

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 names a specific verb triple (создать/изменить/удалить) and a specific resource (общие наборы минус-фраз аккаунта), which the agent can distinguish from sibling list_negative_keyword_shared_sets (read-only) and link_negative_keyword_sets (linking). It does not, however, explicitly reference any sibling tool to sharpen the boundary.

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 states no conditions for when to use shared sets versus the campaign- or ad-group-level negative keyword tools (set_campaign_negative_keywords, set_ad_group_negative_keywords). The only routing signal is the action enum buried in the schema, so the agent gets no explicit when-to-use guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=true, so the mutation and idempotency profile is covered without the description. The description adds nothing beyond that: it does not say what moderation triggers, whether it is reversible, what authorization or account state is required, or how partial failures across a batch are handled.

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?

It is a single short sentence, but its brevity comes from duplication of the title rather than editing — it earns almost nothing on its own. There is no front-loaded constraint or behavioral detail to justify the minimalism.

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 bulk mutation tool accepting up to 10,000 IDs with no output schema, the description should at least explain what moderation means operationally and how results are reported. Neither is present, leaving a significant gap for an agent deciding whether to invoke it.

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 both ad_ids and dry_run are fully documented in the schema, including the 10,000-item cap and the dry-run semantics. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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 gives a clear verb+resource ('отправить объявления на модерацию'), but it is essentially a verbatim restatement of the title and adds no scope or differentiation. An agent cannot tell from the text how this relates to siblings like manage_ads or update_text_ad, which also touch individual ads.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as manage_ads. The 'выбранные' (selected) wording lightly implies the caller must first pick ad IDs, but nothing routes the agent between this tool and its siblings.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description usefully augments this by spelling out the destruction semantics ('прежние фразы теряются', empty array clears) and the side effect that add/remove read the current list itself, i.e. an extra API call. This adds genuine context beyond the structured fields, though it omits auth/permission or rate-limit information.

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?

Three sentences with the purpose front-loaded and the critical destruction warning prominent. Minor redundancy: the add-vs-replace point is made twice (once enumerating modes, once in the closing sentence), which slightly dilutes conciseness.

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 mutation tool with no output schema, the description covers the key behaviors an agent needs: mode semantics, list-preservation implications, and the self-reading behavior of add/remove. The dry_run parameter is left to the schema, which is acceptable given the otherwise complete operational picture.

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%, and the schema's own mode description already details replace/add/remove plus normalization rules, so the schema carries the burden. The description largely restates the mode behavior rather than extending it, landing at the baseline of 3 for high-coverage schemas.

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 states a specific verb+resource (negative keywords) and scopes it explicitly to 'на уровне группы объявлений', which implicitly distinguishes it from campaign-level siblings like set_campaign_negative_keywords. It is clear what the tool does, though it never names the sibling alternative explicitly, so sibling differentiation rests on the level qualifier rather than a stated contrast.

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 gives strong when-to-use guidance at the mode level: replace wipes the list, add appends, remove deletes, and it explicitly warns that to add to an existing set you must use add because replace with a single phrase will erase the rest. It does not, however, address when to prefer this tool over its siblings (e.g., campaign-level or shared-set tools), so tool-level alternative guidance is absent.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds little beyond restating the operations; it omits useful behavioral context such as the irreversibility of delete and the existence of dry_run, which the schema alone carries.

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?

A single compact sentence with the core operations front-loaded and no filler. It is efficient, though its brevity contributes to the gaps noted elsewhere.

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 destructive, multi-action mutation tool with no output schema, the description is minimally adequate: it lists the operations but does not explain the action-to-payload coupling, the dry_run verification option, or irreversibility. Annotations cover safety, but the workflow guidance remains thin.

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 the schema fully documents all five parameters (including action, dry_run, targets and bids). The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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 names a specific resource (аудиторные цели) and enumerates the concrete operations (add, stop, resume, delete, change bids), so an agent understands the tool's scope. It does not explicitly distinguish itself from the sibling list_audience_targets, but the write-oriented wording implies it.

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?

There is no explicit when-to-use/when-not guidance, no prerequisites, and no reference to alternatives like list_audience_targets. Usage is only implied by the enumerated action verbs, and the action-to-required-parameter coupling is left entirely to the schema.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context beyond that: it says nothing about dry_run preview behavior, batch limits, validation semantics, or what happens to omitted fields.

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?

A single front-loaded sentence with no filler or redundancy. It is appropriately terse for the tool, though its brevity means it is also doing little structural work beyond naming the operation.

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 input schema and annotations are thorough, and no output schema exists, so the description need not explain return values. However, for a mutation tool with a dry_run preview and bulk array of up to 1000 adjustments, the description omits important usage context, making it merely minimum viable.

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%, with rich parameter docs for dry_run, adjustment_id, and the bid_modifier range (0–1300). The description mentions ID and coefficients but adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline of 3 applies.

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 specific verb (Изменить) and resource (коэффициенты существующих корректировок) scoped by ID. The word 'существующих' distinguishes it from add_bid_adjustments and delete_bid_adjustments, though it does not name those alternatives explicitly.

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?

Implies use only when existing adjustment IDs are known and their coefficients need changing. It gives no explicit when-not guidance and never mentions the sibling tools (add_bid_adjustments, delete_bid_adjustments) or the dry_run preview option, leaving selection between related tools to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this with concrete consequences ('прежние фразы теряются', 'пустой массив очищает'). It adds real value beyond the annotation flags, though it does not discuss permissions or rate limits.

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?

Front-loads the resource and scope, then concentrates on mode semantics. Slightly repetitive with the schema's mode description, but every sentence is relevant and no filler.

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 destructive mutation tool with annotations and no output schema, the description covers mode behavior, data loss, and the read-before-write nuance well. Permissions/response details are not covered but are not critical here.

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% and the schema description already documents each mode exhaustively, so the baseline is 3. The description's mode explanation largely restates the schema, adding only the worked example about a single-phrase replace.

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 specific verb+resource (setting campaign-level negative keywords) and scopes it with 'на уровне кампании', which distinguishes it from the ad-group sibling. It does not name the alternative tool explicitly, so it falls just short of a 5.

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?

Explicitly distinguishes replace vs add vs remove, tells the agent it need not pre-read the list, and warns that replace with one phrase erases the rest and that add is required to append. The condition selecting each mode is spelled out, so nothing is left to inference.

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

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

The description discloses a non-obvious silent-no-op failure mode under autostrategy, which is exactly the behavioral context annotations cannot convey, and it is consistent with readOnlyHint=false and idempotentHint=true. It stops short of covering permissions/auth requirements or confirmation behavior, so not a full 5.

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?

Front-loaded with purpose, then the key behavioral caveat, then the prerequisite chain in a tight, readable sequence. Every sentence earns its place; only slight density in the final clause keeps it from a 5.

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 mutation tool with no output schema, it covers purpose, the critical when-it-does-nothing condition, and the prerequisite workflow. It does not describe what partial parameter combinations do or confirmation of applied bids, a minor gap.

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 the schema already documents bid, context_bid, keyword_ids, ad_group_ids, campaign_ids and dry_run. The description's 'поиск/сети, в рублях' and level scope add only marginal meaning beyond the schema, so the baseline 3 applies.

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 specific verb (установить) plus resource (ставки) with explicit scope: phrase/group/campaign level, search/network, rubles. The mention of manual vs. auto strategy context and the prerequisite tools clearly separates it from siblings like set_strategy and set_bid_adjustments.

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-to-use ('работает только при ручном управлении ставками') and when-not (autostrategy assigns bids itself; the call succeeds but has no effect on impressions). It also routes the agent through prerequisites: get_strategy first, then get_keyword_auction.

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

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

Goes well beyond the annotations: it warns that changing goals restarts strategy training (⚠️), that replace is lossy ('прежние цели теряются', empty array clears), and that the server reads the current list itself. These are exactly the destructive-behavior details the destructiveHint annotation cannot convey.

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?

Front-loads purpose, then layers mode semantics, the destructive pitfall, and the training-restart warning. Dense and mostly waste-free, though the mode explanation is somewhat redundant with the schema and could be trimmed.

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 destructive mutation tool with no output schema, the description covers purpose, per-mode behavior, destructive edge cases, a training-restart side effect, and supported campaign types. An agent has everything needed to invoke it correctly and safely.

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. The description adds real value on top: it spells out the add-vs-replace pitfall for mode and clarifies the service GoalId semantics (13 for maximum conversions). It does not cover dry_run or the goal_id pattern, leaving the schema to do that work.

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 precise verb and resource: 'Задать цели стратегии кампании (PriorityGoals) и их ценность в рублях', and explains what those goals are for (the autostrategy optimizes bids by them). It also names supported campaign types, which distinguishes it from the broader set_strategy sibling.

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 conditional guidance per mode and an actionable exclusion: use add to append because 'replace с одной целью сотрёт остальные'. It also lists supported campaign types. It stops short of naming when this tool should be chosen over set_strategy, so it is strong context rather than full alternative routing.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the write/external-effect nature is already covered. The description adds the 1–8 cardinality constraint and the returned set ID, which is useful, but adds nothing about account mutation scope, dry_run support, or whether an existing set is replaced — and it contradicts nothing.

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 short sentences with zero padding, front-loading the create action and ending with the return value. Efficient, though it is so terse that it omits guidance a mutation tool would benefit from.

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 simple two-parameter mutation tool with a fully documented schema, the description covers the action, the cardinality bound, and the return value (no output schema exists, so naming the returned ID matters). Missing only workflow context and any note that dry_run validation is available.

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%: both parameters, including nested title/href/description fields and the dry_run flag, are documented inline. The description only restates the 1–8 range already expressed by minItems/maxItems, so it does no work beyond 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?

States a specific verb and resource: 'Создать новый набор из 1–8 быстрых ссылок' (create a new set of 1–8 sitelinks), and notes the returned set ID for binding to an ad. It is clearly distinguishable from list_sitelinks and delete_sitelinks by the verb, though those siblings are never named.

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?

No explicit when-to-use guidance and no alternatives named. The phrase 'Возвращает ID набора для привязки к объявлению' hints at the create-then-bind workflow, but the agent gets no condition telling it why to pick this over add_ad_extensions or manage_ads.

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