Google Ads - AdLoop

by kLOsk

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Tracking coverage audit

audit_event_coverage

Read-only

Audits event tracking by cross-referencing codebase events with GTM tags and GA4 fires to identify gaps and statuses.

Instructions

Three-way audit: codebase events ↔ GTM tags ↔ GA4 actual fires.

First, search the user's codebase for gtag('event', ...) and dataLayer.push({event: ...}) calls and extract every distinct event name. Pass that list as expected_events. The tool fetches the LIVE GTM container, joins it against GA4 event counts for the date range, and returns a per-event matrix with one of these statuses: ok — tag active and event firing ok_auto_collected — GA4 Enhanced Measurement event, no tag needed no_tag_no_fire — codebase event, no GTM tag, never fires tag_paused — GTM tag exists but is paused tag_active_but_not_firing — tag is active but no GA4 hits gtm_only_firing — GA4 event from a tag, not in codebase gtm_paused_but_firing — only paused tag(s), not in codebase, yet GA4 still fires (event comes from elsewhere) gtm_only_not_firing — tag exists, not in codebase, no fires ga4_only — fires in GA4, no tag, no codebase ref ga4_fires_no_tag — codebase event firing without a GTM tag auto_event_only — Enhanced Measurement event with no codebase ref

Also surfaces dynamic-event tags ({{Event}} variables) and Custom HTML tags that the audit cannot interpret automatically.

GTM IDs come from Tag Manager UI → Admin → Container Settings. Date format: "YYYY-MM-DD". Empty = last 30 days.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`property_id`	No
`date_range_end`	No
`gtm_account_id`	No
`expected_events`	Yes
`date_range_start`	No
`gtm_container_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.13.2Sep 7, 2026
Removedv0.13.0Jul 22, 2026
Addedv0.12.0Jul 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. It adds substantial behavioral detail: the tool fetches the LIVE GTM container, joins GA4 counts, and returns a per-event matrix with enumerated statuses. It also transparently surfaces limitations by stating that dynamic-event tags and Custom HTML tags cannot be interpreted automatically. This goes well beyond the annotations and gives the agent a clear picture of what the tool will and won't do.

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 description is long but every sentence earns its place: the purpose is front-loaded, input preparation is clear, and the exhaustive status list is necessary to convey the output matrix. It is structured with line breaks and a bullet-like list, making it scannable. While it could be trimmed slightly (e.g., some statuses are self-explanatory), the detail is justified given the tool's complexity.

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?

The tool is complex with multiple inputs, an output schema, and a detailed status taxonomy. The description covers the audit process, input preparation, output semantics (via statuses), and known limitations. It also mentions the date-range default. Given that an output schema exists, it does not need to describe return structures, and it omits nothing critical for an agent to invoke the tool correctly. The coverage is comprehensive for its complexity.

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 schema description coverage at 0%, the description carries the burden of explaining parameters. It thoroughly explains expected_events ('Pass that list as expected_events'), date range ('Date format: YYYY-MM-DD. Empty = last 30 days'), and GTM IDs ('GTM IDs come from Tag Manager UI → Admin → Container Settings'). The GA4 property_id is not explicitly named, but the description's mention of GA4 event counts implies its necessity. It adds meaning to most parameters but leaves property_id to inference, so it's strong but not perfect.

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?

The description opens with a clear, specific verb-resource statement: 'Three-way audit: codebase events ↔ GTM tags ↔ GA4 actual fires.' It names the exact components and distinguishes itself from generic tracking tools by describing the cross-referencing behavior. The detailed status list further clarifies the tool's scope, making it unambiguous among siblings like validate_tracking.

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 provides clear context on how to prepare inputs: how to extract expected_events from the codebase, where to find GTM IDs, and the date format. However, it does not explicitly state when to use this tool versus alternatives like validate_tracking or get_tracking_events, nor does it give exclusion conditions. It offers strong contextual guidance but no explicit when-not or alternative routing.

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

Deploy Server