Skip to main content
Glama
yandex-direct-mcp-plus

yandex-direct-mcp-plus

by Pavelsiba

Прогноз по фразам

get_keyword_forecast
Read-only

Forecast keyword traffic and click prices without creating a campaign, returning a TSV table with impressions, clicks, CTR, and position bids to help select and budget search semantics.

Instructions

Прогноз трафика и цены клика по списку фраз без кампании — для подбора семантики. Отдаёт таблицу TSV, строка на фразу: Shows — показы за прошедший месяц; Clicks, CTR — нижний блок без первого места; FirstPlaceClicks, FirstPlaceCTR — первое место; PremiumClicks, PremiumCTR — спецразмещение; Min и Max — цена клика за вход в нижний блок и за первое место в нём; PremiumMin и PremiumMax — то же в спецразмещении. С auction_bids — колонки «P<блок><место> Bid» (ставка за позицию) и «… Price» (списываемая цена): P11–P14 — спецразмещение, P21–P24 — нижний блок. Строка «Итого» — суммы по всем фразам, где Min/Max/PremiumMin уже бюджет за месяц, а не цена клика. Деньги — в валюте из currency. Ждёт готовности отчёта до 90 секунд.

Input Schema

NameRequiredDescriptionDefault
phrasesYesФразы для прогноза, до 100. Пересекающиеся фразы прогнозируются с учётом друг друга
currencyNoВалюта цен и бюджетов в ответе; по умолчанию RUBRUB
region_idsNoРегионы, коды из get_regions: ["65"] — Новосибирск, ["225","-213"] — Россия кроме Москвы. По умолчанию — все регионы
auction_bidsNoДобавить по каждой фразе ставку и списываемую цену для каждой позиции показа (AuctionBids)
negative_keywordsNoМинус-фразы, общие для всех фраз прогноза

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the TSV row-per-phrase output shape, the meaning of each column, the special semantics of the 'Итого' row (monthly budget rather than per-click price), currency handling, and a 90-second wait for report readiness. That latency and unit-shift disclosure is exactly the kind of behavior an agent cannot get from structured fields.

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?

The purpose is front-loaded in the opening clause and every sentence carries new information — no filler. It is a dense single block of column legend whose readability would improve with separation, but nothing is redundant.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so column by column, including the edge case of the totals row and the currency-dependent units. For a read-only forecasting tool with five mostly-documented parameters, an agent has enough to call it and interpret the response correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it explains what the extra columns produced by auction_bids actually are (P11–P14 for premium placement, P21–P24 for the lower block, Bid vs Price) and how currency propagates into all returned money values. Region and negative_keyword semantics are left entirely to the schema.

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+resource (forecast traffic and click price for a list of phrases) and a scope qualifier ('без кампании') that separates it from campaign-scoped siblings like get_statistics and get_campaign. It also names the intended job ('для подбора семантики'), so an agent can identify it 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.

Usage Guidelines4/5

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

Gives a clear usage context: keyword/semantic research on phrases that do not yet belong to a campaign. It does not name alternatives (e.g. get_keyword_auction or get_statistics) or state when not to use it, so routing between the two auction/pricing tools is left partly to inference.

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