Quattr

total_search_share

Read-only

What's our TOTAL share of the search results page for a segment — organic plus paid combined? Combines your organic market share (your share vs tracked competitors) with your paid presence (Google Ads impression share + paid clicks) into a single total-SERP search-share number. Use for 'total search share', 'organic + paid share of the SERP', 'how much of search do we own'. ⚠️ SERP geometry is approximated — organic and paid occupy different page real estate, so the combined number is a labeled estimate, not a measured share of pixels. Defaults to the primary 'default' (Overall Market) segment when omitted — name another tracked segment to scope to it.

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

Input Schema

Name	Required	Description
`medium`	No	Organic competitor source medium, default "google/organic".
`segment`	No	Tracked segment ID; omit to use the primary "default" (Overall Market) segment.
`date_range`	Yes	Explicit 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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, non-destructive, closed-world), and the description adds genuine behavioral context beyond them: the warning that SERP geometry is approximated and the combined figure is a labeled estimate rather than a measured pixel share. It also discloses the segment defaulting rule. It does not discuss rate limits, caching, or freshness.

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 the metric definition, then usage phrases, then the estimate caveat and default-scoping rule. The warning emoji and quoted trigger phrases earn their space, though the description is on the longer side for a 3-parameter read tool.

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?

No output schema exists, so the description carries the burden of explaining the return: it does, by defining the combined total-SERP number and flagging its estimate status. Given a simple three-parameter read-only tool, this is nearly sufficient, missing only any note on granularity/dimensions or freshness.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so medium, segment, and date_range are all documented in the schema, including inclusive endpoints and the medium default. The description only restates the segment default, adding no syntax or format detail beyond the schema; baseline 3 applies.

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 computed metric (total SERP share = organic market share + paid impression share/clicks) in the opening question and confirms it in the second sentence. An agent can distinguish it from sibling metrics like market_share_overview or paid_impression_share from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger phrases ('total search share', 'organic + paid share of the SERP', 'how much of search do we own') and states the segment default plus how to rescope. It does not name alternative sibling tools or state when NOT to use it (e.g., when only organic or only paid is wanted), so it stops short of a 5.

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

All Quattr tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?