Skip to main content
Glama

Quattr

paid_search_overview

Read-only

How much are we spending on Google Ads and how efficient is it? Total ad cost, average CPC, cost per conversion, and paid conversions for the WHOLE DOMAIN — optionally RANKED by search term / bidded keyword / page / ad group / campaign / campaign type / intent / category (group_by), sliced by search term / bidded keyword / ad group / intent / page / category / country / device / campaign / campaign type, and compared to a prior period. Filters and breakdowns COMBINE, in EITHER direction: intent:'VPS Hosting' + group_by:'page' is the same drill as QWA's paid INTENT tab → "By pages", and keyword:'example-brand' + group_by:'page' answers "for this search term, which landing pages" — the inverse of page:'…' + group_by:'keyword'. Both cross-filter to the SAME intersection, so pick whichever grain the question names first. For a CHEAPEST/LEAST question you must also flip the ranking — sort_by:'cost_per_conversion' + sort_direction:'asc' — because the default desc returns the most EXPENSIVE pages, the exact inverse. Reports whole-domain Google Ads metrics — no segment needed (Google Ads has no per-segment scoping here). This tool does NOT expose Google Ads conversion rate; NEVER derive it as conversions/clicks — use conversions_overview with medium:'google/cpc', metrics:['conversion_rate']. For a complete paid-versus-organic channel comparison including conversions on both sides, use paid_organic_performance_comparison. This is ad SPEND & efficiency from your Google Ads account, NOT paid market share vs competitors (use market_share_overview with medium='google/cpc' for that). For per-segment paid auction coverage use paid_impression_share.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date_range": "<date_range>"
    },
    "name": "paid_search_overview"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoRestrict to ONE page. EXACT URL by default — matched literally, so `%`, `_` and a leading `-` in a percent-encoded URL such as "/web%20hosting" are DATA, not wildcards. Resolve it with list_filter_values(page) first. For a URL PATTERN ("top pages under /vps-hosting") pass page_match:"pattern" and supply your own % wildcards, e.g. "%/vps-hosting%" (QWA page_segment semantics). Unlike intent/category, page MAY be combined with group_by:"page" in either mode.
