flin-ga4-mcp

Overview Schema Source Related Servers Discussions Admin

run_funnel_report

Read-onlyIdempotent

Build sequential GA4 funnel reports with 1–10 steps and up to 4 segments, including breakdowns and next-action dimensions, to analyze conversion paths.

Instructions

Read a sequential funnel via Data v1alpha: 1–10 steps, up to 4 segments.

Steps use native FunnelStep JSON, e.g. {"name":"Purchase","filterExpression":{"funnelEventFilter":{"eventName":"purchase"}}}. Step filters use FunnelFilterExpression, not the core report FilterExpression. Optional breakdown: {"breakdownDimension":{"name":"deviceCategory"},"limit":"5"} (max 15). Next action: {"nextActionDimension":{"name":"eventName"},"limit":"5"} (max 5). Segments use native Segment JSON; Google validates nested filter/segment semantics. Returns funnelTable and funnelVisualization with named rows, metadata and propertyQuota. No offset exists; possiblyTruncated flags subreports at the limit. Narrow the query then.

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": {
      "start_date": "<start_date>",
      "end_date": "<end_date>",
      "steps": "<steps>"
    },
    "name": "run_funnel_report"
  }
}

Input Schema

Name	Required	Default
`limit`	No
`steps`	Yes
`account`	No
`end_date`	Yes
`segments`	No
`start_date`	Yes
`property_id`	No
`is_open_funnel`	No
`dimension_filter`	No
`funnel_breakdown`	No
`funnel_next_action`	No
`visualization_type`	No	STANDARD_FUNNEL

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Even though annotations already declare a safe read-only, idempotent operation, the description adds substantial behavioral context: step/segment limits, the FunnelFilterExpression requirement, breakdown and next-action limits, returned artifacts, absence of offset, and possiblyTruncated behavior. Nothing contradicts 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 description is front-loaded with purpose and scope, then proceeds through the important funnel-specific structures and caveats. It is dense but appropriate for a 12-parameter analytics tool, with little obvious filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers funnel mechanics, limits, return shape, and truncation behavior well, and an output schema exists so return values need not be fully explained. However, with 12 parameters and 0% schema description coverage, missing semantics for parameters such as dimension_filter and is_open_funnel leave meaningful gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It does well for the hardest nested parameters—steps, segments, funnel_breakdown, and funnel_next_action—including JSON examples and limits, but it leaves several top-level parameters unexplained, including start_date, end_date, limit, property_id, dimension_filter, and is_open_funnel.

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 states a specific verb and resource: 'Read a sequential funnel via Data v1alpha', with concrete scope limits of 1–10 steps and up to 4 segments. It is clearly funnel-specific, but it does not explicitly distinguish this tool from sibling report tools such as run_report or run_realtime_report.

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?

The first sentence and funnel-specific framing imply this tool is for sequential funnel analysis, and the description gives useful constraints on steps, segments, breakdowns, and next actions. However, it never explicitly says when to choose this over alternatives like run_report, nor does it state exclusions or routing conditions.

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

Deploy Server