MCP, the Model Context Protocol, is an open standard that lets an AI assistant connect to tools and data, so it can query your Google Analytics, ad accounts or CRM when you ask a question instead of reading a stale export. Google, Meta, HubSpot and PostHog all publish official MCP servers; the Google Analytics and Google Ads servers are read-only, while Meta's and HubSpot's can also make changes. The specification requires user consent before a tool runs but says the protocol itself cannot enforce its security principles, so start every connection read-only and add write access one step at a time.
Monday, 8:40. You export last week from Google Analytics, then Google Ads, then Meta, then the CRM, and paste four CSV files into a chat window. By the time the summary comes back, it describes a week that ended two days ago, built from files you might have cut wrong.
MCP removes the export step. The assistant asks Google Analytics for the numbers itself, at the moment you ask the question, and can show you the exact report it ran.
That makes it one of the plainest wins for a marketing engineer, the marketer who builds systems instead of doing each task by hand. It also hands an AI system the keys to your ad accounts, so the order you connect things in matters more than the tool.
The verdict: connect official servers, start read-only, and check the first answers by hand.
MCP is a set of rules for how an AI app talks to outside systems. The current specification, dated July 28, 2026, names three parts: the host is the AI app you use, a client is the connector inside it, and a server is the program that speaks for one outside system.
A server can offer three kinds of things. Resources are data to read, prompts are saved instructions, and tools are actions the model can run, such as "run this report".
Anthropic introduced the protocol in November 2024 and donated it to the Linux Foundation's new Agentic AI Foundation on December 9, 2025, with OpenAI and Block as co-founders. At that point the Linux Foundation said there were more than 10,000 published MCP servers, and that Claude, ChatGPT, Gemini, Microsoft Copilot, VS Code and Cursor had adopted it.
For you, that means one thing. A server built once works in any of those apps, so the vendor builds it and you just connect it.
Servers run in one of two places. A local server is a program your AI app starts on your own computer and it reads its keys from your environment, while a remote server lives at a web address and, under the spec's authorization rules, signs you in with OAuth 2.1.
The difference shows up in your security review. A local server can reach whatever your computer can, and the spec's security guidance shows how a poisoned install command could copy private keys off the machine; a remote server sees only what you granted at sign-in.
Of the marketing servers below, Google's two run locally by default. Meta, HubSpot and PostHog host theirs.
Connect every MCP server on the lowest rung and climb one rung at a time, only after a clean log on the rung below. Rung one, read: read-only scopes or read-only servers, such as Google Analytics, Google Ads or PostHog's read-only switch. Rung two, draft: writes land somewhere harmless, such as Meta ads created paused or HubSpot changes shown for confirmation.
Rung three, capped: writes allowed inside vendor rules, such as Meta's blocked actions and budget caps per ad account. Rung four, live: changes go out, each one approved by a named person. Write the current rung for each connection into the agent's spec file.
The big marketing platforms now ship their own servers. That matters, because an official server is maintained by the people who own the API and the rules.
Google's Google Analytics MCP server answers questions like how many users you had yesterday, and its setup guide on GitHub asks for the read-only Analytics scope. The Google Ads MCP server is read-only in its current release and runs Google Ads Query Language for you.
Meta's ads AI connectors go further. The hosted server can pull reports and also create ads, audiences, A/B tests and lift studies, with new ads paused until you turn them on.
HubSpot's remote MCP server reads CRM records, campaigns and email analytics, and can write records and pages. Its docs say every write shows a proposed-changes summary that needs your confirmation, and every action follows your existing user permissions.
PostHog runs a free hosted MCP server for product analytics, experiments and SQL. Its advanced setup shows a single header that limits the server to read-only tools.
The card below puts the five side by side. Read the right-hand column before you connect anything.
In our pull of US LinkedIn postings for the 30 days to October 16, 2026, 22% of 60 builder roles mentioned MCP. That is 55 GTM engineer postings and 5 of the new marketing engineer postings, duplicates removed.
The surrounding numbers explain why. APIs or webhooks came up in 78% of the same postings, and Claude in 32%.
MCP is the newest layer on top of APIs, so a team that already wires APIs together reaches for it next. Figma's posting for a Marketing Engineer, AI Deployment lists building integrations, "APIs, MCP Servers", for each operator on the team.
You do not need to build servers to get hired. You do need to know how to connect one safely, what it can touch, and how to check its answers.
In an interview, tell it as a short story: which server, which scope, which question, and how you checked the answer against the source. That one story shows more judgment than a list of tools you have connected.
Start with questions you already answer by hand every week. You know the right answer, so you can tell when the assistant is wrong.
The first is the Monday numbers. Two sources, last week against the week before, the three biggest changes, and the query behind each one. That is the raw material for the growth cockpit, the weekly memo that replaces the status meeting.
The second is the funnel check. One Google Analytics funnel report, split by source, pointing at the step with the biggest drop; the order for reading those steps is in reading ad data.
The third is the CRM truth check: leads by source, and how many became deals. Ad platforms count form fills, the CRM counts money, and the gap between them is a number neither tool shows you on its own.
Each prompt in the card names the source, the date range and the output. Vague questions get confident, unchecked answers.
What not to start with is just as clear. Anything that spends money or touches many records at once, such as budget changes, new campaigns or bulk CRM edits, waits until the ladder below says it can.
The specification is clear about safety, and honest about its limits. It says hosts must get explicit consent before invoking any tool, and the tools section says there should always be a human able to deny a tool call.
It also says tool labels such as "read-only" are hints, and clients should never make decisions based on hints from servers they do not trust. Then comes the line that matters most: MCP itself cannot enforce these security principles at the protocol level.
The spec also says apps should show which tools are switched on, mark each call as it happens, and ask for confirmation. If the app you use does none of that, pick another app before you connect an ad account.
So safety lives in the app you use and the server you pick, not in the protocol. That is the same idea as an agent harness: the rules around the model do the protecting.
Simon Willison, who coined the term prompt injection, names the dangerous mix in the lethal trifecta: private data, content an attacker can write, and a way to send data out. Give one assistant all three and a planted instruction can steal your data, and his example was a flaw in GitHub's own official MCP server.
Marketing setups hit all three easily. Your CRM is private data, a form field or a reply email is content a stranger wrote, and a tool that sends email or calls a webhook is the way out.
Keep at least one of the three out of any single session. Unapproved connections are their own risk, covered in shadow AI guardrails.
Every connection climbs the same four rungs, one at a time. We call it the Read-Only Ladder.
Rung one is read. The Google Analytics server asks for the read-only scope, the Google Ads server cannot write at all, and PostHog has a read-only switch; most teams should live here for the first month.
Rung two is draft. Writes are allowed, but they land somewhere harmless: Meta's server creates ads paused, and HubSpot shows a summary of proposed changes before it writes anything.
Rung three is capped. Meta lets an admin block whole actions, such as creating campaigns, or block any budget set above an amount you choose, for each ad account, and its server enforces those rules.
Rung four is live, with a named person approving each change. Climb a rung only after a clean log on the one below it.
The spec's own security guidance points the same way. It recommends starting with a small set of low-risk read scopes and asking for more only when a task needs them, because a token with broad scopes does broad damage if it is stolen.
Then MCP will show you the mess faster. It does not fix definitions; if Google Analytics and HubSpot disagree about what a lead is, the assistant will report both numbers with equal confidence.
That is still progress. Write down the three definitions that matter, a lead, a qualified lead and a customer, and give them to the assistant with every question; the longer version of that work is in the company brain article.
Some jobs are the wrong shape for MCP. Every result lands in the model's working memory, and Claude Code's MCP documentation warns when one tool result passes 10,000 tokens and caps it at 25,000 by default.
For a job that pulls the same large report every week, a script is cheaper. Anthropic's engineers showed one workflow dropping from 150,000 tokens to 2,000 when the model wrote code that called the MCP tools and kept the data out of its context.
And some data should not go to a cloud model at all. Patient, client or legal records belong on a local model; HubSpot already blocks call, email and conversation data from its MCP server when its Sensitive Data setting is on.
Pick one question you answer every Monday and one source that answers it. Google Analytics is the easiest start, because its official server is read-only by design.
Day one, connect it. Remote servers in Claude Code take one command, claude mcp add with an HTTP transport, a name and the server URL, and the docs list the options.
The Google Analytics server takes a little longer, because it runs locally. Its setup guide walks through installing pipx, turning on the Analytics Admin and Data APIs in a Google Cloud project, and signing in with the read-only scope.
Day two, ask the question five ways and save every answer with the report it ran. Day three, check each one against the Google Analytics screen and write down every mismatch.
Day four, add the definitions file and ask again. Day five, decide: if three answers in a row matched the screen, add a second source; if not, fix the question before you add anything.
Put the rules in a file, not in a chat message. We keep every agent's rules in skill files so each session starts from the same facts, and a line like "read-only on ad accounts" belongs there and in the server settings.
If you want to practise this on a real company's accounts, that is part of our marketing engineer training. If you want it built inside your own CRM, that is our CRM and RevOps work.
How to Write a Job Spec for an AI Agent [template]. Where the read-only rule, the approval line and the definitions file get written down. The spec is what makes an MCP setup repeatable.
The Marketing Engineering Stack [architecture]. Where MCP sits next to the warehouse, the scheduler and the API gateway, and why agents should not hit ad APIs directly at scale.
So the simple takeaway is this: let the assistant read your numbers before you let it change them.
Four weeks: audit a real company, build its growth repo, ship one working system and measure it. You leave with the repo and a case study.
See the training →Hiring instead? See how we build these systems for companies.