Skip to main content
Glama

Quattr

web_analytics_overview

Read-only

How is my website traffic doing? Sessions, users, conversions, conversion rate, bounce rate, session duration and engagement from your web-analytics source (GA4 or Adobe Analytics) for one segment — optionally restricted to one country or broken down by country / device / landing page / traffic source / keyword / content category / intent — or, for the conversion metrics, by rank bucket ("conversions by rank bucket for pages containing /compare" is metrics:['conversions'], breakdown:'rank_bucket', page:'/compare') — and compared to a prior period. Pass goal (a tenant goal name like "Purchase", or goalN id) to make conversions and conversion_rate goal-specific — "purchase conversion rate for each product category" is goal:'Purchase', metrics including conversion_rate, breakdown:'category', sort_by:'conversion_rate'. The goal rate is governed and USER-based (completions ÷ unique users), the same basis QWA displays; NEVER derive a rate as conversions ÷ sessions. Follow-up drills retain scope by passing the selected category, subcategory, intent, page, or keyword while setting breakdown to the requested row type (for example breakdown:'page', category:'Login and Account'). Full page URLs are exact; path-only page scopes use contains matching because the underlying facts store absolute URLs. For a day/week/month/quarter trend by traffic source, call this tool exactly once with granularity plus breakdown:'source_medium'; it returns a single governed multi-source series instead of requiring one call per source or bucket. DEFAULT SCOPE mirrors QWA-as-built at CARD level, not per metric. With NO conversion metric requested, every metric is read at QWA Growth Trends' default scope — web search type + google/organic — so totals match an untouched QWA card, NOT raw GA4 all-source numbers. Requesting ANY of conversions, conversion_rate, total_value or transactions flips the WHOLE result to All traffic sources, behavioral metrics included, exactly as QWA's own "Switched to All traffic sources" does — so sessions/users are drawn from the same traffic population the rate's DENOMINATOR uses. The displayed conversions count remains QWA's All-Conversions total and is NOT the rate's numerator, so conversions / users does not reproduce the displayed rate; never derive a rate that way, and read metricDatasets for each metric's source. transaction_revenue does NOT flip the card (QWA has that entry commented out). Every result echoes the effective scope in appliedScope. A source_medium breakdown enumerates sources instead of pinning organic. This is the BEHAVIORAL / on-site lens (what visitors did once they arrived), NOT GSC clicks / impressions / rankings (use search_performance) and NOT market share vs competitors. ALWAYS per segment — called without one it lists the available segments.

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

Input Schema

