Skip to main content
Glama
google-data-mcp

google-data-mcp

by seliem-attia

GA4: Funnel report

ga4_run_funnel_report
Read-only

Analyze GA4 funnel steps to see how many users reach each stage and where they drop off, with completion and abandonment rates per step.

Instructions

Funnel analysis (Data API v1alpha runFunnelReport): how many users reach step 1, 2, 3 … and where they drop off. Returns activeUsers, funnelStepCompletionRate, funnelStepAbandonments, funnelStepAbandonmentRate per step. A step = eventName (optionally urlContains on page_location) or a raw FunnelFilterExpression. Example: [{"name":"Landing page","eventName":"page_view","urlContains":"/heat-pump"},{"name":"Form","eventName":"form_start"},{"name":"Lead","eventName":"generate_lead"}].

Input Schema

NameRequiredDescriptionDefault
limitNo
stepsYes
endDateNoDefault yesterday
propertyYesGA4 property ID, e.g. '123456789' or 'properties/123456789'
startDateNoDefault 28daysAgo
isOpenFunnelNoOpen funnel: entry possible at any step (default false)
breakdownLimitNoMax. breakdown values, 1–15 (default 5)
dimensionFilterNoGA4 FilterExpression, same syntax as for ga4_run_report
breakdownDimensionNoBreak down by, e.g. 'deviceCategory' or 'sessionDefaultChannelGroup'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered and the description is free to add semantics: with no output schema, naming activeUsers, funnelStepCompletionRate, funnelStepAbandonments and funnelStepAbandonmentRate is genuinely useful disclosure of the return shape. It stops short of quota, sampling, or property-permission behavior, which keeps it below a 5.

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 what the tool does and what it returns before the structural detail. The example is long but earns its place by demonstrating the nested step objects; the only minor slack is the enumerative '1, 2, 3 …' phrasing.

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 9-parameter tool with nested objects and no output schema, the description covers the core call shape, alternative step encodings, and the metric set returned. Remaining defaults (startDate/endDate, breakdownLimit, limit) are already documented in the schema, so no critical gap is left for an agent.

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?

At 78% schema coverage the baseline is 3, and the description exceeds it by clarifying that a step is either eventName (optionally narrowed by urlContains on page_location) or a raw FunnelFilterExpression — an either/or relationship the flat schema does not make explicit. The worked three-step JSON example anchors the nested 'steps' array structure in a way the schema cannot.

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?

Specific verb and resource ('Funnel analysis ... runFunnelReport') plus the exact question it answers (how many users reach each step and where they drop off). It also lists the returned metrics, which lets an agent separate it from ga4_run_report without opening either schema.

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 by the funnel framing, and the description cross-references ga4_run_report only for filter syntax, not for tool selection. There is no explicit 'use this instead of ga4_run_report when...' routing, nor any when-not-to-use or prerequisite guidance.

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