MCP Is Not Your Client Reporting System

By Ben Luong - Monday June 15, 2026 Share (Twitter) WhatsApp Summarize ChatGPT Perplexity Grok Google AI Before getting into reporting systems and why MCP is not your clients reporting system, it is worth defining what MCP is. MCP stands for Model Context Protocol.

In plain English, it is a standard way for an AI assistant such as Claude to connect to outside tools and data sources. An MCP server is the connector in the middle: one might expose Google Ads, another GA4, another BigQuery.

Instead of exporting a CSV, opening another tab, and pasting numbers into a chat, Claude can ask the connected system for data directly. For PPC work, that is useful because most reporting questions start messy. You do not always know the exact column, date range, or follow-up question before you begin.

You ask what changed last week, see something odd, then ask why. That is where MCP is genuinely good. Connect Claude to Google Ads or GA4 with something like GoMarble MCP and you can ask what changed last week without exporting CSVs or building pivot tables. I use it for ad-hoc investigation regularly, and it is faster than the alternative.

The mistake is treating that as a client reporting system. People connect via GoMarble to a platform and assume they have solved reporting. They have made ad-hoc queries easier to run. Getting to client-ready reporting takes more than that. For Internal Account Work, Google Ads Is Often Enough Google Ads has decent native reporting.

The Reports section covers campaign movement, search terms, asset performance, and budget pacing without leaving the platform. It is not widely used, but the Gemini report generator changes the trade-off. For internal account checks, you can often describe the report you want in plain English and build it inside the interface.

Google Ads can already generate reports inside the native interface. For internal account work, that is often enough. Image source: Author screenshot from Google Ads interface. Not AI-generated. That is the point of the screenshot above. Gemini is already doing a lot of the report-building work.

If the question is an internal account question and Google Ads can answer it cleanly, use Google Ads. The external Claude, MCP and BigQuery stack earns its keep when the question needs governed definitions, joined data or client-facing commentary. The problem starts when the report goes to a client. A client is asking what happened to the business.

Google Ads can tell you what it thinks happened, inside its own attribution model, during its own reporting window. Clients usually need data from more than one source to answer that question properly. MCP for Ad-Hoc Investigation Direct MCP connections work well when the question is investigative and one-off. What changed last week?

Which campaign shifted the most spend? Is this conversion drop real or did tracking break? That kind of work is exploratory. You do not know the exact question before you start. You pull context, follow threads, ask follow-ups. MCP handles that well. It is faster and lower-friction than downloading reports and hoping the columns line up.

This is also where direct MCP shines because the question is disposable. You want an answer, not a permanent reporting asset. The limitation is that you are querying the platform directly. Google Ads describes Google Ads. GA4 describes GA4. Client reporting usually needs the join between them.

BigQuery for Everything That Matters Twice If a metric goes in a client report or affects budget decisions, it should not depend on Claude reconstructing the definition from a prompt each time. Put it in BigQuery. Client reporting needs a memory. BigQuery gives it one. Getting data in is straightforward. Google’s native transfers cover most of it.

Weavely handles Google Ads and GA4 without much configuration if you want something lighter. Supermetrics will do it too if you are already paying for it across your client stack, though it costs more than most accounts need for this specific use case. Once the data is there, create views.

Brand versus non-brand New versus returning customers Qualified leads Margin-adjusted revenue Whatever matters to the account, defined in one place. Brand versus non-brand is the simplest example. Google Ads does not always split this in the way a business needs.

You create a BigQuery view that labels campaigns using your naming convention or an agreed definition. The logic lives in the view. The next time you ask Claude about non-brand performance, it queries the view and gets back the same answer from the same definition it used last time.

If “BigQuery view” sounds too technical, think of it as a saved version of the reporting logic. You are not asking Claude to remember how you define non-brand every time. You are giving it a clean table to query. There is a token cost argument here too. When Claude queries a live platform via MCP, the raw