I built a Google Ads MCP because AI could read my data but couldn't fix it

Kanwar Kohli — Sat, 23 May 2026 21:32:45 +0000

I own a wood-fired pizza restaurant in Iowa.

Last month I noticed my Google Ads were burning money. Low conversions, weird CPC spikes on Fridays, one campaign doing everything. I asked Claude to help me fix it. Claude could read the data. It could tell me what was wrong. But it couldn't actually change anything.

So I built GadsChain.

The problem with existing tools

Windsor.ai and Supermetrics connect AI to Google Ads data. They're great for analytics. But they can only read — pause a campaign, update a budget, add negative keywords? Not possible.

I needed AI that could act, not just report.

What I found in the data

Before building anything, I pulled 28 days of my restaurant's Google Ads data and had Claude analyze it:

Total spend:       $51.41 over 28 days
Clicks:            163
Impressions:       3,389
CTR:               4.81% (above average)
Conversions:       3
Cost/conversion:   $17.14

The CTR was actually good. The problem was elsewhere.

Finding 1 — Friday anomaly. Friday CPC was $0.11 vs $0.44 average. That's Display Network traffic mixing in — low intent, low quality clicks burning budget.

Finding 2 — Conversion tracking broken. Only 3 conversions in 28 days from 163 clicks. Most days showed zero. The tracking wasn't firing correctly.

Finding 3 — Destination URL broken. The campaign was pointing to a subdomain I'd deleted months ago during a DNS cleanup. Google had been trying to crawl a dead URL since May 3. Zero impressions for three weeks because of one broken link.

Finding 4 — Wrong campaign type. Running Performance Max instead of Search. PMax is opaque and needs 30+ conversions to optimize. With 3 conversions it was flying blind.

Claude identified all of this. But I had to fix it manually — clicking through Google Ads UI one setting at a time.

That's the gap GadsChain fills.

What GadsChain does

GadsChain is an open-source MCP server that gives AI assistants direct write access to Google Ads.

Three layers:

Google Ads API → [Fetch] → [Transform] → [Act] → AI Agent
                  GAQL      micros→$      mutate
                  queries   CTR norm      campaigns

Fetch — GAQL queries for campaigns, search terms, budget data.

Transform — Converts raw protobuf responses. Micros to dollars, decimal CTR to percentage, enum names extracted, None values handled gracefully. The AI gets clean data, not raw API output.

Act — Six tools that actually change things:

get_campaigns(customer_id)
get_search_terms(customer_id, campaign_id, days)
update_budget(customer_id, campaign_id, daily_budget_usd)
pause_campaign(customer_id, campaign_id)
enable_campaign(customer_id, campaign_id)
add_negative_keywords(customer_id, campaign_id, keywords)

Safety controls built in:

REMOVED status blocked — irreversible, hard error
Shared budgets refused — explicit error instead of silent mutation affecting multiple campaigns
Missing credentials raise on first tool call, not import

The stack

Language:     Python 3.11
MCP layer:    FastMCP
Google Ads:   google-ads >= 24.0.0
Validation:   Pydantic v2
Config:       python-dotenv
Container:    Docker
Registry:     PyPI

Same stack as ThinChain, our first server (options chain data, 95% token reduction). The pattern works — FastMCP handles the MCP protocol, you focus on the domain logic.

Real numbers after fixes

Within 24 hours of fixing the destination URL and requesting review:

Ads back in Google's review queue
Budget raised from $7 to $20/day
Display Network waste identified and addressable
Conversion tracking being rebuilt

Before GadsChain: AI reads your ad data, you fix it manually.

After GadsChain: AI reads your ad data, AI fixes it.

This is the SnipMCP pattern

GadsChain is the second server under SnipMCP. The thesis:

Every domain has the same problem — raw API data is too noisy, too large, and too complex for AI agents to act on reliably. SnipMCP builds domain-aware MCP servers that sanitize, compress, and structure that data before it reaches the model.

ThinChain: 482 option strikes → 25 relevant ones (95% token reduction)
GadsChain: thousands of ad metrics → actionable signals

Same pattern. Different domain. We're building more.

Get started

pip install gadschain

You'll need:

Google Ads Manager Account (MCC)
Developer token (apply at Google Ads API Center)
OAuth2 credentials from Google Cloud Console

Full setup guide in the README.

GitHub: github.com/SnipMCP/gadschain

ThinChain: github.com/SnipMCP/thinchain

Platform: snipmcp.com

PRs welcome. If you're building MCP servers for other domains, we'd like to talk.

Built a small tool that tells you why your AWS bill changed each week

Kanwar Kohli — Wed, 13 May 2026 16:03:47 +0000

Over the past year I kept seeing the same AWS problem across founders and small engineering teams: the bill changes faster than people can explain it.
Usually nobody notices until month-end, and by then they're digging through Cost Explorer trying to figure out which service changed, what deployment caused it, and whether it's real growth or waste.
So I built a lightweight tool called ThinCost.
It connects to AWS using a read-only IAM role and sends a weekly email explaining what changed, which services drove the increase, potential waste, and concrete actions to reduce spend.
The goal wasn't another dashboard. It was: "Tell me in plain English why my AWS bill changed."
Setup is about 60 seconds: email + AWS account ID → deploy a CloudFormation stack → done. No stored credentials. No write access. Read-only permissions only.
Looking for a handful of beta testers running real AWS workloads. Happy to give free access for a few months in exchange for honest feedback.
→ thincost.com

DEV Community: Kanwar Kohli