AdLoop

Draft an Analytics data retention change

draft_ga4_data_retention

Destructive

Draft a change to how long GA4 keeps event- and user-level data, returning a PREVIEW.

GA4 defaults to 2 months, which cuts explorations, funnels and other user-level reports short; standard properties allow 14 months, GA4 360 up to 50. Standard reports are aggregated and not affected. Lengthening applies from now on (data already deleted does not come back); shortening deletes older data for good and needs a double confirmation. The preview shows before and after and reminds the user that a privacy policy naming a retention period must match. NO_CHANGE when the settings already match. Nothing changes until confirm_and_apply applies it; the dry run re-reads the settings and refuses if they changed in GA4 after the preview.

Google Analytics Data API: https://developers.google.com/analytics/devguides/reporting/data/v1 and Admin API: https://developers.google.com/analytics/devguides/config/admin/v1

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "draft_ga4_data_retention"
  }
}

Input Schema

Name	Required	Description
`property_id`	No	Numeric GA4 property ID, with or without the "properties/" prefix. If empty, uses the default from config.
`user_data_retention`	No	Months to keep user-level data, same values. Empty leaves it.
`event_data_retention`	No	Months to keep event-level data: 2, 14, 26, 38 or 50 (or TWO_MONTHS, FOURTEEN_MONTHS, ...). Empty leaves it.
`reset_user_data_on_new_activity`	No	True restarts a user's retention period with each new event from that user. Empty leaves it.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations by explaining exactly which direction is destructive: lengthening is forward-only and never restores deleted data, while shortening 'deletes older data for good and needs a double confirmation'. It also discloses the stale-preview refusal behavior, the before/after preview contents, and the NO_CHANGE case—the kind of nuance annotations cannot carry.

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 the action and the PREVIEW qualifier, then ordered by importance: domain context, destructiveness asymmetry, preview mechanics, then the API reference links. Dense but every sentence carries information; the trailing documentation URLs are the only near-dead weight.

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 zero-required-parameter draft tool with an output schema, this covers what the agent still needs: what the preview contains, when it returns NO_CHANGE, what the confirmation step is, and how stale previews fail. Nothing material to correct invocation is 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real decision context the schema lacks: the 2-month default, the 14-month standard-property ceiling, and the 50-month 360 ceiling, which directly informs value selection. It does not clarify reset_user_data_on_new_activity beyond what the schema already says, keeping it from a 5.

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?

Names a specific verb and resource ('Draft a change to how long GA4 keeps event- and user-level data') and immediately flags that the output is a PREVIEW rather than an applied change. That preview framing is the exact distinction an agent needs against the many sibling draft_* tools and against confirm_and_apply.

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?

It clearly states the workflow position: 'Nothing changes until confirm_and_apply applies it', with a dry-run that re-reads settings and refuses if GA4 changed since the preview, plus the NO_CHANGE outcome. What's missing is guidance on the inverse—e.g. pointing to get_ga4_property or audit_ga4_property for inspecting current retention without drafting a change.

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

All AdLoop tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.