vk-ads-mcp

by Qusto

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource or operation (field discovery, listing campaigns/ad groups/banners, statistics, export, rate limits). No two tools overlap in functionality, so an agent can easily distinguish them.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., describe_fields, get_statistics, list_campaigns). The naming is predictable and clear.
Tool Count4/5
With 8 tools, the set is well-scoped for a read-only analytics-oriented VK Ads server. It covers listing, statistics, export, and diagnostics without being too sparse or overly bloated.
Completeness3/5
The tools cover listing, statistics, and export well, but lack any write operations (create, update, delete) for campaigns, ad groups, or banners. For a full ad management server, this is a notable gap, though the set is coherent for read-only analytics.
Average 4.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds context about combining two sources (live call and cached headers) and confirms it's a safe diagnostic operation, adding value beyond annotations.
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 well-structured: a concise summary, bullet points explaining two sources, and a usage recommendation. No unnecessary words; every sentence adds value.
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?
For a zero-parameter diagnostic tool, the description fully explains what it does, the data sources, the return format, and when to use it. No gaps given the simplicity.
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?
The input schema has no parameters (0 params, 100% coverage), so baseline is 4. The description does not need to add parameter info as there are none.
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 it reports remaining VK Ads API quota for diagnostics, naming specific data sources (live throttling call and cached headers). It distinguishes itself from siblings by focusing on quota diagnostics rather than data retrieval.
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?
The description explicitly says 'Use this to check how much API budget is left before issuing further listing or statistics requests, or to debug HTTP 429 rate-limit errors.' It provides clear context but does not explicitly exclude other uses or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds details: fetches via shared client, reads metric from total.base aggregate, sorts, and returns top/bottom limit. No contradictions.
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 plus a usage directive; all content is relevant and front-loaded. No unnecessary words.
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 an output schema present and 100% parameter coverage, the description fills the remaining gaps by explaining the ranking logic, metric source, and usage intent. It is complete for a tool of this complexity.
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 baseline is 3. The description adds context like 'from each object's total.base aggregate' but does not significantly enhance parameter meaning beyond the schema's own descriptions.
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 (rank) and the resource (VK Ads objects by a performance metric, returning top N). It distinguishes from sibling tools like list_ad_groups by focusing on ranking and selection of best/worst performers.
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?
The description explicitly says 'Use this to pick the best-performing (or worst-performing) campaigns, ad groups or banners.' However, it does not contrast with sibling tools like get_statistics for raw data or list_* for unfiltered listings, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination walking, raw dict return, and default field behavior, adding value beyond the `readOnlyHint` and `idempotentHint` annotations. No contradictions.
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?
Concise and front-loaded: 5 sentences cover purpose, pagination, field selection, and reference to another tool. No superfluous information.
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?
Covers main aspects: what it does, pagination, field selection, and integration with `describe_fields`. With output schema present, return values are documented elsewhere. Minor omission of error handling but not critical.
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%, but the description adds meaning: provides example for fields parameter, explains status filter, sorting, and limit with clamping. This goes beyond the schema descriptions.
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 it lists ad campaigns (VK Ads `ad_plans`) for the authenticated cabinet, with a specific verb and resource. It distinguishes from siblings like `list_ad_groups` and `list_banners` by naming the resource.
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?
Provides clear context: mentions default minimal field set, suggests using `describe_fields` first to learn valid fields, and explains how to get rich data. While it doesn't explicitly say when not to use, the guidance is sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides significant behavioral detail beyond annotations: it explains that the client splits long ranges (>92 days) and id lists (>50), flattens items into CSV rows using stdlib, writes to a file, and specifies header behavior and missing value handling. It also clarifies it never mutates ad objects, adding context to the annotation readOnlyHint=false.
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 well-structured, starting with a clear purpose sentence, followed by detailed behavior, and then CSV specifics. It is concise yet comprehensive, with no unnecessary words. Every sentence adds value.
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?
Given the tool complexity (6 parameters, output schema exists), the description covers all necessary aspects: splitting behavior, CSV format, header union, missing values, and side effects (file overwrite). It aligns with annotations and schema, providing a complete understanding without requiring the output schema.
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?
The input schema has 100% description coverage, providing baseline score of 3. The description adds extra meaning by explaining how the client transparently splits date ranges and id lists, and implies that invalid object_type raises an error. This adds value beyond the schema alone.
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 starts with 'Export VK Ads statistics to a CSV file on disk', clearly stating the verb (export) and resource (VK Ads statistics). It further specifies the object type and date range, distinguishing it from sibling tools like get_statistics which return JSON, and it mentions read-only behavior, setting it apart from mutation tools.
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?
The description explains when to use this tool (to export statistics to CSV) and transparently handles range splitting and id list splitting. However, it does not explicitly state when not to use it or directly compare to sibling alternatives like get_statistics or get_top_objects, leaving the agent to infer the best use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations by revealing that the client transparently splits date ranges over 92 days and chunks id lists over 50, merging results. This discloses behavior not evident from readOnlyHint and idempotentHint alone.
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 concise at 5 sentences, front-loaded with a clear purpose, and uses efficient language. Every sentence adds value without repetition.
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?
Given the tool complexity (6 parameters, 1 required) and presence of an output schema, the description fully covers purpose, behavior, and parameter-related constraints. No gaps remain.
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%, but the description adds context about how parameters relate to API limits (e.g., date_from/date_to splitting, ids chunking), providing meaning beyond the schema descriptions.
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 'Fetch performance statistics for VK Ads objects' and explains the API endpoint. It distinguishes this tool from siblings like 'get_top_objects' or 'list_campaigns' by focusing on statistics.
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?
The description provides clear context for when to use this tool (retrieving statistics) and explains that the client handles API limits automatically. However, it does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint, idempotentHint) by explaining pagination behavior ('drains every page'), return format ('RAW item dicts'), and default field set. This adds substantial context that structured fields alone do not provide.
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 concise (5 sentences), well-structured, and front-loaded with the core purpose. Each sentence adds value without redundancy, and it follows a logical flow from what the tool does to how to use it effectively.
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?
Given the tool complexity (5 optional parameters, pagination, field selection), the description is remarkably complete. It explains the tool's role in the API hierarchy, provides usage examples, references a sibling tool for field discovery, and clarifies pagination behavior. With annotations and output schema present, no critical information is missing.
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?
Although schema coverage is 100% and the schema descriptions are detailed, the description adds extra context for the 'fields' parameter with examples and reference to 'describe_fields', and clarifies that 'limit' affects batching but not result completeness. This enriches parameter understanding beyond schema basics.
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 lists ad groups, explains the hierarchy with campaigns and banners, and distinguishes itself from sibling tools by focusing on ad group objects. It uses specific verbs and resource types, making the purpose unmistakable.
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?
The description provides usage guidance by mentioning the optional 'fields' parameter and recommending calling 'describe_fields' first to learn valid field names. It implies read-only usage, but does not explicitly compare to alternatives like 'list_banners' or 'get_statistics'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: transparent pagination, returning raw item dicts, default minimal field set, and the effect of the 'fields' parameter. No contradiction with annotations.
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 four sentences, front-loaded with purpose, and every sentence adds value—pagination, read-only, field selection, and a pointer to describe_fields. No redundancy or filler.
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?
Given the existence of an output schema and annotations, the description covers all needed context: what the tool does, pagination behavior, read-only nature, parameter usage tips, and how to explore fields. It is self-contained and sufficient for correct invocation.
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%, providing baseline 3. The description adds meaning beyond schema with examples (e.g., 'content' field carries variants/urls) and behavioral notes (limit clamping, all banners returned). This incremental value justifies a score of 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 clearly states 'List banners (creatives) in the own VK Ads cabinet.' with a specific verb and resource. Although it does not explicitly contrast with sibling tools, the resource 'banners' is distinct from 'ad_groups' or 'campaigns' in sibling names, making it unambiguous.
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?
The description provides clear context on how to use the tool, including parameter guidance (e.g., pass 'fields' for rich data) and a recommendation to call 'describe_fields' first. It lacks explicit when-not-to-use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds specific mechanism: sends invalid field to trigger HTTP 400 and parses allowed fields. No contradiction.
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?
Three well-structured sentences: purpose, usage instructions, and how-it-works. No fluff, each sentence serves a distinct purpose.
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?
Output schema exists (not shown but stated true). Description covers live behavior and prerequisites. Complete for a simple parameter tool.
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 100% with clear parameter description. Description adds value by mapping resource values to sibling tool names (e.g., 'ad_plans' for campaigns).
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?
Clear verb+resource: 'Discover which fields a VK Ads resource accepts. Call this FIRST.' Distinct from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call before list tools and names them (list_campaigns, list_ad_groups, list_banners). Provides when-not-to-use context by stating it's a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vk-ads-mcp MCP server](https://glama.ai/mcp/servers/Qusto/vk-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Qusto/vk-ads-mcp)

Score Badge

Copy to your README.md:

[![vk-ads-mcp MCP server](https://glama.ai/mcp/servers/Qusto/vk-ads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Qusto/vk-ads-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Qusto/vk-ads-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server