Ask Your Marketing Data Questions in Plain Language: MCP for Claude and ChatGPT

The gap between having marketing data and getting answers from it is mostly a translation problem. The question is "which creative angle is driving new customers in Austria this quarter," and answering it means knowing which dashboard holds that view, how the filters work, and whether the number that appears is the one you meant. The Model Context Protocol closes that gap by letting an AI assistant query the underlying data directly and return an answer in the form the question was asked. For marketing teams, that is a genuine change in how reporting works, and it arrived recently enough that most brands have not yet worked out what it is good for.

What MCP Actually Is

The Model Context Protocol is an open standard for connecting AI assistants to external systems. Anthropic published it in late 2024 and it has since been adopted broadly, including by OpenAI, which means a single MCP server can serve Claude, ChatGPT, and other compatible clients without separate integrations for each.

The architecture has three parts. An MCP server exposes a set of capabilities from a system, such as an attribution platform. An MCP client, which is the AI assistant, connects to that server. The protocol defines how the assistant discovers what the server can do and how it requests data.

The practical distinction from a chatbot bolted onto a dashboard is meaningful. A dashboard chatbot answers questions about the views it was built to serve. An MCP connection exposes the underlying data structure, so the assistant can compose queries the dashboard designer never anticipated, join across dimensions, and follow up on its own answer when you ask why.

What This Looks Like in Use

The interaction is conversational and iterative, which is where most of the value sits.

You ask which channels drove new customer acquisition last month. You get an answer. You ask how that compares to the same month last year. Then you ask whether the difference is explained by CPM changes or conversion rate. Then you ask to see it split by market.

Each of those follow ups, in a dashboard, is a separate view that either exists or does not. In a conversation, each one is a sentence. The compounding effect is that the analysis goes deeper, because the cost of the next question is near zero rather than being the cost of finding or building the right view.

The second use case is preparation. Assembling a weekly review or a monthly leadership summary means pulling numbers from several places and writing the explanation. An assistant with data access can produce the draft, including the variance explanation, which turns an hour of assembly into a review of something already written.

What It Changes and What It Does Not

It changes who can ask. The most immediate effect is that people who do not know the reporting tool can get answers. A founder, a merchandiser, a customer service lead with a question about a market can ask it in plain language rather than filing a request with whoever owns the dashboard.

It changes the depth of routine analysis. Because follow up questions are cheap, the analysis that actually happens gets deeper. Most people stop at the first answer in a dashboard because the second question requires work.

It does not change data quality. This is the important limit. An assistant querying your attribution data inherits every weakness in that data. If your consent rate is low and a third of orders are modelled, the assistant's confident paragraph is built on modelled orders. If your UTM tagging is inconsistent, the channel breakdown it produces carries the same inconsistency. Plain language access to bad data produces plain language wrong answers, delivered more fluently than a dashboard would.

It does not remove the need to understand the metrics. An assistant can tell you the ROAS on a channel. Knowing that platform ROAS overlaps across networks and cannot be summed is still your job, and an assistant querying attributed data rather than platform data is only giving you the better number if the underlying system is the one that assigns each order once.

It does not replace judgement about what to ask. The quality of the output tracks the quality of the question. "How are we doing" produces a generic summary. "Has new customer CAC in Austria risen faster than in Germany over the last eight weeks, and is the difference explained by CPM or by conversion rate" produces something useful.

Where the Limits Sit

Three practical constraints worth knowing before assuming this solves everything.

Permissions and scope. An MCP connection is an access grant. It should be scoped to what the assistant needs, authenticated properly, and revocable. OAuth based connections are the current standard for this, and a setup that requires pasting a long lived API key into a chat client is worth treating with suspicion.

Data sensitivity. Marketing data usually includes revenue figures and sometimes customer level information. Understand where queries are processed and what is retained before connecting anything containing personal data. This is a question for whoever owns data protection in your organisation, and it is worth resolving before rather than after.

Reliability of interpretation. An assistant can misread a schema, apply a filter differently than you intended, or state a number with more confidence than the underlying data supports. Spot check answers against the dashboard for the first few weeks, particularly for numbers that will end up in a report someone else reads.

Getting Value From It

The criteria that determine whether this is useful rather than novel:

• Is the underlying data trustworthy? Fix consent rates, tagging, and attribution reconciliation first. Conversational access amplifies whatever is already there.
• Is the connection properly scoped and authenticated? Prefer OAuth over static keys, and grant the minimum access needed.
• Are you asking specific questions? Vague questions get vague answers, in any interface.
• Are you spot checking? Especially for numbers that will be quoted to other people.
• Is it replacing work or adding it? The value is in questions you would not otherwise have asked and drafts you would otherwise have written by hand.

The data quality point is the one worth dwelling on. There is a real risk that conversational access makes weak measurement feel authoritative. A dashboard showing a channel breakdown at least looks like a system with settings and definitions, which invites scepticism. A paragraph in natural language explaining that paid social drove 34 percent of new customers reads as a finding. If a third of the orders behind that figure were modelled rather than observed, the paragraph is more confident than the data supports, and nothing in the interface signals that.

The practical mitigation is to ask about it directly. Questions like "what share of these orders were modelled rather than observed" and "does attributed revenue reconcile to shop revenue for this period" are exactly the sort of thing a conversational interface handles well, and they are the questions that keep the rest of the answers honest. An assistant connected to a system that can answer them is more useful than one connected to a system that cannot.

Summary

The Model Context Protocol lets AI assistants query marketing data directly, in plain language, with follow up questions costing nothing. That widens who can get answers beyond the people who know the reporting tool, and it deepens routine analysis because the second and third question stop being work. Draft preparation for weekly reviews and monthly summaries is the other immediate use.

What it does not do is improve the data underneath. Consent rates, tagging consistency, and whether your attribution reconciles to actual revenue all matter exactly as much as before, and conversational access can make weak measurement sound more authoritative than it is. Fix the data first, scope the connection properly with OAuth rather than static keys, ask specific questions, and spot check anything that will be quoted to someone else. Then use the interface for what it is genuinely good at, which is the follow up question you would not have bothered to build a view for.

FAQ

What is the Model Context Protocol?
An open standard for connecting AI assistants to external systems and data sources. It was published by Anthropic and has been adopted broadly, including by OpenAI, which means one MCP server can serve multiple assistants rather than requiring a separate integration per client.

How is this different from a chatbot inside a dashboard?
A dashboard chatbot answers questions about the views it was built for. An MCP connection exposes the underlying data structure, so the assistant can compose queries nobody anticipated, join across dimensions, and follow up on its own answers when you ask why.

Is it safe to connect marketing data to an AI assistant?
It depends on how the connection is scoped and what data it reaches. Prefer OAuth based authentication over long lived API keys, grant the minimum access needed, and check where queries are processed and what is retained before connecting anything containing customer level personal data.

Will it give me accurate numbers?
It will give you the numbers in your data, which is a different question. If your consent rate is low, your tagging inconsistent, or your attribution unreconciled, the assistant reports those weaknesses fluently. Spot check against your dashboard initially, and ask directly about modelled share and revenue reconciliation.

What is it actually best at?
Follow up questions and draft preparation. The compounding value is that asking the second and third question becomes free, so analysis goes deeper than it would in an interface where each new angle requires finding or building a view.