Skip to main content
Glama

Google Analytics (unofficial)

Get holistic marketing report data

marketing_get_report
Read-only

Primary reporting tool for a given GA4 property or site. Use for totals, trends, and breakdowns by dimension across GA4 website traffic and app analytics, Google Search Console site traffic, and Bing Webmaster — including last-30-days summaries, revenue, leads, sessions, users, engagement/time-on-page (average_session_duration, user_engagement_duration), and period-over-period comparisons. Drill deep: GA4 supports up to 9 grouped dimensions (date/hour, geo, device/browser/OS, source/medium/channel, landing_page/page_path, etc.). Defaults to all mapped connected sources merged into one standardized view, aligned on the shared grain (typically landing_page) so a page row blends GA4 sessions+engagement with Search Console/Bing clicks/impressions/CTR/position; per-source detail (e.g. full query lists) stays in sourceSections. Note GA4 has no query dimension and Search Console/Bing have no sessions/engagement, so those cannot share one row — query is a Search Console/Bing breakdown. Narrow with sources or sourceMode='single'. Any GA4 dimension/metric name not in the catalog is passed through to the GA4 API automatically; metricMode='source_native' forces a pure GA4-native report. Pass one date range for a single window or two date ranges for period-over-period comparison.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoOptional app or web stream selector. Use this when the user identifies the GA4 source by stream ID, measurement ID, Firebase app ID, or stream name.
siteNo
limitNo
offsetNo
sourceNo
maxRowsNo
metricsYesGA4 metric API names such as sessions, activeUsers, conversions, eventCount, totalRevenue, or engagedSessions. Include explicit numerator and denominator metrics when requesting significance context.
siteUrlNo
sourcesNo
orderBysNoOptional sort order. Each entry requires fieldName (a GA4 API name like sessions or date) and optional desc (true for descending). Example: [{ fieldName: "sessions", desc: true }].
pageSizeNo
propertyNoGoogle Analytics property identifier. Accepts a numeric GA4 property ID like 481373915 or a resource name like properties/481373915.
surfaceIdNoOptional analysis surface ID. When omitted, the default surface is used if no explicit selector is provided.
dateRangesYesOne or more GA4 date ranges. Use two date ranges for period-over-period comparisons or significance checks.
dimensionsNoOptional GA4 dimensions such as date, country, deviceCategory, landingPagePlusQueryString, or dateRange. Omit entirely for aggregate totals (renders as KPI widget). Only include when the user asks for a breakdown or trend.
metricModeNocanonical
propertyIdNoNumeric Google Analytics 4 property ID for website analytics or app analytics. Use this when the user references a GA4 property directly.
sourceModeNoauto
appStreamIdNoGA4 app or web data stream ID when the request targets a specific app stream or website stream.
significanceNoOptional significance context for GA4 rate comparisons. Use this only when the user asks whether a change is statistically significant or meaningful.
keepEmptyRowsNo
metricFiltersNo
returnAllRowsNo
sourceOptionsNo
dimensionFiltersNo
metricFilterExpressionNo
dimensionFilterExpressionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNo
chartNo
scopeNo
lineageNo
metricsNo
warningsNo
comparisonNo
confidenceNo
sourceStateNo
significanceNo
reportSummaryNo
analyticsLinksNo
resolvedEntitiesNo

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description adds substantial behavioral context: defaults to merged sources aligned on a shared grain, pass-through of unknown GA4 names, sourceMode behavior, and dimension/data availability limitations. This goes well beyond the annotations without contradicting them.

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 description is a single dense paragraph (~200 words). It is front-loaded with 'Primary reporting tool' and each sentence adds a behavior or constraint. While it could benefit from bullet points, it remains efficient for the tool's complexity.

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?

Given 27 parameters, nested objects, and an output schema, the description covers the core report semantics: merged view, per-source sections, supported dimensions/metrics, date range behavior, and source narrowing. The output schema handles return values, and annotations cover safety. This is a complete enough description.

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 only 37% (27 params), but the description compensates by explaining key parameter semantics: dateRanges (one vs two for period-over-period), metrics examples (sessions, users, revenue), dimensions supported, sources/sourceMode, and metricMode='source_native'. It does not cover pagination/filters, but the most decision-critical params are explained.

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 opens with 'Primary reporting tool for a given GA4 property or site' and specifies 'Use for totals, trends, and breakdowns by dimension across GA4 website traffic and app analytics' – a clear verb+resource+scope that distinguishes it from siblings like marketing_get_funnel or marketing_get_sources.

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 states 'Use for totals, trends, and breakdowns' and gives direct operational guidance: 'Narrow with sources or sourceMode='single'', 'Pass one date range for a single window or two date ranges for period-over-period comparison', and notes limitations about GA4 vs Search Console/Bing dimensions. This clearly frames when to use this tool and how to adjust it.

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.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: catalog for schema discovery, report for standard reporting, funnel for conversion analysis, sources for account/property discovery, and manage_surface for selector management. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent marketing_verb_noun pattern: get_catalog, get_funnel, get_report, get_sources, and manage_surface. The verb and noun structure is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for an analytics server, covering discovery, reporting, funnel analysis, source/account listing, and surface configuration without being bloated or too thin.

Completeness5/5

The tool surface covers the core analytics lifecycle: discover schema (catalog), connect to sources (sources), manage settings (manage_surface), and retrieve data (report and funnel). No obvious gaps exist; even advanced needs like pass-through dimensions are handled within get_report.

Resources