Skip to main content
Glama
Sign In
Yandex Direct MCP

Yandex Direct MCP

by askads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Изменить минус-фразы

update_negative_keywords
Destructive

Add, remove, replace, or clear negative keywords in one Yandex Direct campaign or ad group. Reads the current list for add/remove, prevents duplicates, and reports before/after counts.

Instructions

Меняет минус-фразы одной кампании или одной группы объявлений. API хранит список целиком и при записи заменяет его, поэтому действие задаётся явно:

  • add — дописать фразы к текущим. Инструмент читает текущий список (campaigns/get или adgroups/get) и записывает объединённый (update): два вызова API. Уже имеющиеся фразы не дублируются.

  • remove — убрать указанные фразы из текущего списка. Тоже чтение + запись.

  • replace — записать ровно переданный список вместо текущего, без чтения. Пустой список здесь не принимается — для очистки есть clear.

  • clear — удалить все минус-фразы (отправляется null). Фразы сравниваются без учёта регистра и лишних пробелов — так же склеивает их сам API; морфологию и порядок слов инструмент не учитывает. Если add/remove ничего не меняют, записи нет (changed: false). Ответ: before/after — число фраз до и после, added/alreadyPresent или removed/notFound — что именно произошло. Между чтением и записью нет блокировки: правка того же списка в интерфейсе в эту секунду будет перезаписана. Ограничения API: фраза без минуса в начале, до 7 слов, слово до 35 символов; суммарно до 20 000 символов на кампанию и 4096 на группу — нарушения API вернёт ошибкой по объекту. Минус-фразы кампании и группы действуют вместе.

Input Schema

NameRequiredDescriptionDefault
actionYesadd, remove, replace или clear — см. описание инструмента.
phrasesNoМинус-фразы без ведущего минуса, например ["бесплатно", "!скачать"]. Не передаётся для clear.
adGroupIdNoId группы объявлений (либо это поле, либо campaignId).
campaignIdNoId кампании (либо это поле, либо adGroupId).
client_loginNoЛогин клиента агентства или кабинета в управлении (из list_clients). Если не указан — YANDEX_DIRECT_LOGIN из конфигурации, а без него собственный аккаунт токена.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description explains that the API stores the entire list and replaces it on write, which actions require a read before write, and that no write occurs if add/remove changes nothing. It also discloses race conditions, normalization behavior, response fields, and API constraints, which is unusually rich behavioral context for a destructive mutation tool.

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

Conciseness5/5

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

The description is long but appropriately dense for a destructive tool with four action modes and several API quirks. The purpose is front-loaded, and the action list is organized so an agent can scan the relevant behavior before invoking.

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

Completeness5/5

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

Given the mutation complexity, annotations, and absence of an output schema, the description is complete enough to invoke correctly. It covers action semantics, return shape, constraints, race conditions, and identifier context without needing to defer to an output schema.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds substantial meaning: it explains each action's effect, why phrases must omit the leading minus, how add/remove compare phrases, and the API limits on phrase length and total characters. It also clarifies that phrases are omitted for clear and that campaign and ad group negative keywords act together.

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

Purpose5/5

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

The first sentence states a specific verb and resource: changing negative keywords for one campaign or ad group. It also immediately frames the four action modes, making the tool's distinct purpose clear against sibling keyword-management tools.

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

Usage Guidelines4/5

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

The description gives strong internal guidance for choosing among add, remove, replace, and clear, including the explicit rule that replace cannot take an empty list and clear must be used instead. It does not explicitly differentiate from sibling tools such as keyword_action, but the negative-keyword scope is clear.

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