Skip to main content
Glama
askads

Yandex Direct MCP

by askads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Прямой вызов API Яндекс Директа

raw_request
Destructive

Call any Yandex Direct API v5 service or method directly when no dedicated tool exists; read methods run freely, while write methods require confirmWrite=true.

Instructions

Универсальный запрос: вызывает напрямую любой сервис или метод API Яндекс Директа v5 (например service "bidmodifiers", method "get"). Нужен для сервисов, у которых нет отдельного инструмента. Деньги — в микроединицах (без конвертации). Методы чтения (get/has/check) выполняются свободно; любой другой метод считается записью и требует confirmWrite=true.

Input Schema

NameRequiredDescriptionDefault
methodYesМетод API, например get, add, update, delete, set, toggle, checkCampaigns.
paramsNoОбъект params для метода — как есть.
serviceYesПуть сервиса строчными буквами, например campaigns, bidmodifiers, sitelinks, adextensions, changes, keywordsresearch.
client_loginNoЛогин клиента агентства или кабинета в управлении (из list_clients). Если не указан — YANDEX_DIRECT_LOGIN из конфигурации, а без него собственный аккаунт токена.
confirmWriteNoДолжен быть true для запуска метода записи (всё, кроме get/has/check).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.11.0
    • changedInput schema / properties / service / description
      Previous value: -"Путь сервиса строчными буквами, например campaigns, bidmodifiers, sitelinks, vcards, changes, keywordsresearch."New value: +"Путь сервиса строчными буквами, например campaigns, bidmodifiers, sitelinks, adextensions, changes, keywordsresearch."
  2. 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"
+}
  3. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / confirmWrite / description
      Previous value: -"Must be true to run a write method (anything other than get/has/check)."New value: +"Должен быть true для запуска метода записи (всё, кроме get/has/check)."
    • changedInput schema / properties / method / description
      Previous value: -"API method, e.g. get, add, update, delete, set, toggle, checkCampaigns."New value: +"Метод API, например get, add, update, delete, set, toggle, checkCampaigns."
    • changedInput schema / properties / params / description
      Previous value: -"Raw params object for the method."New value: +"Объект params для метода — как есть."
    • changedInput schema / properties / service / description
      Previous value: -"Lowercase service path, e.g. campaigns, bidmodifiers, sitelinks, vcards, changes, keywordsresearch."New value: +"Путь сервиса строчными буквами, например campaigns, bidmodifiers, sitelinks, vcards, changes, keywordsresearch."
  4. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, readOnlyHint=false and non-idempotent, so the description doesn't need to restate danger; instead it contributes real behavioral detail: the read-vs-write classification (get/has/check vs everything else), the confirmWrite gate, and that monetary values are in micro-units with no conversion. It doesn't cover error behavior, rate limits, or payload limits of the raw endpoint, which for an open-world passthrough would be valuable.

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?

Four short sentences, front-loaded with the verb and scope, then the carve-out for dedicated tools, then the two facts (micro-units, write gating) that most affect correctness. Nothing redundant with the title or the schema.

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?

For a generic, open-world passthrough with no output schema, the description supplies the three things the schema cannot: which services it exists for, how write gating works, and the micro-unit convention. Return-value shape and failure modes are unaddressed, which is the main remaining gap for a raw API escape hatch.

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 100%, so baseline is 3; the description goes beyond by defining which method values count as reads and by flagging that all monetary fields in params are micro-units without conversion — a semantic trap the schema never mentions. It adds no detail on the params object shape, but the schema already says params are passed as-is.

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?

States a specific verb and resource: a universal passthrough that calls any Yandex Direct v5 service or method, with a concrete example ("bidmodifiers"/"get"). It also explicitly scopes itself to services that lack a dedicated sibling tool, so an agent can tell it apart from the ~40 named siblings.

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?

Gives clear when-to-use ("для сервисов, у которых нет отдельного инструмента"), which implicitly routes the agent to dedicated siblings first, and adds the gating rule that read methods run freely while any other method needs confirmWrite=true. No explicit prohibition or listing of the dedicated alternatives, but the selection condition is unambiguous.

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