Skip to main content
Glama
askads

Yandex Direct MCP

by askads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Добавить корректировку ставок

add_bid_modifier

Adds bid adjustments to a Yandex Direct campaign or ad group for mobile, desktop, demographics, retargeting, and regional targeting.

Instructions

Добавляет корректировку ставок на кампанию или группу объявлений. Значения BidModifier — проценты по правилам API (например, 0–1300), а не деньги. API принимает в одном элементе BidModifiers только один тип корректировки, поэтому каждый переданный тип (mobile, desktop, demographics, retargeting, regional) уходит отдельным элементом в одном вызове bidmodifiers/add, в этом порядке. Каждая запись AddResults помечена полем Type (MOBILE_ADJUSTMENT, DESKTOP_ADJUSTMENT, DEMOGRAPHICS_ADJUSTMENT, RETARGETING_ADJUSTMENT, REGIONAL_ADJUSTMENT): типы создаются независимо, при частичной ошибке повторять только типы с Errors. Внутри одного типа (массивы demographics/retargeting/regional) API создаёт всё или ничего.

Input Schema

NameRequiredDescriptionDefault
mobileNoКорректировка для мобильных.
desktopNoКорректировка для десктопа.
regionalNoКорректировки по регионам.
adGroupIdNoId группы объявлений (либо это поле, либо campaignId).
campaignIdNoId кампании (либо это поле, либо adGroupId).
retargetingNoКорректировки по ретаргетингу.
client_loginNoЛогин клиента агентства или кабинета в управлении (из list_clients). Если не указан — YANDEX_DIRECT_LOGIN из конфигурации, а без него собственный аккаунт токена.
demographicsNoКорректировки по демографии.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • addedInput schema / properties / client_login
      Added value: +{
+  "description": "Логин клиента агентства или кабинета в управлении (из list_clients). Если не указан — YANDEX_DIRECT_LOGIN из конфигурации, а без него собственный аккаунт токена.",
+  "pattern": "^[A-Za-z0-9][A-Za-z0-9._@-]{0,99}$",
+  "type": "string"
+}
  2. Changed9 schema fields changedv1.5.1
    • changedInput schema / properties / adGroupId / description
      Previous value: -"Target ad group id (use this OR campaignId)."New value: +"Id группы объявлений (либо это поле, либо campaignId)."
    • changedInput schema / properties / campaignId / description
      Previous value: -"Target campaign id (use this OR adGroupId)."New value: +"Id кампании (либо это поле, либо adGroupId)."
    • changedInput schema / properties / demographics / description
      Previous value: -"Demographic bid adjustments."New value: +"Корректировки по демографии."
    • changedInput schema / properties / desktop / description
      Previous value: -"Desktop bid adjustment."New value: +"Корректировка для десктопа."
    • changedInput schema / properties / mobile / description
      Previous value: -"Mobile bid adjustment."New value: +"Корректировка для мобильных."
    • changedInput schema / properties / mobile / properties / os / description
      Previous value: -"Limit to IOS or ANDROID."New value: +"Ограничить IOS или ANDROID."
    • changedInput schema / properties / mobile / properties / percent / description
      Previous value: -"Adjustment percent."New value: +"Процент корректировки."
    • changedInput schema / properties / regional / description
      Previous value: -"Regional bid adjustments."New value: +"Корректировки по регионам."
    • changedInput schema / properties / retargeting / description
      Previous value: -"Retargeting bid adjustments."New value: +"Корректировки по ретаргетингу."
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=false) by disclosing the percentage domain (0–1300, not money), the one-type-per-element API constraint and the deterministic emission order, the Type field stamping each AddResults entry, and precise partial-failure semantics (retry only the types with Errors) versus all-or-nothing within a single type.

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?

Four dense sentences, all front-loaded and all load-bearing: purpose, value semantics, request shaping, response/error handling. Slightly compression-heavy, but nothing is redundant.

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

Completeness4/5

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

Given 8 optional params, nested objects and no output schema, the description covers what a caller most needs: value units, how the payload is split, and how to interpret and retry from AddResults. The only remaining gap is that return-shape detail is described only enough to explain retry, and the campaignId/adGroupId either-or is left to the schema.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds genuine meaning on top: percent values follow API percentage rules (0–1300) rather than currency, and it enumerates the five type keys (mobile, desktop, demographics, retargeting, regional) mapped to their adjustment types. It doesn't clarify the campaignId/adGroupId mutual exclusion that the schema hints at.

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?

Opens with a precise verb+resource in the imperative ('Добавляет корректировку ставок на кампанию или группу объявлений') and names the underlying API method (bidmodifiers/add), so an agent knows exactly what is created. However, it never contrasts itself with the sibling set_bid_modifiers or delete_bid_modifiers, leaving the add-vs-overwrite distinction implicit.

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

Usage Guidelines3/5

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

Usage is only implied through the mechanics described (one modifier type per element sent as separate items in a single call, in that order). There is no explicit statement of when to call this versus set_bid_modifiers, which in the sibling list is the obvious alternative for the same resource.

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

Deploy Server

Other Tools