flin-ga4-mcp

Overview Schema Source Related Servers Discussions Admin

run_access_report

Read-onlyIdempotent

Retrieve GA4 data-access audit records via Admin API for a property or account to review user access activity, not configuration changes; administrator access required.

Instructions

Read data-access audit records (Admin API), not configuration changes. Administrator required.

Select property_id (default property if omitted) OR ga_account_id for an account-wide audit. Uses the separate Access schema: e.g. dimensions=["userEmail"], metrics=["accessCount"]. Some dimensions require Analytics 360. Access records are retained for up to two years. Filters use AccessFilterExpression; order_bys uses AccessOrderBy JSON. Numeric strings and quota are preserved. Follow nextOffset with unchanged arguments. Account reports do not return entity quota. account is a local login alias.

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>",
      "dimensions": "<dimensions>",
      "metrics": "<metrics>"
    },
    "name": "run_access_report"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`account`	No
`metrics`	Yes
`end_date`	Yes
`order_bys`	No
`dimensions`	Yes
`start_date`	Yes
`property_id`	No
`ga_account_id`	No
`metric_filter`	No
`dimension_filter`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial context beyond them: Admin API rather than Data API, administrator permission, two-year retention, Analytics 360 requirements for some dimensions, preserved numeric strings and quota, and that account-level reports omit entity quota. Pagination behavior is also called out ('follow nextOffset with unchanged arguments').

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 purpose and the negative scope, then structured as short lines that each carry a distinct fact. A few lines are cryptic out of context ('Numeric strings and quota are preserved', 'nextOffset' not matching any schema field), which costs a bit of clarity.

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?

For a 12-parameter, open-world audit tool, the description covers access requirements, scoping, filter/order-by formats, retention limits, 360 gating, and pagination — and an output schema exists so return values need not be described. Nothing essential to a correct first call appears missing.

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?

With 0% schema description coverage across 12 parameters, the description carries the burden and mostly succeeds: it explains property_id vs ga_account_id scope selection, gives a concrete dimensions/metrics example from the Access schema, and names the expected payload shapes for metric_filter/dimension_filter (AccessFilterExpression) and order_bys (AccessOrderBy). It leaves start_date, end_date, limit, and offset semantics unexplained, and readers must infer that 'nextOffset' refers to the offset parameter.

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 (read data-access audit records via the Admin API) and immediately excludes a nearby concept with 'not configuration changes', which separates it from search_change_history and the reporting siblings. An agent can tell this apart from 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 Guidelines4/5

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

Gives clear selection criteria ('Select property_id (default property if omitted) OR ga_account_id for an account-wide audit') and a prerequisite ('Administrator required'). It does not name the sibling reporting tools explicitly, so routing is implied rather than spelled out.

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

Deploy Server