Typed beats prompted
The Google Ads API is notoriously easy to get subtly wrong – resource names, micros, versioned fields. A typed tool carries none of that surface into the model's hands.

Google Ads MCP
Google Ads waste hides in different places than Meta's: keywords quietly buying brand searches you already win, broad match drifting into irrelevance. Finding that takes analysis; fixing it takes a change inside the account. MCP closes the distance between the two without handing an AI the keys.
A Google Ads MCP server exposes the Google Ads API to an AI agent through the Model Context Protocol: a fixed set of typed tools – read spend and search terms, pause a keyword, adjust a campaign budget – each with validated parameters and its own permission. The agent proposes; a write executes only after a human approves that specific call.
A small surface is a security feature: every tool the agent does not have is a mistake it cannot make. Reads run freely – that is how the case gets built. Writes wait for you.
| Tool | Access | What it does |
|---|---|---|
| get_campaigns | read | Campaign and ad group structure, status and budgets |
| get_search_terms | read | The queries that actually triggered your ads – where brand waste shows up |
| get_spend | read | Cost per campaign, ad group and keyword over any window |
| pause_keyword | write · approval | Stop one keyword – the classic fix for paid brand cannibalisation |
| set_campaign_budget | write · approval | Change a daily budget, bounded by limits you set |
The Google Ads API is notoriously easy to get subtly wrong – resource names, micros, versioned fields. A typed tool carries none of that surface into the model's hands.
The AI can read search terms all day. The moment it wants to pause the keyword buying your own brand name, it writes a proposal with the evidence – and waits.
Every executed call stores who approved it, the numbers cited, Google's response and the previous state. One click puts it back.
This is the demo’s own Google Ads verdict, followed from the first read to the log entry – real numbers, no hypotheticals.
get_search_terms and get_spend pull 30 days on the keyword "løbesko": €8,400 spent, healthy click volume, conversions reported by Google.
Matched against real orders the keyword produced €0 in profit – the conversions land on brand searches you already win organically. Google counted them; the order book already owned them.
The proposal names one call – pause_keyword – and attaches the spend, the matched orders and the overlap with organic brand traffic.
The exact call waits in AI Actions. Nothing reaches the account until a human approves this specific change.
On approval the call executes against the Google Ads API in about a second. The log stores who approved it, the numbers cited, Google's response and the previous state – revert is one click.
Different jobs, not just different quality – which is why the comparison has columns instead of a winner’s podium. Some accounts run all three.
| MCP + approval | Ads scripts | Automated rules | |
|---|---|---|---|
| Who writes the logic | The profit engine – COGS, matched orders, repeat behaviour | You, in JavaScript, against a versioned API | You, in a form, one trigger at a time |
| Sees COGS and repeat rate | Yes, from Shopify and Stripe | Only if you build and maintain a data pipeline | No |
| Human approval | Every write, per call | None once scheduled | None once enabled |
| Maintenance | None on your side | Scripts rot as API versions retire | Rules drift silently as accounts change |
| Audit trail | Full: approver, evidence, response, one-click revert | Google's change history | Google's change history |
The loop, on Google Ads – from the demo

Google Ads → Kepra
Reading
spend + matched orders
Deciding
profit after COGS and LTV
Your call
nothing moves until you say so
Pushing
executed over MCP, logged
Verdict: The keyword "løbesko" has spent €8,400 in 30 days for €0 profit – the clicks convert on brand searches you already win.
A system that only claims wins is a brochure. These are the boundaries, stated as plainly as the features.
A server that exposes the Google Ads API to AI agents as typed tools over the Model Context Protocol. The agent calls tools like get_search_terms or pause_keyword with validated parameters instead of composing raw API requests, and every write requires human approval per call.
Pausing keywords that buy traffic you already own – brand searches converting through paid clicks that would have arrived organically. The demo's verdict is exactly this: a keyword that spent €8,400 in 30 days for €0 in profit.
No. Reads run freely; writes stop at an approval naming the exact change. The commitment is contractual, not configurable.
Kepra is in private development. The demo shows the full loop on sample data, and the waitlist is the way in when access opens.
Scripts automate what you already decided; they cannot weigh COGS, repeat rates and matched orders to decide what deserves changing. Here the AI does the analysis and argues its case – and you stay the one who decides.
Through typed tools, yes: the agent cannot compose raw API requests, writes carry hard bounds and stop at a human approval, and every change is logged with one-click revert. The risky versions are API keys pasted into a chat, or a browser agent driving the Ads interface unsupervised.
No. That is the practical difference from Ads scripts: the tools exist already, the agent calls them, and your job is reading the evidence and approving or declining. Nothing to write, nothing to maintain when the API version rotates.
The demo is open – no signup. AI Actions shows a proposal, the evidence, and the approval step exactly as it ships.
Also running Meta Ads? Meta Ads MCP →