Skip to main content
Glama

Opus Growth, Ad Platforms MCP Connector

Performance Report

performance_report
Read-onlyIdempotent

Performance report (cost, clicks, impressions, conversions). level: campaign | ad_group | ad | keyword. Keyword level reports from keyword_view and is where pause / negative-keyword decisions are actually made, because one ad group usually mixes match types and intents; negative criteria are excluded (they have no performance and would read as "keywords with zero results"). Keyword rows come back flattened: campaign, ad_group, keyword, match_type, metrics. PAGING: keyword level can easily exceed ten thousand rows, which is more than a tool result can carry, so rows are capped (500 at keyword level, 2000 elsewhere) and the response carries total_rows / returned / offset / truncated / next_offset — call again with offset to walk the rest. limit/offset are only on this tool; get_report always returns the first page. segment: empty | device | date | day_of_week | hour | network | city | region | country | conversion_action | audience — adds a breakdown ("day" is accepted for date, "geo" for country). network splits Search / Search partners / Display / YouTube. Geo segments (city/region/country) report from geographic_view and always come back at campaign level with a readable location field. conversion_action answers "which conversion actions is each campaign actually producing" (the UI's Segment > Conversions > Conversion action): one row per campaign x conversion action, with primary conversions and all_conversions side by side, which is how you reconcile a campaign total against an account total when offline/CRM uploads are mixed with website tags. That segment returns NO cost, clicks or impressions — Google does not split spend by conversion action and would repeat the campaign total on every row, so anyone summing it would inflate the spend. AUDIENCE: segment="audience" answers "which audiences should I add, bid up or split out" — the UI's Audiences > Segments. One row per audience, at ad group level when level is ad_group/ad/keyword and at campaign level otherwise, with the audience NAME resolved: Google returns internal codes like uservertical::93017 for in-market, affinity and demographic segments, which is unreadable on its own. Each row carries taxonomy (IN_MARKET vs AFFINITY), audience_type, bid_modifier and the usual metrics. targeting_mode is the field the decision rests on: observation means measure only, delivery is NOT narrowed, while targeting means delivery is restricted to that audience. Pair it with manage_audience_targeting, which attaches or excludes an audience, so a change can be measured before and after instead of only made. IMPRESSION SHARE (no segment only): campaign returns all three — impression_share_pct, lost_is_rank_pct, lost_is_budget_pct; ad_group and keyword return impression share and rank-lost but NOT budget-lost, because Google only exposes budget-lost at campaign level (budget is a campaign constraint); the ad level has none at all. Values come as readable percentages next to Google's raw 0-1 fractions, and a missing field means the metric does not exist for that row (Display/PMax, or no impressions) rather than zero. This is what separates "efficient but saturated, no headroom" from "efficient and budget-starved, scale it". DATE: if you provide period it is used instead of days — 'today' (TODAY 00:00–now), 'yesterday', 'this_week', 'last_week', 'this_month', 'last_month', 'last_7_days'/'last_14_days'/'last_30_days', or an explicit 'YYYY-MM-DD' / 'YYYY-MM-DD:YYYY-MM-DD'. If period is empty, days applies (days=0 = today only).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
levelNocampaign
limitNo
offsetNo
periodNo
segmentNo
customer_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. Added
  16. Removed
  17. Added
  18. Removed
  19. Added
  20. Removed
  21. Added
  22. Removed
  23. Added
  24. Removed
  25. Added
  26. Removed
  27. Added
  28. Removed
  29. Added
  30. Removed
  31. Added
  32. Removed
  33. Added
  34. Removed
  35. Added
  36. Removed
  37. Added
  38. Removed
  39. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses row caps (500 keyword / 2000 elsewhere), the total_rows/returned/offset/truncated/next_offset paging contract, that conversion_action rows carry no cost/clicks/impressions and would inflate spend if summed, that geo segments always flatten to campaign level, and that missing impression-share fields mean the metric does not exist rather than zero. These are exactly the behavioral traits an agent needs before calling.

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?

Front-loaded with purpose and level, and each labeled block (PAGING, DATE, segment, IMPRESSION SHARE) is scannable. It is very long and occasionally rambles — the audience and conversion_action passages could be tightened — but nearly every sentence carries decision-relevant information rather than 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?

For a 7-parameter reporting tool with an output schema, the description supplies the segment-specific return shapes, flattening rules, and metric availability caveats that the schema does not. Nothing an agent needs to call it correctly, or to interpret the rows it gets back, is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 and does so: level choices, the full segment enum with aliases ('day' for date, 'geo' for country) and special-case behavior per segment, limit/offset paging semantics with a concrete next_offset walk pattern, and period's accepted values plus the precedence rule (period overrides days, days=0 = today only). Practically every parameter is given meaning the bare types cannot convey.

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?

States a specific verb+resource set ('Performance report (cost, clicks, impressions, conversions)') and enumerates the supported levels. It explicitly distinguishes itself from the sibling get_report by noting that limit/offset exist only here, so an agent can route correctly without opening either schema.

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?

Explicit when-to-use guidance throughout: keyword level is named as where pause/negative-keyword decisions are made, conversion_action is framed as the way to reconcile campaign vs account totals, audience is tied to add/bid-up/split decisions and paired with manage_audience_targeting, and impression share is positioned as separating saturated from budget-starved campaigns. Alternatives and conditions are stated, not implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.