Skip to main content
Glama

Quattr

market_share_query

Read-only

Compose a market-share query with competitors, share/click metrics, and an optional breakdown in one call. Use it for multiple specific competitors or when the user explicitly requests the exact market_share_query tool. Honor an explicit exact-tool request even when competitors contains only "self": self-only keyword/page breakdowns execute through QWA's governed drill path (dynamic client comp{N} for Queries, page_market_share for Pages, and clicks_cpc_M for both). For ordinary natural-language self-only requests, prefer market_share_breakdown for ranked keyword/page rows and growth_vs_market_share for one filtered summary. Resolves "self" / "me" / "us" / "mine" / "my" → your share column; accepts competitor names, domains, labels, or comp{N} literals. IMPORTANT: when the user NAMES competitors (e.g. "our market share vs Competitor A and Competitor B"), pass them ALL DIRECTLY in competitors ALONGSIDE "self" (e.g. ["self","competitor-a.example","competitor-b.example"]) — this verb resolves each name/domain/label to its share column ITSELF, so do NOT call resolve_entity for individual competitors. A self-only page/category-filtered aggregate with no breakdown is rejected with a steer to growth_vs_market_share. Per segment — without one it defaults to the primary "default" (Overall Market) segment. 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": "market_share_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoRestrict to branded ("Yes") or non-branded ("No") demand (ignored at site granularity)
grainNoGranularity: keyword/page for per-row GSC metrics, site/segment for share-only (clicks blocked by a known SQL bug at those grains). 'category' is NOT supported for share vs competitors (no member carries categories AND comp{N}) — it returns a clear steer.keyword
top_nNoMaximum rows to return (max 200; only meaningful when breakdown_by is set).
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"
filtersNoAdditional filters with operators (matches the UI). e.g. keyword contains "vps" but not "pricing": [{field:"keyword",op:"contains",value:"vps"},{field:"keyword",op:"not_contains",value:"pricing"}]; country in usa,can: [{field:"country",op:"eq",value:["usa","can"]}]; device desktop: [{field:"device",op:"eq",value:"DESKTOP"}]. regex/not_regex only on keyword/page.
metricsNoWhich metrics to include. "impressions" and "ctr" are a fast-follow (not yet live-verified at keyword grain).
segmentNoTracked segment ID; omit to default to the primary "default" (Overall Market) segment
sort_byNoSort field: "clicks"; "market_share"/"share"/"our share" or any self alias (self/me/us/mine/my) for your share; or the name/domain of a competitor in the competitors list. A self-share sort requires a self alias in competitors. Invalid keys are rejected instead of silently falling back. Defaults to clicks when available, else the first requested share.
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.
competitorsNoCompetitor identifiers: "self" / "me" / "us" / "mine" / "my" = your own share; a domain/label substring = that competitor; "comp3" = column comp3. When the user names competitors (e.g. "vs Competitor A and Competitor B"), pass them DIRECTLY here ALONGSIDE "self" — e.g. ["self","competitor-a.example","competitor-b.example"]; this verb maps each name/domain to its share column, so do NOT resolve_entity individual competitors. The default ["self"] returns ONLY your own share (no competitor columns).
breakdown_byNoOptional group-by field: intent, keyword, or page. Omit for a single aggregate row across the whole segment.

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 only cover the read-only/safe profile, and the description adds substantial behavior beyond that: the governed drill path for self-only breakdowns (dynamic comp{N}, page_market_share, clicks_cpc_M), documented rejection-with-steer paths for category grain and self-only page/category aggregates, and a unit contract clarifying output semantics. It also warns against unnecessary resolve_entity calls.

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?

Purpose and the primary routing rule are front-loaded, and every section (usage, aliases, unit contract) addresses a real ambiguity. It is dense and somewhat repetitive with the schema's own competitors text, which keeps it short of a 5, but nothing is pure 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 12-parameter tool with no output schema, the definition covers defaults (segment, metrics, competitors), grain restrictions, error/steer behavior, and explicit output-value semantics via the unit contract. An agent has what it needs to call and interpret results 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 and the schema already carries per-parameter docs. The description still adds cross-parameter rules the schema does not state: a self-share sort_by requires a self alias in competitors, and competitor names/domains/labels must be passed directly rather than resolved via resolve_entity. The unit-contract caveat (0.03 means 0.03%, not 3%) further shapes how share values must be interpreted.

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 first sentence gives a specific verb (compose) and resource (market-share query) plus scope (competitors, share/click metrics, optional breakdown) in one call. It also implicitly separates itself from the sibling aggregate tools market_share_breakdown, market_share_overview, and growth_vs_market_share, which are named later. An agent can identify the tool without opening the 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 ('multiple specific competitors', or an explicit exact-tool request) plus explicit when-not: for ordinary NL self-only requests, prefer market_share_breakdown for ranked rows and growth_vs_market_share for a single filtered summary. It even names the rejection cases (self-only page/category aggregate) and the steer target.

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