AdLoop: Google Ads, Reddit Ads & GA4

Overview Schema Source Related Servers Discussions Admin

Draft enhanced conversions upload

draft_upload_enhanced_conversions_for_leads

Draft an Enhanced Conversions for Leads upload from a CSV, hash raw customer PII for matching, and preview row counts and consent before confirming the Google Ads upload.

Instructions

Draft an Enhanced Conversions for LEADS upload from a CSV — PREVIEW.

Uploads lead conversions via ConversionUploadService.UploadClickConversions with user_identifiers, matching hashed customer PII back to the Google users who clicked the ads. The CSV holds RAW PII in columns: Email, Phone Number, First Name, Last Name (plus Conversion Name, Conversion Time, Conversion Value, Conversion Currency; optional Order ID dedup key, and optional Ad User Data / Ad Personalization consent columns).

PII is normalized and SHA-256-hashed AT PREVIEW TIME — only the hashes are stored in the plan. Raw email/phone/name never land in the plan or the audit log. A cell that already is a SHA-256 hex digest (a CRM export that hashes before writing) is used as it is. The target conversion action must be UPLOAD_CLICKS-type.

An Order ID column makes re-uploads dedup instead of double-counting.

Rows that repeat inside one file are named in dedup_warnings. Rows sharing an Order ID count once at Google; two rows with different Order IDs are two real orders and are not reported.

The CSV comes from csv_path (a file on the machine running AdLoop) or from upload_id (a file uploaded with upload_conversion_csv, the only way on AdLoop Cloud). An uploaded file is deleted once the draft has read it.

Returns a preview with a plan_id, the row counts, the consent the rows actually carry (consent_summary) and the skipped rows; nothing is uploaded until that preview is confirmed.

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

Input Schema

Name	Required	Description
`consent`	No	Consent signals for GDPR/EEA, as an object with "ad_user_data" and/or "ad_personalization", each "GRANTED", "DENIED" or "UNSPECIFIED". None sends UNSPECIFIED. A row whose own "Ad User Data" / "Ad Personalization" columns are filled in overrides this for that row; empty cells fall back to it.
`csv_path`	No	Path of the CSV file holding the upload rows, read on the machine that runs AdLoop. Refused on the hosted server; use upload_id there.
`upload_id`	No	Id of a CSV uploaded with upload_conversion_csv (up_...), instead of csv_path.
`customer_id`	No	Google Ads customer ID (digits, e.g. "1234567890"). Empty uses the configured default account.
`default_region`	No	ISO 3166-1 alpha-2 country assumed for phone numbers that carry no country code, e.g. "DE" for "0151 12345678". Empty leaves such numbers unusable; the row still uploads when its email or its complete address identifies the lead.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.33.1Oct 22, 2026

addedInput schema / properties / csv_path / default
```
Added value: +""
```

changedInput schema / properties / csv_path / description

Previous value: -"Path of the CSV file holding the upload rows, read on the\nmachine that runs AdLoop. The hosted server refuses this tool\nrather than reading a path of its own."New value: +"Path of the CSV file holding the upload rows, read on the\nmachine that runs AdLoop. Refused on the hosted server; use\nupload_id there."

addedInput schema / properties / upload_id

Added value: +{
+  "default": "",
+  "description": "Id of a CSV uploaded with upload_conversion_csv (up_...),\ninstead of csv_path.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "csv_path"
-]
```

Addedv0.27.1Oct 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) it discloses exactly what happens to data: PII is normalized and SHA-256-hashed at preview time, only hashes land in the plan or audit log, an uploaded file is deleted once read, and nothing is uploaded until the preview is confirmed. It also explains dedup behavior via Order ID and dedup_warnings, which the agent could not infer from the annotations.

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 scoping line is front-loaded and the paragraphs are tight and information-dense, but the trailing Google Ads API documentation link adds nothing for an agent already choosing between tools, and the return-value paragraph partly duplicates the output schema.

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 preview/draft tool with full schema coverage and an output schema, everything an agent needs is present: input source selection, PII handling, consent fallback, dedup semantics and the confirmation gate. The brief recap of the preview payload is redundant but not harmful.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema cannot carry: the required and optional CSV columns, the fact that an already-hashed cell is used as-is, and how an Order ID column changes double-counting. default_region's consequence (numbers without a country code become unusable) is echoed but not expanded beyond the schema.

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 opening line states a specific verb (Draft), a specific resource (an Enhanced Conversions for LEADS upload from a CSV) and the operational mode (PREVIEW), which separates it from the sibling draft_upload_call_conversions and from the mutating confirm_and_apply step.

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 gives concrete prerequisites (the target conversion action must be UPLOAD_CLICKS-type) and routes between the two input modes: csv_path is refused on the hosted server, where upload_id from upload_conversion_csv is 'the only way'. It does not explicitly name a competing sibling to prefer instead, so it stops short of full when/when-not guidance.

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

Deploy Server