Claude MCP for Marketers: What It Is, What It Unlocks
The short version
MCP is a standard that lets a model call your systems directly, so your AI reads the GA4 property instead of asking you to paste the report. It's governed by the Linux Foundation now, and the same server works in ChatGPT, Gemini and Copilot as well as Claude, so a system you connect once works with all of them. Connecting is the easy part. The work comes after: deciding what each tool is allowed to write, and writing tool descriptions clear enough that the model picks the right one.
Anthropic published the Model Context Protocol on November 25, 2024, as an open standard for connecting AI systems to the places data actually lives. On December 9, 2025 they donated it to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg supporting it.
Why the handover matters: when one model vendor owns a protocol, adopting it ties your systems to that vendor's roadmap. A foundation backed by Google, Microsoft, AWS and OpenAI is not steered by any one of them, so you can build against MCP without betting on a single company.
That same announcement counted more than 10,000 active public MCP servers and 97M+ monthly SDK downloads across Python and TypeScript, with client support in ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. So a server you build for Claude can be used by those other tools too.
This is rung two of the Claude adoption ladder, written by a team that runs custom servers in production on client work. The pillar explains what a connector is. This one is about what to do with it, and what goes wrong.
What MCP standardizes
There are three parts to it. Vendors use the words loosely, so here is what each one means.
Hosts are the AI applications you sit in front of: Claude Desktop, ChatGPT, your IDE. Clients are the connectors living inside that host. Servers are the things that expose your systems to it. The messages between them use JSON-RPC, an established format your developers will already know.
A server offers three kinds of thing, per the 2026-07-28 specification. Resources are context and data. Prompts are templated workflows a person chooses. Tools are functions the model can call on its own initiative. Tools are where nearly all the value is for a marketing team. They are also where nearly all the risk is.
Here is what that changes. Before MCP, every AI integration was custom work that only paid off inside one product. Now you make a system speak MCP once, and every model that speaks MCP can reach it.
What it unlocks
The first change: you stop moving data between windows. Ask about last month's organic performance and the model queries Search Console for the answer, then checks GA4 to see what those sessions did after they landed. Nothing to export, paste or screenshot, and the numbers are current at the moment you ask.
That sounds minor. It isn't. A large part of an analyst's week goes into assembling data before anyone can ask a question of it.
The second change is bigger, and most people miss it: a server can write as well as read. We run one for Google Merchant Center enrichment across several client catalogs. It reads product health, then publishes enriched attributes through a supplemental feed, and every value it writes is grounded in a real source on that client's own site. A person approves each batch before it goes. We wrote up what that audit actually found.
The third change is that the work carries over. A server you build so Claude can read your catalog is the same server ChatGPT or Copilot reads it through, with no second integration to write. So build it properly the first time. It is also why the governance change above matters.
Stock connector or custom server
A rule that has held up for us: use a stock connector when the job is to read a system. Build a custom server when the job has steps in it, especially steps that change something.
Stock connectors are the ones a vendor already built and maintains: Drive, Slack, GitHub, your CRM. You authenticate and they work. Most teams should start here and plenty should stay here permanently. Anthropic counts over 75 connectors powered by MCP in Claude alone, so the odds are decent that your system is already covered.
The build case shows up when the work is a sequence: read Merchant Center, validate, ground each value in a real source, publish, and log what changed, with a person approving somewhere in the middle. No generic wrapper does that, because the sequence is specific to how you work. At that point you are building software that a model happens to drive, and it needs the budget and testing any other software would get.
The other reason to build your own is surface area. A generic wrapper often hands the model forty tools when the job needs four, and every extra tool is one more thing it can pick by mistake.
Your tool descriptions are copy
The model chooses which tool to call by reading that tool's description. So the description is copy. It is written for a machine rather than a person, and it needs the same care you would give a button label.
When one of our servers misbehaves, the cause is rarely the code. It's usually a description that read clearly to the engineer who wrote it and ambiguously to the model. Two tools that both sound like they list campaigns. A parameter documented as "the id" in a system that has three kinds of id. The model picks whatever the description pointed it at, and the description pointed it at the wrong thing.
What fixed it was treating those strings as microcopy: say what the tool does, name the exact input it wants, and say when not to use it. We now write tool descriptions before the code, the same way you would settle a button label before designing the flow behind it.
This is also the easiest thing to check if you are using someone else's server. If a connector keeps picking the wrong tool, read the descriptions it is working from before you blame the model.
What breaks
Start with security, because the specification is strict about it. Tool descriptions "should be considered untrusted, unless obtained from a trusted server," and hosts must obtain explicit user consent before invoking any tool. In plain terms: anything a server tells your model is input, and input can be hostile. A connector you install from a public directory is someone else's code running with your permissions.
Another problem we run into has cost us more time than security has. Two connectors can expose tools with identical names pointed at completely different accounts, and the name tells you nothing about which one you're holding. Every server we use now has to answer "which site are you" before any write, and we ask it every run rather than trusting the answer from the last one.
Next, permissions. Anything that can write can break something, so each of our connections carries a ceiling: read only, propose a change for a person, or apply it directly. Most sit on the middle setting for months. Moving one up is a decision somebody makes deliberately, and it's the same conversation as working out which use cases are worth an agent at all.
Last, cost and clutter. Every connected server spends context describing itself before the model does any work, so a host with a dozen connectors installed runs slower and chooses worse than one with three. Connect what the job needs and turn the rest off.
How to try it in a week
Pick the system you export from most often. For most marketing teams that's Search Console, GA4, or the ad platform.
Connect the stock connector for it, read only, then spend a week asking it the questions you'd normally build a report to answer. Keep a note of which ones it handles well and which ones still sent you into the platform's own interface.
That list answers the question for you. The ones it handled are reporting work you can stop doing by hand. The ones it fumbled tell you whether the gap is the connector, the way your data is organized, or a question that needed a person all along. Only after that is it worth talking to anyone about a custom build.
Do the week before you buy anything. Vendors demo the reading part, which is the easier half of the problem.
Where this goes
Connectors are what make rung four possible. An agent can only act on the systems it can reach, and the permissions you set on those connections decide how much it is allowed to do. Set those permissions carefully now and there is less to undo later. Once several are running, you need something that reads their work for you.
Start with one connector, read only, on the system you're tired of exporting from. Give it a week. Find out what your AI can actually reach before you decide what it should be allowed to change.
We build and run this stack with brand marketing teams, and we're happy to give you a straight read on which of your systems are worth wrapping. Start a conversation.
