Skip to main content
Glama
Sign In
yandex-api-mcp

yandex-api-mcp

by 5iNeX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

direct.raw_call

Call any Yandex Direct API method directly by specifying resource, method, and parameters when higher-level tools don't cover your use case.

Instructions

Raw Direct API call (escape hatch).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "resource": "<resource>"
    },
    "name": "direct.raw_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
methodNoDirect API method, e.g. get, add, update.
paramsNoDirect API params payload.
resourceYesDirect resource name, e.g. campaigns, ads.
account_idNoProject profile id (resolves to Direct Client-Login and optional Metrica counter defaults).
direct_client_loginNoOverride Direct Client-Login for this call (agency multi-project support).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing. The 'method' parameter means this tool can add/update (mutate), yet there is no warning about destructive effects, required permissions, rate limits, or error behavior on raw payloads. 'Escape hatch' hints at caution but is not a substitute for disclosure.

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

Conciseness3/5

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

Single front-loaded phrase with no waste, but here brevity reflects under-specification rather than tight editing. A tool that proxies arbitrary API methods needs more than seven words.

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

Completeness2/5

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

For a high-complexity escape hatch with a nested params object, 1 required param, no output schema, and no annotations, the description omits how method/params map to the API, what happens on failure, and any safety guidance. It is markedly incomplete for the risk surface it exposes.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the account_id -> Client-Login resolution and the direct_client_login override. The description adds nothing beyond that, so baseline 3 applies.

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?

States a concrete verb and resource ('Raw Direct API call') and the parenthetical 'escape hatch' signals it is the generic fallback. An agent can distinguish it from the typed siblings (direct.list_campaigns, direct.create_ads, etc.) without opening the schema, though it never says which API surface or version it fronts.

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?

'Escape hatch' implies use only when no dedicated tool covers the operation, which is useful, but it is never made explicit and no alternatives are named. There is no statement of when NOT to use it or why a typed sibling should be preferred.

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