Skip to main content
Glama
Sign In
ga4-mcp-server

ga4-mcp-server

by dienhokhanh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Run several GA4 reports

batch_run_reports
Read-only

Run up to five GA4 reports for one property in one API call. Combine multiple report requests to reduce calls and retrieve analytics data together.

Instructions

Run up to 5 reports for one property in a single API call (cheaper and faster than separate run_report calls). Each request takes the same fields as run_report.

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": {
      "requests": "<requests>"
    },
    "name": "batch_run_reports"
  }
}

Input Schema

NameRequiredDescriptionDefault
propertyNoGA4 property: numeric ID ("123456789"), resource name ("properties/123456789") or display name ("My Website"). Defaults to GA4_DEFAULT_PROPERTY if set.
requestsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description usefully adds the hard cap of 5 requests plus the cost/latency benefit. However, it says nothing about batch failure semantics — whether one malformed request aborts the whole call or returns partial results — which is the key behavioral unknown for a batch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences with zero filler; the batching limit and the cost/latency benefit are front-loaded before the field-reference note. Nothing would be gained by lengthening it.

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?

For a read-only batch tool with no output schema, the description covers invocation well but leaves the return shape ambiguous: it doesn't say whether results come back as an ordered array of per-request reports or a merged payload, nor how partial failures surface. An agent can call it, but cannot reliably interpret or error-handle the response.

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?

Top-level schema coverage is 50% (property documented, requests not), but the description compensates by stating 'Each request takes the same fields as run_report,' routing the agent to a known contract instead of guessing. The nested schema is also richly documented per field, so no additional description of metrics/dimensions/filters is needed.

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 and resource ('Run up to 5 reports for one property in a single API call') and explicitly positions itself against the sibling run_report. An agent can distinguish batch vs single-report behavior immediately.

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

Usage Guidelines4/5

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

Gives a clear selection rationale — 'cheaper and faster than separate run_report calls' — which tells the agent to prefer this when multiple reports target the same property. It does not state the inverse case (when run_report is still preferable, e.g. more than 5 reports or reports against different properties).

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

Deploy Server

Other Tools