Skip to main content
Glama

Quattr

gsc_breakdown

Read-only

A SNAPSHOT-ONLY breakdown of Google Search Console metrics (clicks / impressions / CTR / average position) DOWN BY a drill field — category, country, device, intent (a customer keyword group), query, page, rank bucket, traffic source, language or geo — with the full curated filter set and optional snapshot period-over-period. Use only for ONE summarized range such as "top pages by clicks" or "clicks by country". NEVER call this tool when the user asks for a day/week/month/quarter series by a drill field, including a comparison or top-N series; call gsc_dimensional_trend exactly ONCE with all requested metrics and put the second explicit period in comparison_range. For a single whole-site or top-N snapshot WITHOUT a break-by field, use search_performance; for biggest movers use seo_ranking_movement_report; for share vs competitors use the market-share analyses.

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>",
      "group_by": "<group_by>"
    },
    "name": "gsc_breakdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoConvenience: restrict to branded ("Yes") or non-branded ("No") demand (mapped into filters).
top_nNoHow many top rows to return.
intentNoConvenience: restrict to one intent (a customer keyword group); mapped into filters. Resolve the id with resolve_entity first.
mediumNoSource medium. DEFAULTS to "google/organic" — organic Search Console metrics. Pass "google/cpc" for paid.
sourceNoWhere Google search performance data is read from. Use "bigquery" ONLY when the user explicitly asks for BigQuery as the source AND describe_data_sources reports it available from live customer configuration — it returns far more granular per-query data (privacy-suppressed impressions appear under "[anonymized by google]").default
filtersNoCurated GSC filters with operators (matches the UI). e.g. country in usa,can: [{field:"country",op:"eq",value:["usa","can"]}]; page contains "/blog/": [{field:"page",op:"contains",value:"/blog/"}]; non-brand: [{field:"brand",op:"eq",value:"No"}]. regex/not_regex only on query/page.
metricsNoWhich metrics to return; defaults to clicks + impressions.
sort_byNoWhich metric to rank the rows by; defaults to the first requested metric.
group_byYesREQUIRED — the field to break the metrics down by, e.g. "category", "country", "device", "intent", "query", "page", "rank_bucket", "traffic_source", "language", or a keyword/page geo field.
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.
granularityNoBackward-compatible handler input only. Clients MUST NOT select gsc_breakdown for a day/week/month/quarter series. Call gsc_dimensional_trend exactly once for the full primary range, include every requested metric, and put any explicit second period in comparison_range.
sort_directionNoRanking direction. Defaults to QWA's ranked-table rule: descending for clicks/impressions/CTR, ASCENDING for position (lower is better), so ranking by position returns the BEST-ranked rows exactly as the app does. Pass "desc" explicitly for the inverse question — the WORST-ranked rows.
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.
comparison_rangeNoSnapshot PoP only: add deltas vs this explicit range, e.g. "2026-04-01 to 2026-04-30". If the request also asks for a day/week/month/quarter series, do NOT call gsc_breakdown; call gsc_dimensional_trend exactly once and pass the second range there.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real behavioral context: snapshot-only semantics, optional period-over-period deltas, and the BigQuery source caveat that privacy-suppressed impressions surface as '[anonymized by google]'. It does not describe pagination or result size behavior, but the added context clearly exceeds the annotation baseline.

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-loads what the tool does, then the exclusion and routing rules, so the highest-value sentence comes first. It is dense and slightly long, but nearly every clause (drill field list, NEVER rule, sibling routing) carries routing weight rather than filler.

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 14-parameter, no-output-schema tool, the description covers purpose, snapshot scope, exclusions, and the key alternatives, which is what an agent needs to select it correctly. Return-shape and top_n behavior are left to the schema, which is acceptable given the annotation-covered read-only profile.

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 100%, so the baseline is 3, but the description adds genuine meaning: it frames group_by as 'the field to break the metrics down by', clarifies that intent is 'a customer keyword group', and explains comparison_range as snapshot PoP deltas. These clarify intent beyond the schema's own wording.

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+scope: 'SNAPSHOT-ONLY breakdown of Google Search Console metrics (clicks / impressions / CTR / average position) DOWN BY a drill field', then enumerates the drill fields. It explicitly contrasts itself with gsc_dimensional_trend, search_performance, seo_ranking_movement_report and the market-share tools, so an agent can separate it from siblings without opening schemas.

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?

Gives concrete when-to-use examples ('top pages by clicks', 'clicks by country') plus an explicit NEVER rule for day/week/month/quarter series, naming the correct alternative (gsc_dimensional_trend with comparison_range). It also routes three other request shapes (no break-by, movers, market share) to their proper siblings.

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