Skip to main content
Glama
kLOsk

AdLoop: Google Ads, Reddit Ads & GA4

Campaign conversions against Analytics

analyze_campaign_conversions
Read-only

Maps Google Ads campaign clicks to GA4 conversions to reveal click-to-session ratios, compare reported conversions, and compute true cost-per-conversion.

Instructions

Campaign clicks → GA4 conversions mapping — the real cost-per-conversion.

Combines Google Ads campaign metrics with GA4 session/conversion data to reveal click-to-session ratios (GDPR indicator), compare Ads-reported vs GA4-reported conversions, and compute cost-per-GA4-conversion. Also returns non-paid channel conversion rates for comparison context. GA4 conversions are the property's key events (GA4 metric keyEvents).

Google Analytics Data API: https://developers.google.com/analytics/devguides/reporting/data/v1 and Google Ads API: https://developers.google.com/google-ads/api/docs/start

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
customer_idNoGoogle Ads customer ID, digits with or without dashes (e.g. "123-456-7890"). Defaults to the configured ads.customer_id.
property_idNoGA4 property as "properties/123456789" (see get_account_summaries). If empty, uses the default from config.
campaign_nameNoOptional case-insensitive substring; only campaigns whose name contains it are included. Empty = all campaigns.
date_range_endNoEnd date as "YYYY-MM-DD" (inclusive).
date_range_startNoStart date as "YYYY-MM-DD". Both dates must be set to apply a range; if either is empty, the last 30 days are used.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.27.1
    • addedInput schema / properties / campaign_name / description
      Added value: +"Optional case-insensitive substring; only campaigns\nwhose name contains it are included. Empty = all campaigns."
    • addedInput schema / properties / customer_id / description
      Added value: +"Google Ads customer ID, digits with or without dashes\n(e.g. \"123-456-7890\"). Defaults to the configured ads.customer_id."
    • addedInput schema / properties / date_range_end / description
      Added value: +"End date as \"YYYY-MM-DD\" (inclusive)."
    • addedInput schema / properties / date_range_start / description
      Added value: +"Start date as \"YYYY-MM-DD\". Both dates must be set\nto apply a range; if either is empty, the last 30 days are used."
    • addedInput schema / properties / property_id / description
      Added value: +"GA4 property as \"properties/123456789\" (see\nget_account_summaries). If empty, uses the default from config."
  2. First observedv0.9.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the click-to-session ratio acts as a GDPR indicator, GA4 conversions map to the property's keyEvents, and non-paid channels are returned as comparison context.

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 core purpose is front-loaded in the first line as a headline, followed by concrete analytical outputs. It is appropriately sized, though the trailing API documentation links are somewhat marginal and not strictly necessary for invocation.

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

Completeness4/5

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

An output schema exists, so return values need not be spelled out, and the readOnly/openWorld annotations cover trust signals. The description supplies enough cross-source context (what is combined and why) for an agent to call the tool correctly, with only when-to-use routing left unaddressed.

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 every parameter (customer_id, property_id, campaign_name, date ranges) is already documented in the schema, including defaults and the 'last 30 days' fallback. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.

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 names a specific verb+resource (Campaign clicks → GA4 conversions mapping) and enumerates concrete outputs: click-to-session ratios, Ads-vs-GA4 conversion comparison, cost-per-GA4-conversion, and non-paid channel rates. It clearly distinguishes itself as a cross-source Ads+GA4 tool, though it never names a sibling to compare against.

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?

Usage is implied by the specific analysis described (real cost-per-conversion across Ads and GA4), but there is no explicit when-to-use guidance and no named alternatives among siblings like attribution_check or get_campaign_performance. The agent can infer the scenario but receives no routing help.

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