What can you do with this server?

This server provides an MCP interface for the VK Ads API, enabling management of campaigns, ad groups, ads, statistics, and account information. * List Campaigns: Retrieve advertising campaigns with optional filtering by status (active, blocked, deleted), with automatic pagination. * Create Campaign: Create a new campaign by specifying a name, objective/type, and budget limits. * Update Campaign: Modify an existing campaign's name, budget, or status (activate, stop, delete). * List Ad Groups: Get a list of ad groups with targeting information, filterable by campaign. * List Ads: Retrieve individual ads filterable by campaign or ad group, including format and status details. * Create Ad: Create a new ad by defining the format (text, image, video), title, description, link URL, and associated ad group. * Get Statistics: Fetch performance metrics (impressions, clicks, spend) for campaigns or ads over a date range, aggregated by day, week, month, or as an overall summary. * List Targeting Groups: Retrieve targeting groups associated with a specific campaign. * Get Account / Budget: Retrieve account information, current balance, and budget limits.

How do I use vk-ads-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vk-ads-mcp Покажи статистику по кампании за последнюю неделю" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

vk-ads-mcp

by theYahia

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

VK Ads MCP — управление рекламой ВКонтакте через нейросеть

Если вы искали, как подключить рекламный кабинет VK Ads к ИИ-ассистенту, спрашивать про открутку и остаток бюджета обычными словами или собирать отчёты по кампаниям без выгрузок в Excel — это оно. 8 инструментов поверх VK Ads API v2 (ads.vk.com/api/v2): кампании, группы объявлений, объявления, статистика и баланс.

npm License: MIT

Модель данных VK Ads: ad_plans (кампании) → ad_groups (группы) → banners (объявления). Имена инструментов оставлены дружелюбными (list_campaigns, list_ads), но обращаются к реальным v2-ресурсам.

Установка

Claude Desktop

{
  "mcpServers": {
    "vk-ads": {
      "command": "npx",
      "args": ["-y", "@theyahia/vk-ads-mcp"],
      "env": {
        "VK_ADS_TOKEN": "ваш_токен"
      }
    }
  }
}

Claude Code

claude mcp add vk-ads -e VK_ADS_TOKEN=ваш_токен -- npx -y @theyahia/vk-ads-mcp

Related MCP server: Meta Ads MCP Server

Авторизация

Переменная	Обязательна	Назначение
`VK_ADS_TOKEN`	✅	OAuth2 Bearer access_token VK Ads API
`VK_ADS_CLIENT_ID`	—	для авто-обновления токена (refresh)
`VK_ADS_CLIENT_SECRET`	—	для авто-обновления токена (refresh)
`VK_ADS_REFRESH_TOKEN`	—	для авто-обновления токена (refresh)

access_token живёт ~1 день. Если заданы все три refresh-переменные, сервер на 401 сам обновит токен через grant_type=refresh_token. Иначе — обновляйте VK_ADS_TOKEN вручную.

Кабинет выбирается токеном, а не параметром. В VK Ads v2 нет account_id в запросах: агентство/менеджер получает отдельный per-client токен (agency_client_credentials) и подписывает им запросы нужного кабинета.

Инструменты (8)

Инструмент	Метод	Описание
`list_campaigns`	`GET /ad_plans.json`	Кампании (ad_plans), фильтр по статусу, авто-пагинация
`create_campaign`	`POST /ad_plans.json`	Создать кампанию: `name`, `objective`, `budget_limit`, `budget_limit_day`
`update_campaign`	`POST /ad_plans/{id}.json`	Обновить: `name`/бюджет/`action` (activate/stop/delete)
`list_ad_groups`	`GET /ad_groups.json`	Группы объявлений с таргетингом (delivery), фильтр по кампаниям
`list_ads`	`GET /banners.json`	Объявления (banners), фильтр по группам, авто-пагинация
`create_ad`	`POST /banners.json`	Создать объявление: `ad_group_id`, `textblocks`, `urls`, `content`
`get_statistics`	`GET /statistics/{type}/{period}.json`	Показы (`shows`), клики, расход; `period` = day/summary
`get_account`	`GET /user.json`	Кабинет и баланс (нужен scope `read_payments`)

Все инструменты используют MCP-аннотации (readOnlyHint/destructiveHint/idempotentHint), а read-инструменты — outputSchema + structuredContent для типизированного и компактного ответа. Списки пагинируются автоматически (до 200 объектов; больше — флаг truncated в ответе).

