Skip to main content
Glama
Pavelsiba

yandex-direct-mcp-plus

by Pavelsiba

Изменить стратегию кампании

set_strategy
Idempotent

Change a Yandex.Direct text and graphic campaign's search and network bidding strategy, including manual, max clicks, average CPC/CPA, or pay-per-conversion, with ruble prices and Metrica goal IDs.

Instructions

Изменить стратегию текстово-графической кампании: ручная, максимум кликов, средняя цена клика или конверсии, оплата за конверсию. Цены — в рублях, цель Метрики — goal_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNotrue — ничего не менять: проверить параметры и вернуть тела запросов, которые ушли бы в Директ. Чтение при этом выполняется.
goal_idNoID цели Метрики для AVERAGE_CPA, PAY_FOR_CONVERSION и WB_MAXIMUM_CONVERSION_RATE; для оплаты за конверсию обязателен. Для WB_MAXIMUM_CONVERSION_RATE допустимо служебное 13 — оптимизация по ключевым целям кампании (PriorityGoals); Директ принимает его, только если в PriorityGoals есть цель, кроме 12 «Вовлечённые сессии»; сами цели задаёт set_priority_goals
average_cpaNoСредняя цена конверсии в рублях; обязательна для AVERAGE_CPA
average_cpcNoСредняя цена клика в рублях; обязательна для AVERAGE_CPC
bid_ceilingNoМаксимальная ставка в рублях для WB_MAXIMUM_CLICKS, WB_MAXIMUM_CONVERSION_RATE и AVERAGE_CPA
campaign_idYesID текстово-графической кампании
search_typeYesСтратегия на поиске: HIGHEST_POSITION (ручная), WB_MAXIMUM_CLICKS, WB_MAXIMUM_CONVERSION_RATE (максимум конверсий за недельный бюджет), AVERAGE_CPC, AVERAGE_CPA, PAY_FOR_CONVERSION или SERVING_OFF
network_typeYesСтратегия в сетях: NETWORK_DEFAULT (по настройкам поиска), MAXIMUM_COVERAGE, WB_MAXIMUM_CLICKS, WB_MAXIMUM_CONVERSION_RATE, AVERAGE_CPC, AVERAGE_CPA, PAY_FOR_CONVERSION или SERVING_OFF
conversion_priceNoЦена конверсии в рублях для PAY_FOR_CONVERSION: списывается за конверсию, а не за клик
weekly_spend_limitNoНедельный бюджет в рублях; обязателен для WB_MAXIMUM_CLICKS и WB_MAXIMUM_CONVERSION_RATE, для остальных автостратегий необязателен
network_limit_percentNoДоля расходов в сетях для NETWORK_DEFAULT, проценты

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.0
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "true — ничего не менять: проверить параметры и вернуть тела запросов, которые ушли бы в Директ. Чтение при этом выполняется.",
      +  "type": "boolean"
      +}
  2. First observedv1.6.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare a write operation (readOnlyHint=false) that is idempotent and open-world, so the safety profile is covered. The description adds only that prices are in rubles and goal_id refers to a Metrica goal — both of which are already restated in the schema — while omitting that the call replaces the existing strategy wholesale.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and its resource, with no filler. It is efficient, though it spends most of its length listing values the enum already enumerates.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool the description is thin: it omits return behavior (no output schema exists) and the conditional dependencies between parameters, relying almost entirely on the schema for correctness. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter documentation baseline is 3. The description's mentions of 'Цены — в рублях' and goal_id duplicate what the schema already states and add no additional syntax or constraint detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Изменить стратегию текстово-графической кампании') and enumerates the strategy families (ручная, максимум кликов, цена клика/конверсии, оплата за конверсию). It scopes the tool to text-graphic campaigns, which helps separate it from campaign-level tools, but never explicitly differentiates itself from the read-side sibling get_strategy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to use this tool versus get_strategy or set_priority_goals, nor what prerequisites (e.g. an existing goal or PriorityGoals) must be met. Usage is only inferable from the tool name and schema.

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