top_nNoHow many rows to return when group_by is set (site total ignores this).
deviceNoFilter by device, e.g. "MOBILE" or "DESKTOP"
intentNoRestrict to ONE search intent, e.g. "VPS Hosting" — mirrors QWA's paid INTENT drill. Combine with group_by:"page" for that intent's landing pages by cost / cost per conversion. Resolve the exact value with list_filter_values(intent) first. Rejected together with group_by:"intent".
countryNoFilter by country, e.g. "usa"
keywordNoRestrict to ONE search term — the query that actually triggered the ad, e.g. "example-brand". Combine with group_by:"page" for that term's landing pages, or with group_by:"campaign_name" for the campaigns buying it. Matched EXACTLY: `%`, `_` and a leading `-` are DATA, not wildcards. Resolve the exact value with list_filter_values(query) or a group_by:"keyword" read first. For a FAMILY of terms use group_by:"keyword" and read the rows — there is no pattern mode. Rejected together with group_by:"keyword".
metricsNoWhich paid metrics to return; defaults to cost, cpc, cost_per_conversion, conversions. Also: clicks, impressions, ctr.
segmentNoNot needed — paid_search_overview is whole-domain (Google Ads has no per-segment scoping here). Ignored if passed; a soft note is returned for a non-default segment.
sort_byNoWhich metric ranks the group_by rows. Defaults to the FIRST entry in metrics; must itself be present in metrics.
campaignNoFilter by campaign name (Google Ads campaign)
categoryNoRestrict to ONE content category, e.g. "Hosting" — mirrors QWA's paid CATEGORY tab, which sits beside INTENT and offers the same page drill. Resolve the exact value with list_filter_values(category) first: this match is case-SENSITIVE, so a hand-typed category with different casing can under-report. Rejected together with group_by:"category".
group_byNoRank the metrics BY this attribute (top-N) instead of returning a single whole-domain total. `keyword` = the actual search term that triggered the ad; `campaign_keyword` = the bidded keyword you targeted in the campaign; also page, ad group, campaign, campaign type, intent or category.
filter_opNoHow to match the campaign filter value (default exact match)eq
date_rangeYesExplicit date range, e.g. "2026-05-01 to 2026-05-31". Both endpoints are INCLUSIVE — the END day is covered (a 7-day range = 7 days). Quattr weeks run Sunday–Saturday; for "last week" use the most recent complete Sun–Sat span.
page_matchNoHow `page` is matched. "exact" (default) treats the value as a literal URL — the right choice for a value resolved via list_filter_values, and the only one that cannot silently over-match a percent-encoded URL. "pattern" opts into wildcard matching, where `%` stands for any run of characters and `_` for exactly one, for prefix/substring reads like "%/vps-hosting%". Ignored when `page` is omitted.exact
granularityNoReturn a whole-domain TIME SERIES bucketed by day / week / month / quarter instead of a single total — e.g. "weekly ad spend over the last 13 weeks". Mutually exclusive with group_by and comparison_range.
adgroup_nameNoRestrict to ONE Google Ads ad group, e.g. "Brand — Exact". Matched EXACTLY. There is no pre-listed value set for it: enumerate with group_by:"adgroup_name" and pass a value from those rows (a ranked top-N, so a small ad group may not appear). Combine with group_by:"keyword" or "page" to break that ad group down. Rejected together with group_by:"adgroup_name".
campaign_typeNoFilter by campaign type, e.g. "SEARCH" or "SHOPPING"
sort_directionNoRanking direction for group_by rows. Default "desc" (biggest first) answers "where does the spend go". Use "asc" for EFFICIENCY questions — the CHEAPEST cost per conversion, the lowest CPC — where desc returns the exact inverse of what was asked. Ascending a cost ratio automatically EXCLUDES rows whose denominator is zero (no conversions / no clicks), because their 0/null ratio would otherwise crowd every genuinely converting row out of the top-N; the response discloses the exclusion.desc
date_range_modeNoREQUIRED when granularity is set. Use "calendar" for YTD or another explicit calendar period: keep the requested start and return only complete buckets inside it. Use "rolling" for "last N days/weeks/months/quarters": preserve N complete buckets by shifting the full window backward when needed.
campaign_keywordNoRestrict to ONE BIDDED keyword — the term you targeted in the campaign, which is not necessarily the search term that matched it (that is `keyword`). Matched EXACTLY. There is no pre-listed value set for it: enumerate with group_by:"campaign_keyword" and pass a value from those rows (a ranked top-N, so a long-tail bid may not appear). Combine with group_by:"keyword" to see which real search terms a bidded keyword captured. Rejected together with group_by:"campaign_keyword".
comparison_rangeNoExplicit comparison range for period-over-period, e.g. "2026-04-01 to 2026-04-30"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, non-destructive, closed-world reads, so the safety profile is covered. The description adds real behavioral detail beyond that: ascending a cost ratio silently excludes zero-denominator rows (disclosed in the response), and a non-default segment returns a soft note rather than erroring. This is useful context, though it stops short of describing output shape.

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?

It is front-loaded with the question and the primary metrics, and most sentences carry routing or caveat value. However, it is long and partly duplicates schema parameter text (keyword/page exactness, sort_by-in-metrics), so some sentences do not fully earn their place.

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?

For a 22-parameter tool with no output schema, the description covers routing, cross-filter semantics, ranking direction, granularity/time-series exclusions, and segment behavior. The main gap is that it does not describe the shape of the returned rows or the comparison output, leaving an agent to infer the response format.

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%, so the baseline is 3, but the description adds genuine meaning: the EITHER-direction filter/group_by cross-filtering semantics (intent+group_by:'page' equals the inverse of page+group_by:'keyword'), and the warning that default sort_by desc returns the inverse of an efficiency question. These are not in the schema and materially change how parameters are set.

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 concrete question it answers and names the exact metrics (ad cost, CPC, cost per conversion, paid conversions) for the whole domain. It repeatedly distinguishes itself from siblings — market_share_overview for competitive share, conversions_overview for conversion rate, paid_impression_share for auction coverage — so an agent can route without opening any 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?

It gives explicit when-to-use and when-not-to-use instructions with named alternatives: use conversions_overview with medium:'google/cpc' for conversion rate, paid_organic_performance_comparison for channel comparisons, market_share_overview for market share. It also states the CHEAPEST/LEAST case must flip sort_direction, a concrete selection rule.

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.

Resources