All posts
aimcpself-hostingn8nautomation

Running 4 MCP servers on my own servers, so AI can read real ad data

Why a paid media manager self-hosts Model Context Protocol servers for Google Ads, GA4, YouTube and Search Console, and what that makes possible.

By Abdul Haseeb

Running 4 MCP servers on my own servers, so AI can read real ad data

Ask a general AI chatbot why your Google Ads cost per acquisition went up last week and you will get a very confident, very generic answer. Seasonality. Competition. Maybe check your Quality Score.

All technically true. All completely useless, because the model has never seen your account.

The fix is not a better prompt. It is giving the model access to the actual data. That is what my self-hosted AI stack does, and the piece that makes it work is a set of four MCP servers running on my own infrastructure.

What MCP is, in plain English

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, for connecting AI models to external tools and data. Think of it as a universal adapter. An MCP server wraps a data source, say the Google Ads API, and exposes it as a small set of tools the model is allowed to call: "get campaign performance for this date range", "list search terms", that sort of thing.

The model does not get a password and free rein. It gets a menu of specific actions, and it decides which ones it needs to answer the question in front of it.

The four servers

I run one MCP server per data source:

  • Google Ads for spend, conversions, cost per acquisition, search terms and auction data
  • GA4 for what visitors do after the click
  • YouTube for video campaign and channel data
  • Search Console for organic search queries and pages

One per source keeps each server small and easy to reason about. If Google changes one API, one server changes.

Why self-host instead of using a hosted service

There are hosted services that will connect an AI model to your marketing accounts. For client data, I prefer to keep the connection on infrastructure I control, for three reasons:

  1. Credentials stay with me. API access to a client's ad account is sensitive. On my own servers, the credentials never get handed to another third party.
  2. No one else's rules. Hosted platforms come with their own rate limits, their own pricing tiers and their own decisions about what you are allowed to connect.
  3. I can change it. When I need a new tool on a server, I add it. I do not file a feature request and wait.

The servers run on the Oracle Cloud servers I administer myself, which also host my mail server. Learning to stand those up, lock them down and keep them running was not optional, because there was nobody else to hand it to.

The rest of the stack

MCP servers on their own are just plumbing. Three more layers turn them into something the team actually uses:

  • Orchestration. n8n, a self-hostable workflow automation tool, runs the scheduled and triggered workflows. Gemini and Google Antigravity handle the tool calling: deciding which MCP tool to call, with which parameters, and how to combine the results.
  • Joining the data. A useful answer almost always needs three or four sources joined together. That joining is the work a person used to do by hand across five open dashboards.
  • A chat interface. The people who need answers are not going to open a terminal. So there is a simple chat UI on top. Ask in plain English, get an answer built from live account data, with no ad platform login required.

That last layer matters more than it sounds. If the interface is technical, the system quietly stops being used, and then none of the rest of it mattered.

The stack, top to bottom
  1. Chat UIPlain English in, no ad platform login
  2. Orchestrationn8n, Gemini, Google Antigravity
  3. 4 MCP serversGoogle Ads, GA4, YouTube, Search Console
  4. 3 Oracle Cloud serversAdministered by me, credentials stay here

What a question actually looks like

Say someone asks: "Why did cost per acquisition go up on the brand campaigns last week?"

One question, traced through the stack
  1. 01Chat UIThe question arrives
  2. 02OrchestrationPicks the sources it needs
  3. 03MCP serversLive numbers from each API
  4. 04AnswerWhich cause the data supports
  1. The question arrives in the chat UI from someone who does not have Google Ads access.
  2. The orchestration layer works out that this needs spend and conversions from Google Ads, landing page behaviour from GA4, and auction data from the same ad account.
  3. Each MCP server calls its own platform API and returns live numbers for the requested window.
  4. The reply names the campaigns, the direction they moved, and which explanation the data actually supports: did competitors push up prices in the auction, or did the landing page start converting worse?

That is the difference between "maybe check your Quality Score" and an answer you can act on.

Guardrails I would recommend to anyone building this

  • Start read-only. Let the model look before you ever let it touch. Changes to live budgets should stay a human decision.
  • Give narrow tools, not raw API access. A tool that answers one question well is safer and more reliable than a general "call any endpoint" tool.
  • Check the numbers. Models can still misread data. Spot-check answers against the platform until you trust them, and keep doing it occasionally after that.

Why a paid media manager does this at all

Because the bottleneck in performance marketing was never a lack of data. It was the time it takes to pull four sources together and work out what actually happened. Automating that is the same instinct that made me build CrewSpace instead of chasing approvals by hand.

You can see the full stack, layer by layer, in the AI stack chapter on the homepage. If you want something like this for your own accounts, get in touch.

Keep reading