How to Manage PPC Campaigns Using a CLI and AI

Why GUIs limit advanced PPC management

Google released its official Ads MCP server in April 2026, and Meta launched its Ads CLI on April 29 the same month [1] [2]. For the first time, the two largest ad platforms are shipping first-party tools designed to be operated from a terminal, not a browser. If you manage campaigns at any real scale, the question is no longer whether CLI-based PPC management is viable but how quickly you should adopt it, and where the gaps still are.

Anyone who has bulk-edited 200 ad groups inside the Google Ads web interface knows the pain. You click, wait for a page render, click again, confirm a modal, wait for another render. Batch operations that should take seconds stretch into minutes because the GUI was designed for comprehension, not throughput. Google Ads Editor helps, but it is still a desktop application with its own sync quirks and a workflow that bottlenecks at the “post changes” step. The fundamental issue is that graphical interfaces serialize human attention: you can only look at one screen, one table, one campaign at a time.

Scripts and APIs have always been the escape hatch, of course. Google Ads Scripts (JavaScript in the browser) and the REST API (via client libraries) let power users automate reporting and bid changes. But writing against those APIs requires substantial boilerplate: OAuth token management, pagination handling, error retry logic, and familiarity with GAQL or the Meta Marketing API’s graph structure. That overhead kept CLI-style automation in the domain of engineers, not media buyers. What changed in 2026 is that the platforms themselves started packaging that complexity into tools that assume a terminal-first user, and that AI agents can call those tools directly through a standardized protocol.

Essential tools for a CLI-based workflow

Three categories of tooling matter here: platform-native CLIs and MCP servers, third-party orchestration layers, and the AI coding agents that tie everything together.

On the Google side, the official Google Ads MCP server is a Python-based package you install via pipx from the google-ads-mcp GitHub repository [3]. It exposes two primary tools: search, which accepts arbitrary GAQL queries against your account, and list_accessible_customers, which returns the customer IDs your credentials can reach. Configuration requires a developer token, a Google Cloud project ID, and application credentials, all passed as environment variables. One critical limitation: it is read-only. You can pull campaign performance, keyword stats, and account structure, but you cannot push bid changes or create campaigns through the official server. Community forks like the google-ads-gemini-extension project on GitHub add write capabilities, though I have not verified their production readiness [4].

Meta’s offering is more complete. The Ads CLI (pip install meta-ads-cli) wraps the Marketing API behind commands like meta ads campaign list and meta ads campaign create, with flags for budget, objective, and targeting [5]. It supports both table and JSON output, which means you can pipe results into jq, feed them to a reporting script, or hand them to an AI agent for analysis. Authentication is a one-time browser-based OAuth flow via meta auth login. Meta also shipped a separate MCP server that lets Claude and ChatGPT manage campaigns without a developer app, which is a meaningful reduction in setup friction [6].

Now campaigns, budgets, insights, catalogs, even pixels can be managed from a simple command layer designed to run in scripts and pipelines.

Gurudev, LinkedIn post on Meta Ads CLI

For Google Ads write operations and cross-platform orchestration, Composio’s universal CLI fills a gap. It handles OAuth and exposes Google Ads actions (creating customer lists, for instance) through a single interface that AI agents like Claude Code can call [7]. Microsoft Ads is the weakest link in this ecosystem: there is no official CLI or MCP server, and the existing Python SDK dates from the Bing Ads era with no verified 2026 AI integration [8]. If Microsoft Ads is a significant part of your spend, expect to write more custom glue code.

Building a new campaign with a simple script

I want to walk through what a CLI-based campaign creation actually looks like, because the abstraction level matters. On Meta, creating a campaign from the terminal is a single command with flags:

meta ads campaign create –name “Q3 Prospecting” –objective OUTCOME_TRAFFIC –daily-budget 5000 –status PAUSED

That command returns a campaign ID, and you can immediately follow it with ad set and ad creation commands, all scriptable. The –format json flag lets you capture the response programmatically, so a bash script can create a campaign, parse the returned ID, and use it to build ad sets in sequence. Exit codes follow Unix conventions, which means you can chain commands with && and halt on failure, something no GUI workflow supports natively [5].

On Google Ads, the story is less clean. Because the official MCP server is read-only, building a new campaign requires either the REST API via a Python script, a third-party tool like Composio, or a community MCP extension. A typical Python script using the Google Ads client library runs 60 to 100 lines for a basic campaign with one ad group and a handful of keywords, most of which is authentication and resource name construction. The MCP approach with Composio shortens this to a natural-language prompt if you have already authenticated, but you are trusting a third-party abstraction layer with write access to your ad account, which is a tradeoff worth weighing carefully.

The real power of scripted campaign creation is not the single campaign. It is the template. Once you have a working script that creates a campaign structure, you can parameterize it: swap in different budgets, targeting criteria, or ad copy from a CSV or a database query. I have seen teams use this pattern to spin up dozens of geo-targeted campaigns from a single spreadsheet, a task that would take hours in the UI and minutes in a terminal. The risk, predictably, is that a bug in your script creates dozens of misconfigured campaigns instead of one, so version control and a staging account are not optional.

Automating bidding and reporting via CLI

Bid management is where the time savings claims get aggressive. One vendor blog from Ryze AI states that conversational AI reduces bid management from 12+ hours weekly to under 2 hours, with a setup time of under 10 minutes compared to 2 to 4 hours for traditional automation [9]. I would treat those numbers with skepticism, since they come from a company selling AI-powered PPC tools, but the directional claim is plausible for accounts where bid adjustments are frequent and rule-based.

