What MCP changes about asking AI for marketing numbers.

MCP is a common interface between an assistant and a tool that holds data. Before a standard existed, every pairing of one assistant with one platform was built by hand, which meant the number of integrations to maintain grew with the number of pairs.

A tool now publishes a server that describes what it can be asked for, and any assistant that speaks the protocol can ask. That is the whole of it. It standardises the call, not the answer, and understanding that distinction is what keeps expectations in the right place.

Access, which used to be the expensive part. Three things get easier and they are worth having.

• One way in per tool

  Connecting an assistant to a platform stops being a bespoke project. The work moves to whoever publishes the server, which is usually the platform rather than you.

• A described surface

  The server states what it can be asked for. The assistant stops guessing at parameter names and field names, which is where a lot of the wrong answers used to come from.

• Permission in one place

  Access is granted per server rather than per script, so read-only is something you can actually enforce and later revoke.

Every server answers about its own tool, in its own vocabulary. Ask what a client spent across all channels last month and the assistant makes one call per platform, gets back several differently shaped results, and adds them up inside its own context.

That is a join, performed by a language model, at the moment of asking. There is no key, no check that the two sides share a grain, and no currency conversion unless the model decides to do one. It will return a number, and the number will look exactly like a correct one.

There is a second cost that shows up later. Every question re-reads the platforms, so nothing is kept. Ask the same question twice a fortnight apart and you cannot tell whether the answer changed because performance changed or because a platform restated a closed day.

When the question lives inside one tool. What is the status of this campaign, which ad sets are not delivering, what is in this account. These are lookups against a single source, the vocabulary problem never arises, and going through a warehouse to answer them would be a detour.

The line is the second source. As soon as a question needs two platforms compared, or this period set against the same period last year, the assistant needs somewhere the two already agree. Reconciling them in the moment is the thing that cannot be made reliable by a better model.

For an agency there is a further case past that line. A question across clients, such as which accounts underspent this month, is a join across every client's accounts, and no single server holds it.

Every source lands modelled in a warehouse you own: one name per metric, one type, one grain and one currency. The reconciling happens in SQL, before anybody asks a question, rather than in a model's context afterwards.

The chatbot reads those same tables on your own model key, and so do the client dashboards, so the two cannot disagree. Because the tables are added to rather than replaced, a comparison with last quarter is a query against history you hold rather than a fresh call to a platform that may have revised it.