Quattr

significance_check

Read-only

Is the −72% period-over-period change real, or just noise? Tests whether a metric's distribution in the selected period is statistically different from the comparison period — fetches per-bucket values for each period, picks Welch's t-test (n≥8) or Mann–Whitney U (small n), and returns delta, deltaPct, pValue, and whether the change is significant at the given alpha. GSC metrics default to google/organic + web; use metric.filters traffic_source/search_type to request paid, all-source, or another search type. Use for "is this drop real?", "is the lift statistically significant?", "did the trend change meaningfully?", and for "is my share significant?" / "is your share significant?" / "is our share significant?". Those share questions are the customer's market share: pass metric { domain: "market_share", metric: "share" } (aliases: my share, your share, our share, own share, market_share). "Your" does not mean the assistant has no share. The verb resolves the alias to the customer's tracked share column and fails closed when that rank is above 40 — do not invent a column or pass a raw metric name. Two governed reads, pure statistics — no compute engine needed.

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": {
      "metric": "<metric>",
      "date_range": "<date_range>",
      "comparison_range": "<comparison_range>"
    },
    "name": "significance_check"
  }
}

Input Schema

Name	Required	Description	Default
`alpha`	No	Significance threshold (default 0.05). The change is flagged as significant when pValue < alpha.
`metric`	Yes	The metric to test for a significant change — which domain it comes from, the metric name, and any scoping (segment, filters).
`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	Time bucket size for the per-bucket series used in the test: day (default), week, or month. More buckets = more statistical power.	day
`comparison_range`	Yes	Explicit comparison date range to test against, 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.5/5.0

Behavior5/5

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

Beyond the readOnly/non-destructive annotations, the description discloses the internal method selection (n≥8 → Welch's t-test, small n → Mann–Whitney U), the exact output fields, the fail-closed behavior when the share rank exceeds 40, and the cost profile ("two governed reads, pure statistics — no compute engine needed"). That is substantive behavior an agent cannot get from the annotations.

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?

The opening hook and the statistic-selection sentence are well front-loaded, but the share handling is padded: the same alias set appears twice (three quoted "...share significant?" phrasings plus a separate aliases list) and the "'Your' does not mean the assistant has no share" aside is defensive filler. Several sentences repeat rather than extend the guidance.

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 five-parameter, nested-metric tool with no output schema and no return-value documentation elsewhere, the description covers the required pieces: what the test does, how the method is chosen, what comes back (delta, deltaPct, pValue, significance flag), how alpha is applied, and the special share-domain path. Nothing an agent needs to call it correctly 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 baseline is 3, but the description adds real meaning on top: it explains that GSC defaults to google/organic + web and how to use metric.filters traffic_source/search_type for paid or all-source data, and it resolves the market_share domain plus its aliases to a tracked share column. It stops short of documenting the generic filter field/op/value contract or segment semantics.

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 verb and resource: it tests whether a metric's distribution in the selected period is statistically different from the comparison period, and names the concrete mechanics (Welch's t-test vs Mann–Whitney U). It also spells out the returned fields (delta, deltaPct, pValue, significance), so an agent can tell it apart from a plain period comparison tool like compare_periods.

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?

It gives explicit trigger questions ("is this drop real?", "is the lift statistically significant?", "did the trend change meaningfully?") and a detailed routing rule for share questions. What it does not do is name a sibling as the alternative or state when NOT to use it — e.g. it never says to prefer compare_periods or pop_significance for a simple non-statistical delta, leaving that boundary to inference.

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?