Примеры запросов

Покажи активные кампании
Создай кампанию "Осенняя акция" с целью traffic и бюджетом 50000
Останови кампанию 12345
Какие группы объявлений в кампании 12345?
Статистика кампании 12345 за январь 2026 по дням
Покажи баланс кабинета

Миграция 1.x → 2.0 (breaking)

Версия 1.x обращалась к легаси API (/campaigns.json, /ads.json, плоский /statistics.json, account_id, числовые статусы) и фактически не работала против ads.vk.com/api/v2. В 2.0 переписан весь API-слой:

account_id удалён из всех инструментов — кабинет задаётся токеном.
update_campaign: вместо status: 1/0 → action: activate|stop|delete (строковые статусы active/blocked/deleted).
Бюджет: all_limit → budget_limit / budget_limit_day (валюта кабинета, не копейки).
create_campaign: type → objective (цель кампании).
create_ad: вместо {ad_format,title,description,link_url} → {ad_group_id, textblocks, urls, content}.
get_statistics: ids_type/period=week|month|overall → object_type и period=day|summary в пути URL.
list_targeting_groups → list_ad_groups (таргетинг живёт на группе объявлений).
get_budget → get_account (баланс читается из /user.json).

Точность API

Эндпоинты и поля подтверждены официальной документацией target.vk.ru и 5 независимыми рабочими клиентами. Несколько деталей помечены в коде // VERIFY: (единицы бюджета, поле баланса, полный enum objective, путь update) и требуют подтверждения живым токеном — см. docs/VERIFICATION.md (~10 минут).

Возможный follow-up (вне текущего объёма)

Массовые действия (mass_action), список клиентов агентства (agency/clients), загрузка креативов (upload_creative), состояние лимитов (throttling), справочники таргетинга (regions/interests), конверсии и remarketing-аудитории.

Разработка

npm install
npm run build      # tsc
npm test           # vitest
npm run dev        # tsx src/index.ts (читает .env — см. .env.example)

Лицензия

MIT

Telegram: @vhodvai

Available Tools

8 tools

create_adB

Создать объявление VK Ads: формат, заголовок, описание, ссылка.

ParametersJSON Schema

Name	Required	Description	Default
`campaign_id`	Yes	ID кампании
`ad_group_id`	No	ID группы объявлений
`format`	No	Формат объявления: text, image, video	text
`title`	No	Заголовок объявления
`description`	No	Описание объявления
`link_url`	No	Ссылка объявления

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 full behavioral disclosure burden. It only states 'create', implying mutation, but lacks details on authentication, side effects, or success/failure outcomes.

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?

The description is very concise, but at the expense of necessary detail. It front-loads the verb and resource, but could be more informative without being verbose.

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?

Given 6 parameters and no output schema or annotations, the description is incomplete. It lacks information about return values, parameter dependencies, and tool constraints.

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 coverage is 100%, so the description adds no extra meaning beyond listing parameter names. It does not explain parameter interrelationships or constraints, hence baseline 3 is appropriate.

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 clearly states the verb 'Создать' (create) and the resource 'объявление VK Ads' (ad), listing key fields (format, title, description, link). It effectively distinguishes from sibling tool 'create_campaign' which handles campaigns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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

create_campaignB

Создать рекламную кампанию VK Ads: название, тип, бюджет.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes	ID рекламного кабинета
`name`	Yes	Название кампании
`type`	No	Тип кампании: normal, promoted_posts, adaptive_ads	normal
`budget`	No	Бюджет кампании в копейках

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only mentions 'create', implying mutation, but offers no details about side effects, required permissions, or what happens on success or failure.

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?

The description is extremely concise at one sentence, front-loaded with the key purpose, and contains no unnecessary 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 creation tool with 4 parameters and no annotations or output schema, the description is too minimal. It lacks details about budget units, type defaults, account dependency, and post-creation behavior.

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 coverage is 100% with descriptions for all parameters. The tool description lists three of the four parameters (name, type, budget) but adds no additional meaning beyond the schema. Baseline is 3 due to high schema coverage.

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 clearly states the verb 'create' and the resource 'VK Ads advertising campaign', and specifies key fields (name, type, budget). It effectively distinguishes from sibling tools like create_ad (which creates an ad) and update_campaign (which updates).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as create_ad or update_campaign. No indications of prerequisites or context are given.

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

get_budgetB

