What is MCP? The Model Context Protocol, explained for marketers

Put the same request to two assistants: build the audience for a 60-day win-back.

The first writes segment logic against attribute names it has inferred from the question — last_purchase_date, total_orders, the names those fields usually have. Reasoning sound, field names fictional until somebody opens the platform and checks. That checking is your job, it takes twenty minutes, and it is why the answer ends up feeling less useful than it sounded.

The second calls out to your ESP — your email service provider, the platform you actually send from — pulls the attributes that exist on your users, finds the field is called last_order_at and that a third of your active users have it empty, and says the segment as written would return almost nobody. Same model, same reasoning. The difference is that it was handed a way to look.

MCP is the plumbing that hands over the login. Nothing more mystical than that, and worth understanding precisely, because plumbing is where your customer data and your API keys travel.

The letters stand for Model Context Protocol: an open standard, published by Anthropic and since implemented by a range of other assistant and developer tools, describing a single job — how an AI assistant is handed capabilities it can use mid-conversation.

Before a shared standard existed, every AI product that wanted to reach into Braze or HubSpot or your warehouse built a private bridge, and that bridge worked with exactly one assistant. A standard collapses that. One side publishes a list of things it can do, in a described format; the other reads the list and calls what it needs. Anyone who has watched martech spend a decade arguing about integration formats will recognise the shape of the win.

The vocabulary arrives with two words, both worse than they need to be.

Server names the component you install — the piece publishing that capability list. It does not imply remote. Most marketing MCPs are a small process running on your own laptop; Orbit installs as a desktop extension file you double-click, and it runs where you are sitting. Some vendors host theirs instead, which is a genuinely different arrangement and the subject of a later section.

Client is the assistant app doing the asking — Claude Desktop, a coding tool, whatever you already talk to. No new interface to learn. You keep typing in the same box; the assistant now has somewhere to look before it answers.

For a marketing team the practical consequence is that "AI tooling for lifecycle" has become a category with a common shape rather than a pile of one-off plugins, so the questions you put to a vendor can be the same questions every time. Which is most of what this guide is for.

Installing an MCP brings two things, and they do opposite jobs.

A tool is a verb.A named function with defined inputs and outputs that the assistant can call and you can watch it call: fetch this segment's size, list the custom attributes on this workspace, compile this template, upload this content block, render this email at 390 pixels wide and report its byte size. Tools are where reach lives — which is why the list of tools a vendor ships is a security document as much as a feature list.

A skill is a procedure. A written method the assistant loads when the conversation calls for it: the checklist a senior operator carries in their head, made explicit. Skills touch no data. They change the order of operations — what gets asked before anything is built, which failure modes get checked, what counts as finished — and load on demand, so carrying dozens costs nothing on a conversation about none of them.

Tools without skills gives you a very fast junior with production API access and no method; it will do precisely what you asked, including when what you asked was wrong. Skills without tools gives you excellent advice that cannot check itself, which is the ordinary chat-assistant experience. The combination is the point of the category.

Worked example, using Orbit because it is the one I can describe honestly. Ask "is this email ready to send?" and the skill supplies the pre-send checklist — what a reviewer looks for, and in what order. The tools then measure: compile the template, render it at desktop and phone widths, check contrast and tap-target size, count the bytes against the threshold where Gmail truncates a message and hides the rest behind a "View entire message" link, and render each branch of the personalisation separately so you see the version your user with no first name receives. The Gmail clipping guide covers that last measurement properly; a byte count is the canonical example of something a language model cannot estimate and a tool gets exactly right.

One test transfers to every vendor in the category: can it ever come back and say no? A review that has only ever returned approval is a formality with good manners. Tools are what make refusal possible, because refusal requires evidence.

Most explainers skip this part, and your security review will open with it. Three hops, three different answers.

The extension itself.A locally installed MCP is a process on your computer, and installing it sends nothing anywhere. Credentials go into the assistant app's own settings — in Orbit's case, Settings › Extensions › Orbit › Configure — and stay on the machine. The vendor never holds them.

The platform call.When a tool reads your segment, the request goes from your machine to your ESP's API and back, the same path your browser takes when you open the dashboard. Nobody in the middle.

The model. The hop people miss. Whatever a tool returns becomes part of the conversation, and the conversation is processed by whoever provides the model, under your agreement with them. Pull five thousand user records into a chat and those records have been read by the model provider. Not a vendor doing something behind your back — it is how the assistant reads anything at all — but a real boundary, and it belongs on your data map.

The discipline that follows is small and worth making a habit: pull the narrowest slice that answers the question. A segment's size rather than its members. The attribute schema rather than the attribute values. Aggregate on the platform side wherever the platform can. A tool making it trivial to haul a customer list into a chat window is not an argument for doing it, and the restraint that keeps personalisation from feeling invasive applies here too.

None of the four shapes is disqualifying. A hosted MCP is often the only way a SaaS vendor can ship one, and plenty of teams are fine with that. Not knowing which row you are in is the disqualifying part.

Separately from all three hops, ask what the extension reports back to its own maker. Orbit's version, offered as the shape of answer to expect rather than a claim about anyone else's: aggregate install and tool-invocation counts plus friction signals, redacted on your machine before sending, no prompts and no workspace contents, and an environment variable that switches it off entirely. Agree with those specifics or not — that is the level of detail a vendor should produce without needing a follow-up call.

These transfer to any vendor in the category, including ones that do not exist yet. Anybody who cannot answer the first three in a sentence each has told you something useful.

Add two that are less about the vendor and more about you. Does anyone on the team already hold a key with send permissions sitting in a config file, because an assistant that can send is a different risk category from one that can read, and most teams should stay on the reading side for the first month. And does consent and preference data travel with the user records these tools will read, so an audience built inside a chat window still respects the choices people made? Murky answers there point at a data-model problem rather than an AI one, and the custom attributes guide is the better starting place.

Whether the tool earns a place in the stack at all — what it duplicates, where it creates a second source of truth — is an ordinary martech question and answers to ordinary martech methods. The Martech Stack Audit skill is the version we use, and the CRM versus CDP decision guide applies the same reasoning to a heavier purchase.

Connect a read-only key first. Ask something you already know the answer to — how many users are in this segment, which attributes exist on this workspace — because the first test is of the plumbing, not the intelligence. Verify it in the dashboard in thirty seconds, three or four times over, before letting anything write.

Then the ceiling, honestly stated. An MCP will not make the model understand your business: that Tuesday sends underperform because half your list is in stand-ups, that legal has a view on the word "free", whether the programme should exist at all. Nor does it make the model right. What it provides is somewhere to look, which converts a category of confident guesses into checkable claims — and the guesses were the expensive part.

Data quality comes along unimproved, too. An assistant reading a messy event taxonomy reads the mess faster and with more conviction, so the fix stays upstream in the data model rather than in the tooling.

For the longer version of what changes in day-to-day work once the assistant can open the artefact it just wrote, the with-and-without walkthrough runs five ordinary tasks both ways, and the deliverability guide is a good example of the standing constraints that have to be written down somewhere the tools can reach.

One line to take into the vendor call: ask where the server runs, and which tools can write. Everything else in this guide follows from those two answers.