Here is how the workflow actually functions. You connect an AI agent (Claude, Gemini, or a custom LLM) to your ad platform via MCP. The agent can then execute GAQL queries against Google Ads or pull insights from Meta’s CLI. You prompt it with something like “show me all keywords with ROAS above 400% and CPC below $2 in the last 14 days,” and it constructs and runs the query, returning structured data. For bid changes on Meta, the agent can issue CLI commands to adjust budgets or pause underperforming ad sets. On Google, write operations still require API calls through the client library or a third-party connector.

Reporting is where CLI workflows shine with less controversy. Pulling a weekly performance report from Meta is a single command:

meta ads insights get –campaign_id 23847123456789 –date-preset last_7d –fields impressions,spend,conversions –format json

Pipe that into a script that calculates derived metrics, formats a Slack message, and posts it to your team channel, and you have a reporting pipeline that runs on a cron job without anyone opening a browser [5]. Google’s MCP server supports the same pattern for read queries, so you can build a unified report that pulls from both platforms, normalizes the data, and outputs a single dashboard update. The friction is in the normalization, since Google and Meta define metrics differently (attribution windows, conversion counting), and no CLI tool solves that semantic problem for you.

One practical consideration that rarely appears in setup guides: data latency varies across platforms. Google Ads data is typically available within a few hours, but Microsoft Ads can lag 2 to 6 hours behind [10]. If your automated bidding script runs at 6 AM and Microsoft data has not refreshed, you are making decisions on stale numbers. Build in checks for data freshness, or schedule your automation to account for the slowest platform in your stack.

Using AI to generate and debug scripts

The most underrated part of this entire workflow is not the CLI tools themselves but the fact that AI coding agents can write, test, and fix the scripts that call them. I tested this with Claude Code connected to the Google Ads MCP server: I asked it to write a Python script that pulls campaign performance for the last 30 days, flags any campaign where cost-per-conversion increased more than 20% week-over-week, and outputs a summary table. Claude generated a working script on the first attempt, including the GAQL query, the pandas transformation, and the output formatting. When I introduced a deliberate error in the credentials path, it diagnosed the issue from the traceback and suggested the fix.

The server exposes specific tools that an LLM can discover and invoke autonomously.

Google Ads MCP server documentation

This is the real shift that MCP enables. Because the protocol is standardized, an AI agent does not need custom instructions for each API. It discovers available tools, reads their schemas, and constructs valid calls. Google’s MCP server documentation explicitly describes this autonomous discovery pattern [1]. In practice, this means a media buyer who can describe what they want in plain English can get a working automation script without writing code from scratch, though they still need enough technical literacy to review the output, understand what the script does, and catch errors before they hit a live account.

Where AI generation falls short is in handling platform-specific edge cases. GAQL has quirks (resource names, segmentation constraints, metric availability by report type) that trip up even experienced developers. An AI agent will sometimes generate a syntactically valid query that returns an unhelpful error because it requested a metric that is not available at the requested segmentation level. Debugging these issues requires reading the Google Ads API documentation, not just re-prompting the AI. The same applies to Meta’s CLI: the agent might construct a command with a valid flag combination that fails because of a business rule (you cannot set a daily budget below the platform minimum for your currency, for example).

My recommendation is to treat AI-generated scripts as first drafts. Run them against a test account or in dry-run mode before pointing them at production campaigns. Use version control. Add logging. These are basic software engineering practices, but they matter more when the person writing the code is an LLM that cannot tell you about the assumptions it made.

When to stick with the standard UI

I have been fairly bullish on CLI workflows throughout this piece, so let me be direct about where they are a poor fit. If you manage a single account with fewer than 20 campaigns and your optimization cadence is weekly, the Google Ads UI or Meta Ads Manager is probably faster. The setup cost of configuring MCP servers, managing API credentials, and learning CLI syntax only pays off when you are doing the same operations repeatedly across many campaigns or accounts.

Creative management is another area where the GUI wins decisively. Reviewing ad copy, checking image crops, previewing responsive display ads across device formats: these are visual tasks that a terminal cannot replicate. You can use the CLI to pull performance data on creative variants and identify winners, but the actual review and approval process belongs in a visual interface. The same goes for audience exploration and discovery. Browsing Meta’s detailed targeting options or Google’s audience segments is an inherently browse-and-select activity that does not translate well to command-line flags.

Account-level settings, billing, and access management are also better handled in the UI. These are infrequent, high-stakes operations where the confirmation dialogs and visual feedback of a GUI provide genuine safety value. Nobody wants to accidentally change their billing method via a mistyped CLI command.

There is also a team dynamics consideration. If you are the only person who understands the scripts, you have created a bus-factor-of-one problem. CLI workflows need documentation, and ideally, more than one person on the team should be able to read and modify them. For teams without any engineering support, the learning curve may outweigh the efficiency gains, at least until the AI agent layer matures enough to handle more of the complexity transparently.

The honest assessment is that CLI and AI-driven PPC management is powerful but early. Google’s MCP server is read-only. Meta’s CLI is weeks old. Microsoft Ads has no equivalent. Amazon Ads has no verified CLI or MCP integration at all. The vendors making the boldest efficiency claims are selling tools, not publishing peer-reviewed studies. What I would do right now is set up the Google Ads MCP server for reporting (it is free and read-only, so the risk is minimal), experiment with Meta’s CLI for campaign creation in a test account, and wait for write support on Google’s side before committing to a fully automated bidding pipeline. The direction is clear, even if the road is not fully paved.

How to Write a Business Plan for a Mobile App

Why Your AI Ad Strategy Is Only As Good As Your Data