Skip to main content
Glama
AdLoop: Google Ads, Reddit Ads & GA4

AdLoop: Google Ads, Reddit Ads & GA4

Apply a previewed change

confirm_and_apply
Destructive

Execute a previously previewed ad change by plan_id: dry-run validation by default, then set dry_run=false to apply after review.

Instructions

Execute a previously previewed change.

IMPORTANT: Defaults to dry_run=True (validate only). Only an explicit dry_run=false applies the change to the ad account (Google Ads or Reddit Ads — the plan knows which platform it targets).

Forced dry runs: when real changes are switched off (live changes off for the workspace in AdLoop Cloud, or safety.require_dry_run in a self-hosted config), dry_run=false is IGNORED and the result is still DRY_RUN_SUCCESS, with 'dry_run_forced_by' and 'remediation' fields. 'remediation' says how the user switches that setting; until it is changed, repeated calls with dry_run=false change nothing.

Two-phase apply: if 'safety.two_phase_apply: true' is set (always on for AdLoop Cloud tenants), dry_run=false is REFUSED with status DRY_RUN_REQUIRED until this plan_id has completed one dry_run=true pass. The sequence is: dry run, review of its result, then the real apply.

Google Ads plans: the dry run sends the exact mutates to Google with validate_only=True, so Google checks the change and executes nothing (checks counts the validated calls). Steps that build on an object an earlier step would create cannot be validated and are counted as skipped.

Reddit plans: Reddit has no validate-only mode, so the dry run re-reads the target entity and re-checks the safety caps (returned as checks).

A DRY_RUN_FAILED result means the change does not go through as previewed. The real apply fails the same way, unless Google rejected only part of the request: then it carries out the rest and reports those operations again.

Returns a status with the plan_id and operation: DRY_RUN_SUCCESS, DRY_RUN_FAILED, DRY_RUN_REQUIRED, BLOCKED, APPLIED, PARTIAL_UPLOAD, PARTIAL_APPLY, UNKNOWN_OUTCOME or APPLY_IN_PROGRESS. BLOCKED means the operation was added to safety.blocked_operations after the draft: nothing ran and the plan stays pending. APPLIED results carry the created or changed resource names under 'result'. PARTIAL_UPLOAD belongs to the upload tools: the batches it lists are already in the account, so the plan is retired. 'sent_total', 'accepted_total', 'rejected_total' and 'resume_from_line' say how far the upload got and at which CSV line a new draft continues; when a batch's fate is unknown, 'unknown_status', 'uncertain_lines' and 'row_errors' name the rows whose outcome has to be checked first. PARTIAL_APPLY and UNKNOWN_OUTCOME come from platforms without transactional writes: part of the change is in the account ('created' names it), or a create was never answered. The plan is retired; read the account back and draft only what is missing. APPLY_IN_PROGRESS means an earlier call claimed this plan first, so this call executed nothing.

Approval cards: in AI apps that show AdLoop's approval card with the preview, dry_run=false is REFUSED with status APPROVE_ON_CARD, because only the user's click on the card applies the change. Dry runs still work. The workspace owner can allow approval in chat as well.

Confirmation dialogs: in apps that show dialogs instead, dry_run=false first asks the user in a dialog. A declined dialog returns NOT_CONFIRMED; an app that receives the dialog but never answers it gets CONFIRMATION_UNANSWERED on the next call, with the ways out.

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan_id": "<plan_id>"
    },
    "name": "confirm_and_apply"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNoTrue (default) validates without changing anything; false applies the change for real.
plan_idYesThe plan_id returned by a prior draft_*, update_*, add_*, pause/enable/remove or other preview tool call. An unknown or expired plan_id returns an error.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.27.1
    • addedInput schema / properties / dry_run / description
      Added value: +"True (default) validates without changing anything; false\napplies the change for real."
    • addedInput schema / properties / plan_id / description
      Added value: +"The plan_id returned by a prior draft_*, update_*, add_*,\npause/enable/remove or other preview tool call. An unknown or\nexpired plan_id returns an error."
  2. Addedv0.13.2
  3. Removedv0.13.0
  4. First observedv0.9.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructive and open-world, and the description goes well beyond them: dry_run is silently ignored under workspace/config safety switches with 'dry_run_forced_by' and 'remediation' returned, and repeated calls change nothing until the setting is flipped. Per-platform dry-run semantics (Google validate_only with skipped dependent steps, Reddit re-read with safety cap re-checks) and partial/unknown outcome handling are all disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical constraint (default dry_run=True, explicit false to apply) is correctly front-loaded, but the body is bloated with material that does not belong to this tool — it openly notes that PARTIAL_UPLOAD, 'sent_total', 'resume_from_line' and CSV line tracking belong to the upload tools. The trailing API documentation links add no selection value.

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 destructive, policy-gated apply tool this covers the risky paths an agent must reason about: forced dry runs, two-phase refusal, approval-card and dialog flows, and non-transactional partial results. An output schema exists, yet the status taxonomy is still explained enough to act on each outcome.

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 baseline is 3, but the description adds real meaning: dry_run's default is enforced by external policy and can be overridden, and plan_id must come from a specific prior preview call and must have survived one dry run. It stops short of adding expiry window or ID format detail beyond what the schema states.

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 gives a specific verb and resource ("Execute a previously previewed change") and the dry_run explanation makes the two modes concrete. The plan_id reference to prior draft_*/update_* tools separates it cleanly from the sibling draft tools that only preview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit conditions are given for both modes: dry_run=true to validate, dry_run=false only after a completed dry-run pass when two_phase_apply is set, refused under approval-card apps, dialog-mediated in others. It also states when not to expect an apply (forced dry runs, BLOCKED operations) and what sequences are required.

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