Бюджет рекламного кабинета VK Ads: остаток, лимиты.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes	ID рекламного кабинета

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions returning balance and limits but does not disclose behavioral traits such as whether it is read-only, requires authentication, or what happens on error. The term 'get' implies safety but is not explicit.

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 description is a single, concise sentence. It is front-loaded and contains no redundant information. However, it could be slightly more structured (e.g., listing returned fields).

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?

Given the tool's simplicity (one parameter, no output schema), the description is minimal. It explains the overall purpose but lacks details on the return format or how balance/limits are represented. It is adequate but could be more complete.

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% (account_id is described as 'ID рекламного кабинета'). The description adds no extra parameter information beyond what the schema provides. Baseline score of 3 is appropriate.

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 clearly states the tool returns the budget (balance and limits) of a VK Ads advertising account. It uses a specific verb ('get' implied by name) and resource ('budget'). No sibling tools appear to serve a similar function, so it distinguishes well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. For example, it could indicate using it before creating ads to check remaining budget.

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

get_statisticsA

Статистика VK Ads: показы, клики, расход за период по кампаниям/объявлениям.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes	ID рекламного кабинета
`ids_type`	No	Тип объектов: campaign, ad, office	campaign
`ids`	Yes	ID объектов для статистики
`period`	No	Период группировки: day, week, month, overall	day
`date_from`	Yes	Дата начала YYYY-MM-DD
`date_to`	Yes	Дата окончания YYYY-MM-DD

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided. The description implies a read-only operation by listing output metrics but does not explicitly state whether it modifies any state. It covers basic behavioral intent but lacks explicit safety guarantees or side-effect disclosures.

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?

The description is a single concise sentence, front-loading the tool's purpose. No redundant or superfluous 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?

Given no output schema and no annotations, the description covers the high-level output (impressions, clicks, cost) but lacks details on return structure and pagination. With 6 parameters and required fields, it could be more complete for an agent to fully understand usage.

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?

Input schema has 100% description coverage for all 6 parameters. The description adds no semantic value beyond what the schema already provides. Baseline 3 is appropriate.

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 clearly states that the tool retrieves statistics (impressions, clicks, cost) for VK Ads campaigns or ads over a period. This is a specific verb-resource pair, and it implicitly distinguishes from sibling tools (create/list/update) by focusing on statistics retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. There is no explicit comparison or context about prerequisites, limitations, or when to prefer other tools. It simply describes what it does.

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

list_adsC

Объявления VK Ads по кампаниям: формат, статус, данные.

ParametersJSON Schema

Name	Required	Description	Default
`campaign_ids`	Yes	ID кампаний для выборки объявлений

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior. It does not mention that the tool is read-only, nor any authentication or rate limit implications. The agent is left guessing about side effects.

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 description is concise (single phrase) but lacks structure. It could be improved with a more complete sentence, but it is not verbose. Acceptable for a simple tool.

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?

Given the tool simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it does not specify what data fields are returned, which limits completeness.

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?

The input schema describes the sole parameter 'campaign_ids' as 'Campaign IDs for selecting ads', which is clear. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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?

The description 'VK Ads by campaigns: format, status, data' clearly indicates the tool lists ads with details like format, status, and data for specified campaigns. However, it could be more explicit about the action (list) and the return structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_campaigns. The description does not specify context or exclusions for its use.

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

list_campaignsA

Список рекламных кампаний VK Ads по кабинету с фильтрацией по статусу.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes	ID рекламного кабинета
`status`	No	Фильтр по статусу: active, blocked, deleted

TDQS

A3.5/5.0

Behavior3/5

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

The description implies a read-only operation ('list'), but does not explicitly state non-destructiveness, pagination behavior, or rate limits. With no annotations, it provides minimal behavioral context.

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?

Single sentence, no redundancy, front-loaded with the core purpose. All words earn their place.

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 simple list tool with two parameters, the description is minimally adequate but lacks details about output format, pagination, or default behavior. No output schema to compensate.

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 coverage is 100% with parameter descriptions. The tool description adds no new semantic information beyond what the schema provides, so baseline score applies.

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 clearly specifies the action (list), resource (advertising campaigns), and scope (by account with status filter). It effectively distinguishes from sibling tools like create_campaign or list_ads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like list_ads or get_statistics. The description does not mention prerequisites or exclusion criteria.

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

list_targeting_groupsC

Группы таргетинга кампании VK Ads.

ParametersJSON Schema

Name	Required	Description	Default
`campaign_id`	Yes	ID кампании

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, requires permissions, or has any behavioral traits (e.g., pagination, rate limits). The description is insufficient for safe invocation.

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

