Skip to main content
Glama

Quattr

gsc_dimensional_trend

Read-only

The ONLY governed tool for Google Search Console metrics OVER TIME BY a drill field — for example weekly clicks by page, country, device, category, intent, query, rank bucket, traffic source, language, or geo. One user request must produce exactly ONE call for the entire date_range. Copy every requested flow metric into that one call; NEVER split a multi-metric request into separate calls. Copy an explicit comparison period into comparison_range; NEVER merge the two ranges or route a dimensional comparison through compare_periods. The tool natively returns multi-metric series and compares the SAME stable entity set across both periods. Average-position dimensional trends return an immediate zero-query capability note. It ranks entities across the full primary range and returns stable day/week/month/quarter series; never emulate this by calling gsc_breakdown once per bucket.

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>",
      "group_by": "<group_by>",
      "granularity": "<granularity>",
      "date_range_mode": "<date_range_mode>"
    },
    "name": "gsc_dimensional_trend"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoConvenience filter for branded or non-branded demand.
top_nNoNumber of ranked range-summary rows; up to five leading values are plotted.
intentNoConvenience filter for one resolved customer keyword group.
mediumNoSource medium; defaults to google/organic.
sourceNoWhere Google search performance data is read from. Use "bigquery" ONLY when the user explicitly asks for BigQuery as the source AND describe_data_sources reports it available from live customer configuration — it returns far more granular per-query data (privacy-suppressed impressions appear under "[anonymized by google]").default
filtersNoOptional curated GSC filters. Resolve values before filtering. regex/not_regex only apply to query/page.
metricsNoCopy ALL metrics named by the user into this ONE array and make ONE tool call. NEVER split a multi-metric request across calls. Any combination of clicks, impressions, and CTR is supported; position intentionally returns an explicit zero-query capability note.
sort_byNoRanking metric. It must be one of the requested metrics; defaults to the first requested metric.
group_byYesREQUIRED — the field whose leading values should be plotted over time.
date_rangeYesThe PRIMARY analysis period only. If the user supplied a second explicit period, keep it separate in comparison_range and make exactly one gsc_dimensional_trend call.
granularityYesREQUIRED time bucket: day, week, month, or quarter. Quattr weeks run Sunday through Saturday.
date_range_modeYesREQUIRED for this trend tool. 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_rangeNoCopy the user's explicit comparison period here. NEVER merge it into date_range and NEVER substitute compare_periods. The tool compares the same primary-period entity set across both bucketed periods.

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 only declare read-only/safe, but the description adds real behavioral traits: average-position trends return an immediate zero-query capability note, entity ranking spans the full primary range, series are stabilized at day/week/month/quarter buckets, and comparison is performed over the same stable entity set. That is substantive disclosure beyond 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.

Conciseness4/5

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

The routing/capability constraints are front-loaded and each sentence carries a rule, but the repeated 'NEVER…' emphasis and the metrics instruction appear in both the description and the metrics schema, making it slightly heavier than necessary.

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?

For a 13-parameter, no-output-schema tool this covers routing, comparison semantics, capability limits, and the broad shape of what is returned (ranked summary plus multi-metric series). The exact composition of the returned series/summary rows remains implicit, but the agent has enough to call it 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, but the description adds cross-parameter semantics the schema lacks: date_range is the primary period only and a second period must stay separate in comparison_range rather than being merged, and the multi-metric contract for the metrics array. Useful incremental meaning, though much of the field-level detail is still schema-repeated.

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 ('GSC metrics OVER TIME BY a drill field') and enumerates the drill dimensions, so the agent knows exactly what this returns. It explicitly distinguishes itself from siblings compare_periods and gsc_breakdown in the same breath.

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?

Gives explicit when/when-not rules: one call per request, all requested metrics in one call, explicit comparison period goes in comparison_range, never route dimensional comparisons through compare_periods, never emulate with repeated gsc_breakdown calls. Alternatives are named with the condition that selects them.

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