Opus Growth, Ad Platforms MCP Connector

List Entities

list_entities

Read-only

Lists the entities (campaigns, ad groups/ad sets, ads, keywords) of ANY connected ad platform with their IDs — use this instead of looking for a platform-specific list tool. platform: google_ads (default) | meta (facebook/instagram) | tiktok | linkedin | microsoft. entity: campaigns | ad_groups (adsets on Meta, adgroups on TikTok) | ads | keywords (Google Ads) | campaign_groups & creatives (LinkedIn). account = that platform's account id (for Google Ads you may also use customer_id); leave empty to use the connected/default account. parent_id narrows children to one parent (e.g. the campaign id when listing ad groups/ad sets, the ad set id when listing ads). Call describe(platform) to see which entity names a platform accepts.

Google Ads specifics (platform='google_ads'):

PAGING: rows is ONE PAGE — limit rows from offset (limit max 2000). total_rows is the real count and serving_count / serving_summary are always computed over ALL rows, not the page. truncated=true → call again with offset=next_offset and merge; never present the page as the complete list. Keyword and ad pages are returned as FLAT rows (a keyword inventory can run to thousands of rows — the raw nested GAQL form overflows the client's tool-result budget and then nothing reaches you at all).

CURRENT BIDS: ad group rows carry max_cpc (and target_cpa when set), keyword rows carry max_cpc plus effective_max_cpc and bid_source. Read the bid before changing it — a percentage change ("raise this by 30%") is otherwise sent as an absolute number and can LOWER the bid instead. bid_source: AD_GROUP_CRITERION means the keyword carries its own bid and OVERRIDES the ad group: raising the ad group bid then changes nothing for that keyword. Average CPC from a report is not a substitute — it is what was paid, not the ceiling that was set, and it is usually lower.

ACTIVE / RUNNING / LIVE = is_serving: true (derived from serving_status), NOT status: "ENABLED". They are different things: a campaign whose end date has passed still reads status=ENABLED while the Google Ads UI shows it as "Ended". When the user asks which campaigns are active, answer from is_serving and account for the rest using serving_status

status_reasons (ENDED, PAUSED, NOT_ELIGIBLE, MISCONFIGURED, PENDING...). Never present a status=ENABLED row as active on its own — the user is comparing your answer to their Google Ads screen. serving_summary gives the counts.

For campaigns it ALSO returns the bidding strategy (bidding_strategy), daily budget (daily_budget), targets (target_cpa / target_roas) and the max CPC ceiling (max_cpc, in account currency; null means no ceiling is set AT CAMPAIGN LEVEL). When max_cpc_note is present the campaign uses a portfolio strategy and max_cpc was not read.

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`entity`	No	campaigns
`offset`	No
`account`	No
`platform`	No
`parent_id`	No
`customer_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: paging semantics (rows is one page, total_rows is real count, truncated=true means merge), flat-row return format for keywords/ads, bid-related caveats (max_cpc, bid_source override), and the critical distinction between is_serving and status=ENABLED. This is rich, non-obvious behavior that an agent must know to use the tool correctly.

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 long, but every section earns its place: the opening paragraph defines scope and parameters, and the Google Ads specifics section covers paging, bids, and status semantics that are essential for correct use. It is front-loaded with the core purpose and parameter overview before diving into platform-specific details. It could be slightly tighter, but the density of critical operational information justifies the length.

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's complexity (7 parameters, 5 platforms, multiple entity types, paging, bid semantics, status semantics) and the presence of an output schema, the description is remarkably complete. It covers parameter meaning, platform differences, paging behavior, return-format caveats, and the active-vs-enabled trap. The only minor gap is that it doesn't describe the output schema structure in prose, but the output schema exists and the description explicitly mentions key fields (total_rows, serving_count, serving_summary, is_serving, status_reasons, etc.).

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 description coverage is 0%, so the description carries the full burden of explaining parameters. It explains platform, entity, account, parent_id, and the Google Ads customer_id alias, plus limit/offset paging semantics. It does not explicitly describe the 'limit' and 'offset' defaults in prose, but the schema provides defaults and the paging section covers their meaning. This is strong compensation for the 0% 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 opens with a specific verb and resource ('Lists the entities ... of ANY connected ad platform with their IDs') and explicitly distinguishes itself from platform-specific list tools, telling the agent to use this instead. It enumerates the entity types per platform, so an agent can immediately tell what this tool covers and that it is the generic cross-platform list tool among the siblings.

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?

The description gives explicit when-to-use guidance ('use this instead of looking for a platform-specific list tool'), explains how to disambiguate entity names per platform, and provides platform-specific operational guidance (e.g., Google Ads paging, active vs. enabled status). It also tells the agent to call describe(platform) to see accepted entity names, which is a clear alternative/fallback path.

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

All Opus Growth, Ad Platforms MCP Connector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.