Skip to main content
Glama
kLOsk

Google Ads - AdLoop

by kLOsk

audit_event_coverage

Read-only

Audit event coverage across your codebase, Google Tag Manager, and GA4. Identify unmatched, missing, or extra events to ensure complete tracking.

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
NameRequiredDescriptionDefault
property_idNo
date_range_endNo
gtm_account_idNo
expected_eventsYes
date_range_startNo
gtm_container_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Annotations indicate read-only and non-destructive behavior, which is consistent. The description adds transparency by detailing the audit process (fetching live GTM, joining GA4 counts), the returned status matrix, and limitations (e.g., dynamic-event tags). No contradictory behaviors are mentioned.

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 well-structured, with a clear opening sentence and bullet-pointed statuses. It is front-loaded with the key purpose, and each section adds value. Some redundancy or excessive detail could be trimmed, but it remains efficient for the complexity.

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?

Given the tool's complexity, the description covers the input preparation, output statuses, and inherent limitations. It assumes the output schema exists (not shown) but provides context. Slight gaps in error handling or edge cases (e.g., what if GTM container not found) prevent a perfect score.

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?

With 0% schema description coverage, the description partially compensates by explaining the required parameter expected_events (extracted from codebase) and date format. However, optional parameters like property_id, gtm_account_id, and gtm_container_id are only vaguely referenced ('GTM IDs come from Tag Manager UI'), lacking explicit semantics.

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 explicitly states 'Three-way audit: codebase events ↔ GTM tags ↔ GA4 actual fires,' providing a clear and specific verb-resource combination. This distinguishes it from sibling tools that focus on ad campaign management or other audit tasks.

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?

The description gives detailed instructions on how to prepare inputs (e.g., codebase search for expected_events, GTM IDs from UI, date format) but does not explicitly contrast with sibling tools like validate_tracking or get_gtm_tag. Usage context is implied but not stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kLOsk/adloop'

If you have feedback or need assistance with the MCP directory API, please join our Discord server