Conciseness2/5

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

The description is extremely short (one noun phrase), but this is under-specification rather than conciseness. It fails to provide any actionable detail, making it inefficient for an AI agent.

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

Completeness1/5

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

Given no output schema and no annotations, the description should explain what the tool returns and any constraints. It only states the resource without format, pagination, or example. Completely inadequate for correct usage.

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% (campaign_id with description 'ID кампании'). The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema already documents the parameter adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description identifies the resource as 'Группы таргетинга кампании VK Ads' (targeting groups of VK Ads campaign) but lacks a verb. The tool name 'list_targeting_groups' implies listing, but the description is a noun phrase, making it somewhat vague. It does not distinguish from sibling tools like list_ads or list_campaigns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools exist (e.g., list_ads, list_campaigns) but no exclusions or context for selection are given.

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

update_campaignB

Обновить кампанию VK Ads: название, бюджет, статус (start/stop).

ParametersJSON Schema

Name	Required	Description
`campaign_id`	Yes	ID кампании
`name`	No	Новое название
`budget`	No	Новый бюджет в копейках
`status`	No	Новый статус: start, stop

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as idempotency, authorization requirements, or what happens on failure. For a mutation tool, this is insufficient.

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 description is a single short sentence with no wasted words. However, it could be slightly more structured to include context about the tool's effect.

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?

The tool has 4 parameters and no output schema or annotations. The description does not explain return values, error handling, or side effects, leaving significant gaps.

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%. The description adds little beyond what is already in the schema; it simply lists the parameters. Baseline 3 is appropriate.

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 clearly states the verb 'update' and resource 'campaign', and specifies the fields (name, budget, status). It distinguishes itself from sibling tools like create_campaign.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no mention of conditions or exclusions. It only states what it does.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.0.1May 28, 2026
- First observedcreate_ad
- First observedcreate_campaign
- First observedget_budget
- First observedget_statistics
- First observedlist_ads
- First observedlist_campaigns
- First observedlist_targeting_groups
- First observedupdate_campaign

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Scored 2026-05-28 18:50 across 8 tools

Disambiguation5/5

Each tool targets a distinct action and resource (ad, campaign, budget, statistics, targeting groups), with no ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_ad, list_campaigns), making them predictable and easy to understand.

Tool Count5/5

8 tools is well-scoped for managing VK Ads, covering creation, listing, updates, statistics, and budget without being excessive or insufficient.

Completeness3/5

Missing delete operations for both ads and campaigns, no update for ads, and no individual get endpoints, which leaves notable gaps in lifecycle coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

google-ads
ai.adramp
Google Ads MCP server — manage campaigns, keywords, and metrics.
Marketing E-commerce & Retail
2
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
Google Ads + Meta Ads + GA4 MCPOAuth
io.github.irinabuht12-oss
Google Ads, Meta Ads & GA4 MCP server - 250+ tools for campaigns, creatives, audiences & reports.
Marketing Social Media
11,644
paid-ads AOAuth
io.github.connected-paths
Hosted MCP server for Google Ads and LinkedIn Ads analysis.
Marketing Social Media
2

Related MCP Servers

vk-ads-mcp
Marketing Social Media
Qusto
A
license
A
quality
D
maintenance
Read-only MCP server for analyzing VK Ads campaigns, listing ad structures, retrieving statistics, and generating optimization recommendations.
Updated 3 months ago (2026-06-08 04:48 UTC)
8
1
MIT
Meta Ads MCP Server
Marketing Social Media
phwtsp
A
license
Not graded
quality
D
maintenance
Python MCP server that exposes Meta Marketing API data, providing tools to manage ad accounts, campaigns, and analytics through natural language interfaces.
Updated 6 months ago (2026-03-10 10:35 UTC)
MIT
VK Ads MCP
Marketing Social Media
askads
A
license
A
quality
A
maintenance
MCP server for VK Ads API: manage ad plans, ad groups, banners, and statistics.
Updated 22 days ago (2026-08-21 15:30 UTC)
18
43
7
MIT
vk-ads-mcp
Marketing
ai-hub-open
A
license
Not graded
quality
A
maintenance
MCP server for VK Ads API (myTarget v2) that allows AI agents to manage advertising accounts: create and modify campaigns, ads, upload creatives, and fetch statistics.
Updated 16 days ago (2026-08-28 13:33 UTC)
145
6
Apache 2.0