NameRequiredDescriptionDefault
geoNoBreak the numbers down by visitor location. Country only (state/city visitor geo is temporarily unavailable — see breakdown).
goalNoTenant conversion goal — its name (e.g. "Purchase") or goalN id. Makes `conversions` that goal's completion count and `conversion_rate` that goal's USER-based rate (completions ÷ unique users — the exact basis QWA displays; NEVER derive completions ÷ sessions). "Purchase conversion rate by product category" is goal:"Purchase", metrics including conversion_rate, breakdown:"category", sort_by:"conversion_rate". An unknown goal returns the tenant's goal list.
pageNoRestrict to one page selected in a previous drill. A full absolute URL is exact; a path-only value uses contains matching across stored full URLs. This filters the data; use breakdown to choose the returned row type.
top_nNoHow many rows to return when breakdown is set.
deviceNoRestrict to one device type.
intentNoRestrict to one exact intent selected in a previous drill, e.g. "Brand".
countryNoRestrict to one country, e.g. "United States". Filters the data, distinct from breaking down BY country.
keywordNoRestrict to one exact keyword/query selected in a previous drill.
metricsNoWhich engagement metrics to return: sessions, users, conversions, conversion rate, bounce rate, session/page duration, unique pageview count, total value, transactions, transaction revenue, total/average events, or "engagement". Defaults to sessions, users, conversions, conversion rate and engagement. "engagement" expands to average session duration + bounce rate. Do not add a metric merely to rank a breakdown; use sort_by for that.
segmentNoTracked segment ID; omit to get the list of available segments
sort_byNoMetric that determines top-N row ordering when breakdown is set. It must also be present in metrics. Defaults to the first requested metric. Set sort_by:"conversions" for top pages/categories by conversions even when sessions or other context metrics are also returned.
categoryNoRestrict to one exact content category selected in a previous drill, e.g. "Login and Account". For pages within that category, combine with breakdown:"page".
breakdownNoReturn a top-N breakdown across this attribute instead of a single total — e.g. sessions by device, landing page, traffic source (source_medium), keyword, content category/subcategory, intent (keyword group), or country. rank_bucket buckets the CONVERSION metrics (conversions/transactions/transaction_revenue, or goal-scoped conversions) by Google rank band and combines with a page scope; behavioral metrics (sessions, users, engagement) cannot be bucketed by rank and are rejected with a note. (Visitor state/city breakdowns are temporarily unavailable due to a model-level geo bug.)
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.
granularityNoReturn a whole-domain TIME SERIES bucketed by day / week / month / quarter instead of a single total — e.g. "weekly sessions over the last 13 weeks". It may be combined with breakdown:"source_medium" for one governed multi-source series; other breakdowns and comparison_range are unsupported in trend mode.
subcategory1NoRestrict to one exact level-1 content subcategory selected in a previous drill.
subcategory2NoRestrict to one exact level-2 content subcategory selected in a previous drill.
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_rangeNoExplicit comparison range for period-over-period, e.g. "2026-04-01 to 2026-04-30"
source_medium_valuesNoFor a source_medium breakdown or time series, restrict the result to these exact QWA traffic-source values in this order, e.g. ["(direct) / (none)", "google/organic"]. Values are the QWA-curated source_medium values exactly as stored (low-volume sources may be grouped under an "other" bucket) — there is no "AI", "LLM", or other channel-grouping bucket among them, so never invent one; resolve real values with list_filter_values(traffic_source). Explicit values replace top-N source ranking so unrelated high-volume sources cannot displace the requested rows or series; values matching nothing are echoed back in unmatchedSourceMediumValues rather than silently dropped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly=true, destructive=false, openWorld=false), and the description goes well beyond: it discloses the QWA-as-built default scope, the whole-result scope flip when conversion metrics are requested, that conversions/user does not reproduce the displayed rate, the appliedScope echo, and metricDatasets. This is unusually rich behavioral disclosure for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the user-facing question and key facts, but it is a single enormous paragraph that is hard to scan, and the 'NEVER derive a rate as conversions ÷ sessions / never derive a rate that way' warning is repeated multiple times. The density is justified by tool complexity, but redundancy and lack of structuring cost it.

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 20-parameter tool with no output schema, the description covers the scope semantics, the conversion-flip, drill-down continuation rules, trend mode, and even return-field echoes (appliedScope, metricDatasets, unmatchedSourceMediumValues). Nothing an agent needs to invoke it correctly appears missing.

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 schema carries the literal parameter docs and the baseline is 3. The description still adds meaning the schema does not: how goal interacts with conversions/conversion_rate, that source_medium breakdown enumerates sources instead of pinning organic, that date_range_mode is required with granularity, and worked combination examples (e.g. breakdown:'rank_bucket' with page).

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 resource (web-analytics behavioral metrics from GA4/Adobe) and enumerates the concrete metrics it returns. It explicitly distinguishes itself from siblings: 'NOT GSC clicks / impressions / rankings (use search_performance) and NOT market share vs competitors.' 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?

Extremely explicit about when to use it, when not to (points to search_performance and market-share tools), the DEFAULT SCOPE behavior, how conversion metrics flip the whole card, and how follow-up drills should retain scope. Alternative-conditional guidance is spelled out with worked examples.

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