Skip to main content
Glama
Pavelsiba

yandex-direct-mcp-plus

by Pavelsiba

Список визиток

list_vcards
Read-only

Retrieve virtual business cards by ID or find the ones linked to ads in selected Yandex.Direct campaigns. Creating new cards via the API is not supported.

Instructions

Получить виртуальные визитки по ID или найти их через объявления выбранных кампаний. Создавать визитки Директ через API не даёт — новая визитка заводится в интерфейсе Директа.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoСколько объектов вернуть (максимум 10000)
offsetNoСмещение выборки: сюда передаётся LimitedBy предыдущей страницы
vcard_idsNoКонкретные визитки по их ID
campaign_idsNoНайти визитки, привязанные к объявлениям этих кампаний

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.1

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint=true and openWorldHint=true, safety is covered. The description adds a key behavioral constraint: vCards cannot be created via API and must be created in the Direct interface. It does not detail pagination or return behavior.

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, front-loaded with purpose and retrieval modes, followed by the creation limitation. No redundant text; every sentence earns its place.

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 list tool with no output schema and read-only annotations, the description covers purpose, retrieval modes, and creation limitation. It lacks return format or pagination details, but the schema already handles all parameters.

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 documents all four parameters including limit/offset and the ID arrays. The description mentions IDs and campaign associations in prose but adds no syntax or format beyond what the schema already provides. Baseline score of 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 specific verb ('Получить'/'найти') and resource ('виртуальные визитки'), and clarifies the two retrieval modes (by ID or via campaign ads). It does not name sibling tools to differentiate, but the resource is distinct.

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?

Explains two retrieval paths (by ID or via campaign ads) and explicitly notes that creation is not possible via API, directing the agent to the Direct interface. This gives clear when-to-use context and a when-not for creation, though it does not compare against sibling list tools.

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