Skip to main content
Glama

Quattr

growth_vs_market_share

Read-only

Use this whenever the question pairs one of YOUR metrics — clicks, impressions, CTR or average position — with market share ("clicks and market share", "impressions vs our share", "are we growing faster than our share", traffic vs share side-by-side). Pass vs:"clicks"|"impressions"|"ctr"|"position" (default clicks) to pick the right axis. Pass country and/or device to keep BOTH legs on the same geography and device (e.g. "clicks and market share on mobile in Canada") — do not decompose that into market_share_query + search_performance. Pass page or category for a FILTERED SUMMARY such as "market share and clicks for pages containing /p/"; that path preserves QWA's summary-level market-share denominator and joins a separately filtered GSC aggregate, so adding traffic cannot change the share definition. Country/device cannot be combined with a page/category summary in the same call. For share vs competitors WITHOUT a traffic metric, use market_share_overview instead. For a per-slice top-N breakdown (e.g. top intents or pages by clicks/share), use market_share_breakdown. Defaults to the primary "default" (Overall Market) segment when omitted — name another tracked segment to scope to it. UNIT CONTRACT: market-share values are already percentage units on a 0–100 scale (0.03 means 0.03%, not 3%); share delta is selected-minus-comparison percentage points; leader gap is leader-minus-client percentage points for the same period; only deltaPct is a relative-change ratio.

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": "growth_vs_market_share"
  }
}

Input Schema

NameRequiredDescriptionDefault
vsNoWhich of YOUR metrics to plot against market share: clicks (default), impressions, ctr or position. On the primary "default" (whole-domain) segment, clicks come from a separate whole-domain GSC read joined on the period — same mechanism as impressions/ctr/position (payload echoes clicks_source:"gsc"); on a tracked (non-default) segment clicks stay on the segment-scoped market-share table (clicks_source:"market_share_tracked").clicks
pageNoRestrict share-vs-competitors to ONE page/URL pattern (e.g. "%/products%"), matched against the customer page at the same summary grain used by QWA. Single-value filter.
brandNoRestrict to branded ("Yes") or non-branded ("No") demand (ignored at site granularity)
grainNoGranularity: whole-segment (default), site, keyword or page. Keyword/page unlock keyword-, page- and intent/brand-sliced views; site is whole-site only. NOTE: 'category' is NOT supported for share-vs-competitors (no member carries content categories AND the comp{N} columns) — passing it returns a clear steer, not competitor shares.
deviceNoRestrict BOTH the market-share read and the paired GSC metric read to one resolved device value, e.g. "MOBILE" or "DESKTOP". Resolve the exact value with list_filter_values first. Same scope on both legs.
intentNoRestrict to ONE search intent, e.g. "Informational" (a single-value filter, not a breakdown — for top-N across intents use market_share_breakdown; ignored at site granularity)
mediumNocompetitor source medium for the comparison, e.g. "google/organic" (default) or "google/cpc"
countryNoRestrict BOTH the market-share read and the paired GSC clicks/impressions/CTR/position read to one resolved country code, e.g. "can". Resolve the exact value with list_filter_values first. Same scope on both legs — do not compose market_share_query + search_performance for this.
filtersNoOperator-aware filters applied identically to both legs. Page/category build a filtered summary. Country/device keep share and the GSC metric on the same geography/device. Do not mix page/category with country/device in one call.
segmentNoTracked segment ID; omit to use the primary "default" (Overall Market) segment.
categoryNoRestrict share-vs-competitors to ONE content category (e.g. "Products"), as exposed by list_filter_values(category). Uses QWA's summary-level category parameter. Single-value filter — for top-N across categories use market_share_breakdown(breakdown_by=category). Resolve the exact value with list_filter_values first.
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.
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.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered; the description goes further with a UNIT CONTRACT (share values are 0–100 scale, delta is selected-minus-comparison points, leader gap is leader-minus-client points, only deltaPct is relative), plus the segment-dependent source behavior for clicks and the note that grain='category' returns a steer rather than competitor shares. These are non-obvious behaviors an agent could not infer from structured fields.

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 long and dense, but for a 13-parameter tool with several mutually exclusive filter paths, most sentences earn their place and the trigger scenario is front-loaded. A few clauses (the clicks_source mechanism details) could be trimmed since the schema already covers them, keeping it just below maximal conciseness.

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?

With no output schema, the description supplies the return semantics (share units, delta and gap definitions, deltaPct ratio) that would otherwise be missing, and it covers the combining restrictions and default-segment behavior. For a tool of this complexity, an agent has everything needed to call it correctly.

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; the description nonetheless adds meaning the schema does not carry, notably the unit/scale contract for the share outputs and the rule that page/category builds a filtered summary that preserves QWA's summary-level denominator while country/device must keep both legs identical. It stops short of restating every parameter, which is appropriate given the rich schema.

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 states a specific capability — pairing one of the user's GSC metrics (clicks/impressions/CTR/position) with market share — and enumerates the exact phrasings that select it ("clicks and market share", "are we growing faster than our share"). It explicitly distinguishes itself from market_share_overview, market_share_breakdown, and the market_share_query + search_performance composition, so an agent can route correctly 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 triggers, names the alternative for each divergent case (share-vs-competitors without a traffic metric → market_share_overview; per-slice top-N → market_share_breakdown), and states a hard constraint: country/device cannot be combined with a page/category summary in the same call. This is about as complete as routing guidance gets.

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