Skip to main content
Glama
Sign In
AdLoop: Google Ads, Reddit Ads & GA4

AdLoop: Google Ads, Reddit Ads & GA4

by kLOsk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Draft an Analytics key event

draft_key_event

Draft marking a GA4 event as a key event, or change its counting method and default value, returning a preview with a plan_id so nothing changes until confirmed.

Instructions

Draft marking a GA4 event as a key event (conversion), or changing an existing one — returns a PREVIEW.

The fix for "the event fires but isn't tracked as a conversion": attribution_check / validate_tracking diagnose it, this closes the loop. When the event already is a key event, the plan changes its counting method or default value instead and the preview shows before and after; nothing to change returns NO_CHANGE. Applies to future data only. Returns a preview with a plan_id and warnings; nothing changes until confirm_and_apply applies it.

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

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": {
      "event_name": "<event_name>"
    },
    "name": "draft_key_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
event_nameYesName of the GA4 event to mark as a key event, exactly as it fires (e.g. "sign_up", "purchase"). Required.
property_idNoNumeric GA4 property ID, with or without the "properties/" prefix. If empty, uses the default from config.
currency_codeNoThree-letter currency of default_value, e.g. "EUR".
default_valueNoValue GA4 gives each key event when the event sends no value parameter, e.g. 20 for a lead. Needs currency_code.
counting_methodNoONCE_PER_EVENT (counts every occurrence, e.g. purchases) or ONCE_PER_SESSION (counts once per session, e.g. sign-ups). Defaults to ONCE_PER_EVENT.ONCE_PER_EVENT

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.41.4
    • addedInput schema / properties / currency_code
      Added value: +{
+  "default": "",
+  "description": "Three-letter currency of default_value, e.g. \"EUR\".",
+  "type": "string"
+}
    • addedInput schema / properties / default_value
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Value GA4 gives each key event when the event sends\nno value parameter, e.g. 20 for a lead. Needs currency_code."
+}
  2. Changed3 schema fields changedv0.27.1
    • addedInput schema / properties / counting_method / description
      Added value: +"ONCE_PER_EVENT (counts every occurrence, e.g.\npurchases) or ONCE_PER_SESSION (counts once per session, e.g.\nsign-ups). Defaults to ONCE_PER_EVENT."
    • addedInput schema / properties / event_name / description
      Added value: +"Name of the GA4 event to mark as a key event, exactly as it\nfires (e.g. \"sign_up\", \"purchase\"). Required."
    • addedInput schema / properties / property_id / description
      Added value: +"Numeric GA4 property ID, with or without the \"properties/\"\nprefix. If empty, uses the default from config."
  3. Addedv0.13.2
  4. Removedv0.13.0
  5. Addedv0.12.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds the crucial nuance that this draft performs no mutation at all until confirm_and_apply, and that it 'applies to future data only'. It also discloses the preview payload (plan_id, warnings) and the alternate behavior when the event is already a key event. Minor gap: no mention of auth/permission requirements for the openWorld call.

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 key facts — preview semantics and the confirm_and_apply gate — are front-loaded, and the workflow framing is efficient. The trailing Google Analytics API documentation links do not help an agent decide or invoke the tool and slightly dilute the otherwise tight text.

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 five-parameter draft tool with an output schema and annotations, the description covers everything an agent needs: what it does, when to use it versus the diagnostic and apply siblings, that it is non-mutating, and the NO_CHANGE outcome. Return-value details are correctly left to the output schema.

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 100%, so all five parameters including counting_method and default_value are already documented in the schema. The description only obliquely gestures at them ('the plan changes its counting method or default value instead'), adding little beyond the structured data. Baseline 3 applies.

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 ('Draft marking a GA4 event as a key event (conversion)') and immediately qualifies the scope with 'or changing an existing one — returns a PREVIEW.' This distinguishes it cleanly from draft_delete_key_event and from the confirm_and_apply step that actually mutates state.

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

Usage Guidelines5/5

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

Explicitly positions the tool in a workflow: attribution_check / validate_tracking diagnose the problem, this 'closes the loop', and nothing changes until confirm_and_apply applies it. It also names the no-op case ('nothing to change returns NO_CHANGE'), so the agent knows what a null result means.

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