Quattr

pop_significance

Read-only

Is this conversion-rate (or sessions / conversions / transactions) change REAL or just noise? A period-over-period significance test for your web analytics (GA4 / Adobe): every metric — conversion rate included — is tested with a Welch t-test over per-bucket series of the EXACT number QWA displays (conversion rate is conversions ÷ users, or GA4's own displayed rate), with delta taken from QWA's period aggregates. Returns delta, deltaPct and a real / noise / can't-tell verdict (derived from the p-value and the statistical power — not eyeballed). Use for "did conversion rate really change vs last month?", "is the sessions drop significant?". Both periods carry the METRIC's own QWA default scope (echoed as appliedScope): behavioral metrics (sessions, users, pageviews, events) are web + google/organic, while conversion-family metrics (conversion_rate, conversions, transactions) are web + All traffic sources — mirroring QWA's own auto-switch — so the tested numbers match an untouched QWA card and web_analytics_overview's defaults. For cross-domain or non-GA metric significance (GSC clicks, market share, CWV) use significance_check instead. Whole-domain only in v1.

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>",
      "comparison_range": "<comparison_range>"
    },
    "name": "pop_significance"
  }
}

Input Schema

Name	Required	Description	Default
`alpha`	No	Significance threshold (default 0.05). The verdict is "real" when pValue < alpha.
`metric`	No	Which web-analytics metric to test: "conversion_rate" (default) tests the displayed rate itself (conversions ÷ users, or GA4's conversion_rate_GA); count metrics are sessions, users, conversions, transactions, unique_page_views, total_events. Every metric is tested with a Welch t-test over its per-bucket series.	conversion_rate
`segment`	No	Tracked segment ID; defaults to "default" (whole domain). Per-segment web analytics is not yet available — non-default returns an honest note.
`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.
`granularity`	No	Bucket size for the per-bucket series the Welch test runs over — applies to every metric, conversion_rate included. More buckets = more power.	day
`comparison_range`	Yes	Explicit comparison range for the period-over-period test, e.g. "2026-04-01 to 2026-04-30". Both endpoints inclusive.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description goes well beyond them, disclosing the statistical method (Welch t-test over per-bucket series), how the verdict is derived (p-value + power, not eyeballed), the scope auto-switch rules, and that non-default segments return an honest note.

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-loaded with the core question and verdict intent, and every sentence carries operational information. It is dense and somewhat repetitive (Welch t-test mentioned twice, scope rules restated), which keeps it just short of a 5.

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 read-only analytical tool with no output schema, the description covers what an agent needs: inputs, statistical method, return shape (delta, deltaPct, real/noise/can't-tell verdict), scope behavior, and limitations. Nothing material is 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 coverage is 100%, so the schema already documents all six parameters and the baseline is 3. The description adds genuine meaning beyond it: the metric-family scope defaults (behavioral vs conversion-family auto-switch), that granularity affects statistical power, and the appliedScope echo.

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: a period-over-period significance test for web analytics, opened with a plain-language framing question. It distinguishes itself from siblings by naming significance_check for non-GA/cross-domain metrics and by tying results to web_analytics_overview defaults.

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?

Explicitly routes usage: gives example questions ('did conversion rate really change vs last month?'), names the alternative (significance_check) and its selection condition (non-GA/cross-domain metrics like GSC clicks, market share, CWV), and notes the v1 whole-domain limitation.

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?