SupplyFinder

    Episode 02 ·

    MCP: the protocol everyone name-drops, nobody can explain

    In adtech, the technology is almost never the problem. The operational layer always is. This series is about that gap. One buzzword at a time.

    Walk into any agency meeting and someone will say "MCP." They'll say it with confidence. Ask them what it actually does for a media buyer, and the room goes quiet.

    So let's fix that. No jargon, no hype. Just what MCP is, why you keep hearing it, and the one thing it can't do that everyone implies it can.

    What everyone's saying

    "MCP is the future of programmatic." "Everything's going agentic." "If your stack doesn't support MCP, you'll be left behind." All repeated, rarely explained. That gap between confidence and understanding is the whole reason this series exists.

    What it actually is

    MCP, or Model Context Protocol, is a standard built by Anthropic and open-sourced in late 2024. Strip away the buzz and it's one thing: a universal adapter that lets AI agents talk to advertising platforms without a custom integration for each one.

    Here's the analogy that makes it click. A decade ago, every adtech platform had to build a separate API connection to every other platform. Hundreds of bespoke pipes, each one maintained by hand. MCP is the equivalent moment for AI agents: a platform builds one MCP server, and any MCP-compatible app, whichever AI it runs on, can reach it through the same standard. One integration instead of a hundred. For you, that means the tools you already work through stop being islands.

    That's it. That's the whole idea. It's plumbing. The most hyped acronym in our industry turns out to be a connector, which is exactly why what gets built on top of it matters more than the connector itself.

    Why it matters when you're the one spending the budget

    Two reasons, one happening now and one coming fast.

    Happening now, and it's worth reading carefully, because "we support MCP" doesn't mean the same thing twice.

    Google and Amazon have both opened MCP servers on their own ad stacks. That's real, and it's useful: if you're already buying there, your agents reach those capabilities through one clean standard instead of a custom build. The thing to understand is the scope. These connect you to them. The agent reaches into one platform's world and works within it.

    Then there's a different kind of move. Picture two independent platforms, one demand-side, one supply-side, wiring their agents together over MCP so their systems negotiate directly, instead of a human exporting logs from one and re-keying them into the other. What's notable isn't the speed. It's the shape: two separate companies letting their systems talk to each other, with no one's platform sitting in the middle. That's a different promise. Not "reach into my platform," but "my platform and yours can coordinate."

    Both are MCP. Both are legitimate. But they solve different problems. One connects you more deeply to a single environment, the other connects environments to each other. For you, knowing which one a vendor means is the difference between automation that locks you in tighter and automation that gives you room to move.

    So here's the question to put on the table the next time a partner tells you "we support MCP": does that connect me to you, or does it connect you to everyone else? You'll learn more from how they answer that one sentence than from the rest of the deck.

    Coming fast: this isn't a fringe experiment. The IAB Tech Lab is already keeping an agent registry for MCP-based advertising, and platforms are signing up. Once the standards body keeps the list, "optional" becomes "expected," the way programmatic forced every vendor to expose an API a decade ago. So within a year, the platforms your teams buy through will either speak this language or fall behind the ones that do. You don't need to write the integration spec. You need to know which side of that line your media is on, because the gap won't announce itself. It shows up as campaigns that run smoother somewhere else, and nobody tells you why.

    One caution before anyone oversells you. MCP won't make your campaigns perform better. It removes friction: the plumbing gets smoother, the back-and-forth gets shorter. That's worth having, but smoother plumbing and better media are different promises, and the industry keeps selling the second as if it were the first.

    What nobody selling you MCP will admit

    Most of the time, it's overkill.

    I'll say it plainly, because it's the part that gets left out of every keynote: a large share of the "MCP-powered" use cases I see in the wild are an API call wearing a costume. Someone wrapped a single, predictable action (pull a report, push a budget, sync a feed) in a protocol designed to coordinate a hundred moving parts, and called it agentic. It's not. It's a wrapper, with more failure points than the API it replaced.

    Here's the test that cuts through it. Ask one question: does each step depend on what the last one sent back, or is the whole path locked in before it starts?

    A path that's locked in before it starts (one platform, one action, every Monday) is a job for a plain API. You don't need MCP, and anyone telling you otherwise is selling you architecture you'll pay to maintain for no reason.

    Yes, MCP also standardizes a discoverable toolset, and that has its own value. But if that's all you're getting, you're paying orchestration prices for a connection problem.

    MCP earns its place when orchestration is the actual problem: several systems, no fixed path, where each step depends on what the last one returned. Think of diagnosing why a deal underdelivers: query demand, then supply, then the next move changes based on what came back. There, the value is real, because the hard part was never the connection. It was the coordination.

    The real question nobody's asking

    Here's where I'll be honest, because that's the point of this series.

    MCP doesn't make anyone smarter. It makes them faster. There's a sentence worth keeping in mind: if the inputs are wrong, all MCP does is help you reach the wrong answer faster.

    We spent this whole piece on a protocol, and the thing that decides whether it helps you isn't the protocol. It's whether the layer above it knows what it's doing. The pipe is solved. The decision isn't.

    That's the pattern, and it's the thing to carry into every one of these acronyms: in adtech, the technology is almost never the problem. The operational layer always is. MCP is the transport. The protocols riding on top of it, the ones that decide how buying actually gets negotiated, are where the power sits. And that fight has already started.

    That's where this series goes next.


    Maxime Khalfallaoui, Supply Finder. I came up on the SSP side. Now I help agencies find their way through it.

    Questions people actually ask

    What is MCP (Model Context Protocol) in advertising?
    A standard, open-sourced by Anthropic in late 2024, that acts as a universal adapter so AI systems can talk to advertising platforms without a custom integration for each one. A platform builds one MCP server, and any MCP-compatible client can reach it. It is a connection layer, not a decision-making layer.
    Does "supporting MCP" mean the same thing for every platform?
    No. It can mean a platform lets your agents reach deeper into its own environment (connecting you to them), or it can mean two independent platforms let their systems coordinate directly (connecting platforms to each other). Both are legitimate, but they solve different problems. One locks you in tighter, the other gives you room to move.
    When is MCP overkill versus genuinely useful?
    If the path is known (one platform, one predictable action), you usually do not need MCP, you need an API. MCP really earns its keep when orchestration is the actual problem: several systems, no predetermined path, and the agent has to reason its way through. It can also add value as a standard, discoverable interface to a whole toolset, even for simpler tasks, but if a clean interface is the only benefit, weigh it honestly. The hard part, when it is there, was never the connection, it was the coordination.
    What should I ask a vendor who says they support MCP?
    Ask: does that connect me to you, or does it connect you to everyone else? And separately: is the path fixed in advance, or does it have to adapt based on what each system returns? A fixed path is a job for a plain API. The answers tell you whether you are looking at real infrastructure or an API wearing a costume.