Skip to main content
Glama
Sign In
askads

Yandex Wordstat MCP

by askads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Прямой вызов API Вордстата

raw_request
Read-onlyIdempotent

Send direct POST requests to any Yandex Wordstat API path when no dedicated tool exists, with JSON bodies and automatic folderId insertion.

Instructions

Универсальный запрос: обращается напрямую к любому пути Wordstat в Yandex Cloud Search API — для эндпоинтов, у которых нет отдельного инструмента, например "v2/wordstat/topRequests". Все эндпоинты Вордстата работают методом POST; body отправляется как JSON (folderId подставляется автоматически).

Input Schema

NameRequiredDescriptionDefault
bodyNoТело запроса в формате JSON.
pathYesПуть API, например "v2/wordstat/dynamics".
methodNoHTTP-метод. Поддерживается только POST, он же по умолчанию.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.4.0
    • changedInput schema / properties / body / description
      Previous value: -"JSON request body."New value: +"Тело запроса в формате JSON."
    • changedInput schema / properties / method / description
      Previous value: -"HTTP method. Only POST is supported; defaults to POST."New value: +"HTTP-метод. Поддерживается только POST, он же по умолчанию."
    • changedInput schema / properties / path / description
      Previous value: -"API path, e.g. \"v2/wordstat/dynamics\"."New value: +"Путь API, например \"v2/wordstat/dynamics\"."
  2. Changed2 schema fields changedv2.0.1
    • changedInput schema / properties / method / description
      Previous value: -"HTTP method. Default POST."New value: +"HTTP method. Only POST is supported; defaults to POST."
    • changedInput schema / properties / method / enum
      Previous value: -[
-  "GET",
-  "POST"
-]New value: +[
+  "POST"
+]
  3. Changed1 schema field changedv2.0.0
    • changedInput schema / properties / path / description
      Previous value: -"API path, e.g. \"v2/wordstat/dynamics\" (cloud) or \"v1/regions\" (oauth)."New value: +"API path, e.g. \"v2/wordstat/dynamics\"."
  4. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the lower bar applies, and the description still adds real context: POST is the only supported method, `body` is serialized as JSON, and folderId is injected automatically. It does not cover error behavior or what an invalid path returns, which matters for a pass-through tool, so it stops short of a 5.

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?

Two sentences with no filler: the first establishes what it is and when to reach for it, the second carries the operational constraints. Nothing could be removed without losing information.

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 a raw HTTP pass-through with no output schema and open-world semantics, the description never says what comes back — raw JSON of unknown shape, or an error envelope — which is the single most important unknown for this kind of tool. It covers invocation well but leaves the result contract and failure modes unaddressed.

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 the baseline is 3, but the description goes beyond the schema by explaining that `body` is sent as JSON and that folderId is auto-injected into it — non-obvious behavior the schema does not state. Neither `path` formatting beyond the example nor enum restriction gets extra clarification, keeping it at 4.

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 description uses a specific verb and resource ('обращается напрямую к любому пути Wordstat в Yandex Cloud Search API') and immediately scopes it to endpoints without a dedicated tool, which separates it from the four sibling tools. An agent can tell this is a raw passthrough, not a typed query wrapper.

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?

It explicitly states the selection rule — use this only for endpoints that have no separate tool — which is a clear when-to-use condition. However, the illustrative path it names ("v2/wordstat/topRequests") is exactly what the sibling top_requests already covers, which slightly muddies the rule it just set.

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