AdLoop

Key event import check

check_key_event_imports

Read-only

Check that every GA4 key event reaches Google Ads: imported, used for bidding, and actually receiving conversions.

Matches the property's key events with the Google Ads conversion actions that import them (by GA4 property and event name), and compares GA4's key events from Google Ads traffic (google / cpc) with the conversions Google Ads recorded for each import. insights[] names key events no conversion action imports, imports that are only secondary (reported, not bid on), imports that stay at zero while GA4 counts Google Ads conversions (a broken link or auto-tagging), and imports of events that are no longer key events. Imports from other GA4 properties are listed separately.

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

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": "check_key_event_imports"
  }
}

Input Schema

Name	Required	Description
`customer_id`	No	Google Ads customer ID, digits with or without dashes. Defaults to the configured ads.customer_id.
`property_id`	No	GA4 property as "properties/123456789" or the bare numeric ID. If empty, uses the default from config.
`date_range_end`	No	End date as "YYYY-MM-DD" (inclusive).
`date_range_start`	No	Start 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the matching key (GA4 property plus event name), that the two sources are compared, that other-property imports are listed separately, and it names the insight categories. That is useful, but return-shape detail is largely deferred to the existing output schema, so a 3-4 is warranted.

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 purpose sentence is front-loaded, and each following sentence adds distinct information (matching logic, insight categories, other-property separation). Slightly dense and the API documentation links at the end are of marginal value to an agent, but nothing is padding.

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?

For a cross-system diagnostic, the description covers what is compared, how records are matched, and what each insight category means, while annotations handle safety and the output schema handles return shape. Only minor gaps remain, such as default date behavior and possible rate/scope limits across two APIs.

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%, with defaults and date-range pairing rules documented in the schema itself. The description adds no parameter-level meaning (no mention of date_range handling or customer_id defaults), so baseline 3 is appropriate.

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 with scope: 'Check that every GA4 key event reaches Google Ads: imported, used for bidding, and actually receiving conversions.' That three-stage scope clearly separates it from GA4-only siblings like audit_event_coverage or list_key_events, letting an agent tell which tool covers the GA4-to-Google Ads import link without opening a schema.

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?

The failure modes it detects (unimported key events, secondary-only imports, zero-conversion imports, deleted key events) give clear implied context for when to run it, e.g. debugging missing conversions. It does not explicitly name alternative tools or state when not to use it, which keeps it below a 5.

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.