QuerySail: Google Analytics

Run a Google Analytics report

run_report

Read-onlyIdempotent

Use this to retrieve Google Analytics 4 data for one property: users, sessions, views, engagement, events, key events, revenue and any other metric, optionally broken down by dimensions such as date, channel, source/medium, landing page, page path, country, device or event name, and narrowed with filters (for example sessions from Organic Search to pages starting with '/blog/'). With no metrics it reports activeUsers, sessions and screenPageViews; with no dates it covers the last 28 days ending yesterday. Dates are in the property's time zone. Returns totals and up to 100 rows per call (default 20); page through with the returned cursor. Rates such as engagementRate are fractions. Google may withhold small values (thresholding) or sample large reports; the result says so. Figures are observed values and do not identify causes. Read-only.

Input Schema

Name	Required	Description
`cursor`	No	Opaque cursor from coverage.nextCursor of the previous call with the same arguments.
`filters`	No	All filters are combined with AND. A filter on a requested metric is numeric (equals, notEquals, greaterThan, greaterThanOrEqual, lessThan, lessThanOrEqual with a number value); any other field is a dimension filter with a string operator.
`metrics`	No	Metric API names, e.g. 'activeUsers', 'newUsers', 'sessions', 'engagedSessions', 'engagementRate', 'screenPageViews', 'eventCount', 'keyEvents', 'totalRevenue'. Default activeUsers, sessions, screenPageViews.
`end_date`	No	Inclusive end date: YYYY-MM-DD, 'today', 'yesterday' or 'NdaysAgo' (e.g. '28daysAgo'), in the property's time zone. Provide together with start_date.
`order_by`	No	Sort order. Default: chronological when grouping by a time dimension such as date, otherwise the first metric, highest first.
`row_limit`	No	Rows per call. Default 20, maximum 100.
`dimensions`	No	Dimension API names to group by, e.g. 'date', 'sessionDefaultChannelGroup', 'sessionSource', 'pagePath', 'landingPage', 'country', 'deviceCategory', 'eventName', or custom ones such as 'customEvent:plan'. Omit for totals only.
`start_date`	No	Inclusive start date: YYYY-MM-DD, 'today', 'yesterday' or 'NdaysAgo' (e.g. '28daysAgo'), in the property's time zone. Provide together with end_date.
`property_id`	Yes	Exact property ID from list_properties, e.g. 'properties/123456789'.
`connection_id`	No	Optional: force a specific Google connection when the property is visible to several.
`include_totals`	No	Also return totals across all rows. Default true.

Output Schema

Name	Required	Description	Default
`rows`	No
`units`	No
`totals`	No
`request`	No
`coverage`	No
`property`	No
`freshness`	No
`requestId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 11, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses thresholding of small values, sampling of large reports, the property-time-zone date semantics, rate metrics being fractions, and the fact that figures are observed not causal. It also documents pagination via cursor and the 100-row ceiling, which are genuine operational traits rather than restatements of structured data.

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?

Purpose is front-loaded in the first clause, followed by scope, defaults, paging, and caveats in a logical order. It is dense and information-rich rather than padded, though the single long sentence stretches readability and a few clauses (rates as fractions) border on redundant for an experienced agent.

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?

With 11 parameters, nested filter/order_by objects, and an output schema already covering return shape, the description still supplies the missing context an agent needs: defaults, time-zone semantics, pagination mechanics, filter combination via AND, and data-quality caveats. Nothing material to a correct invocation is absent.

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 would be 3, but the description adds default behavior not present in the schema: omitting metrics yields activeUsers/sessions/screenPageViews, and omitting dates yields the last 28 days ending yesterday. It also restates the 100-row/default-20 limit, which the schema already carries, so the gain is real but modest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('retrieve Google Analytics 4 data for one property') and enumerates the metric and dimension families it can return. It is clearly a reporting tool, but it never names or contrasts itself with siblings such as run_realtime_report or compare_report, leaving the agent to infer the boundary from the names alone.

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

Usage Guidelines3/5

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

Usage is implied rather than prescribed: the agent learns what happens with no metrics or no dates, plus a concrete filter example ('sessions from Organic Search to pages starting with /blog/'). There is no explicit when-not guidance and no routing to the realtime or comparison siblings, so the agent must infer when this tool is the wrong choice.

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

All QuerySail: Google Analytics 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.