Skip to main content
Glama
Qusto

vk-ads-mcp

by Qusto

list_ad_groups

Read-onlyIdempotent

Retrieve all ad groups from your VK Ads cabinet, optionally filtered by campaign, status, and fields. Use to analyze targeting, banners, and UTM parameters.

Instructions

List ad groups (VK Ads ad_group objects) in the connected cabinet.

Ad groups live inside campaigns (ad_plan objects) and contain the individual banners (creatives). This read-only tool drains every page of the /ad_groups.json listing endpoint and returns the RAW item dicts so every requested field reaches you for analysis.

By default the API returns a MINIMAL field set. Pass fields to get rich data, e.g. "id,name,status,targetings,utm,banners,package_id". The targetings field exposes age/gender/geo/interests. Call the describe_fields tool with resource="ad_groups" first to learn the full set of valid field names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ad_plan_idNoRestrict results to ad groups belonging to this campaign (``ad_plan``) id. Sent to the API as the ``_ad_plan_id__in`` filter. When omitted, ad groups from every campaign are returned.
fieldsNoOptional comma-separated list of object fields to request from the API. Forwarded verbatim as the ``fields`` query parameter. Rich fields include ``targetings``, ``utm``, ``banners``, ``package_id`` — see ``describe_fields``.
statusNoRestrict results to ad groups with this status (e.g. ``"active"`` or ``"blocked"``). Sent to the API as the ``_status__in`` filter.
sortingNoOptional sort spec, e.g. ``"-id"`` or ``"id"``. Forwarded verbatim as the ``sorting`` query parameter.
limitNoPage size for pagination (1-50). The API caps page size at 50; larger values are clamped. This affects request batching only — all matching ad groups are returned regardless.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

Install Server

Other Tools

Latest Blog Posts

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