Marketing MCP servers — connecting Claude to GA4, HubSpot, and ad platforms

Marketing MCP servers are small programs that connect Claude to the data systems where your marketing actually lives (Google Analytics 4, HubSpot, Meta Ads, and so on) using a shared protocol that Anthropic introduced in late 2024 (Anthropic, Introducing the Model Context Protocol). Once they are wired up, Claude can read your GA4 traffic, your HubSpot pipeline, and your ad spend in the same conversation, and write you a marketing report that pulls from all three. This piece walks through how we set that up for ourselves, what broke, what is worth your time, and the working configurations you can fork.

Key takeaways

• MCP is a protocol, not a product. It defines how Claude (or any compliant client) talks to a server that exposes tools and data. You install the servers locally or connect to a hosted one; Claude calls them.
• All three of the marketing MCPs we cover are real and working today: an official Google Analytics MCP server, an official HubSpot MCP at mcp.hubspot.com, and several community Meta Ads servers that connect to the Marketing API.
• The implementation work is not the hard part. The hard parts are permission scoping, schema friction (Claude hallucinating field names it cannot see), and deciding what data Claude is allowed to write back rather than just read.
• We run a daily 8am marketing briefing that reads from all three MCPs and writes a one-page summary. The substance of this post is how that briefing is built and what we learned wiring it up.
• All three configurations and the briefing prompt are in our public skills repo; the link is in the takeaway section.

What MCP is, in plain English

The Model Context Protocol is a structured way for an AI assistant to call tools, read data, and ask questions of an external system. Think of it as the difference between giving Claude a copy of yesterday's GA4 export and giving Claude a phone number it can ring whenever it needs traffic data. With an MCP server in the loop, Claude requests the data live, the server fetches it from the underlying API, and the answer goes back into the conversation.

Webhooks, Zapier, Make. Those tools push data on a trigger or move it on a schedule. They are flow-control. MCP is the opposite. The AI decides what it needs, when it needs it, and asks. That changes the kind of work you can ask Claude to do. Instead of "summarise this attached CSV," it becomes "look at our GA4 traffic for last week, compare it to the four weeks before, and tell me where the drop came from." Claude works the question by calling the GA4 MCP server multiple times, narrowing in.

The protocol itself is open. Anthropic published the specification, the SDKs, and example servers. Other LLM platforms have since added support. By early 2026 the standard is broadly adopted across the major model providers. That matters because the MCP servers you set up today are not Claude-specific. The same GA4 MCP runs against any compliant client.

The architecture (above the fold)

Here is the shape of the setup we are about to build.

Claude is the client. The three MCP servers are independent processes. Some are local subprocesses launched by Claude Desktop. Others are hosted endpoints reached over HTTP. Each server speaks to its underlying platform API using whatever credentials you provided (a service-account JSON for GA4, OAuth tokens for HubSpot, a long-lived access token for Meta Ads). Claude does not see those credentials. It sees the tools each server advertises (query_runReport, crm_get_contact, ads_get_insights) and the parameters they take.

There is no shared state. Each MCP server is independent. Claude is the only thing that knows about all three, and it routes its tool calls accordingly.

Setting up the GA4 MCP server

GA4 is the most-requested setup, so we start here. Two paths: Google's own official server (recently published) or a community implementation. We have run both. The official server has the cleanest authentication story; the community ones tend to expose more tools and let you customise more easily.

Step 1 — enable the Analytics Data API

In Google Cloud Console, on the project you want to use:

1. Open the API library and enable Google Analytics Data API.
2. Create a service account under IAM & Admin → Service Accounts.
3. Generate a JSON key for the service account and save it somewhere your local machine can reach. We keep ours under ~/.config/mcp/ga4-service-account.json, locked to the user account.
4. Grant the service account Viewer on the specific GA4 property in the GA4 admin (not the Cloud project; the Analytics property). Open admin → Property Access Management, paste the service account email, role: Viewer.

The property-level grant is the step every guide skips. Without it, the API call returns 403 even though the service account is set up correctly.

Step 2 — install and configure the MCP server

For the official Google server, follow the developers.google.com setup guide. For the community option we use day to day, install with:

Then in Claude Desktop's claude_desktop_config.json:

Restart Claude Desktop. In the developer panel you should see the GA4 server connected and a list of exposed tools. The first time you ask Claude something about your traffic — for example, "what were our top ten landing pages by sessions last week" — it will call query_runReport with the right dateRanges and dimensions and return a result.

Step 3 — pre-load schema context

GA4 dimensions and metrics are notoriously easy to misremember. Left to its own devices, Claude will sometimes ask for pagePath when the field is pagePathPlusQueryString. The fix is to drop a one-page reference into your Claude project (or paste it at the start of a session) listing the fields you actually use. After that, the schema friction drops to almost zero. We keep ours under thirty entries — page path, source / medium, country, device category, event name, sessions, total users, conversions. Eighty percent of marketing questions only need those.

Adding HubSpot

HubSpot is the second MCP. It is also the one with the cleanest official path. In late 2025 HubSpot published an official MCP server at mcp.hubspot.com, plus a CRM connector for Claude described in their support documentation. The connector works without writing any code — you go to your Claude integrations page, enable HubSpot, and authenticate. For most teams that is enough.

If you want more control — custom field exposure, write actions, or running locally — set up the developer route:

1. Go to the HubSpot Developer Platform and create a user-level app. The MCP server requires the new platform; legacy private apps will not authenticate against mcp.hubspot.com.
2. Add read scopes for the CRM objects you actually need. We always start with crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read, and crm.lists.read. Add write scopes only if you have a specific use case for Claude updating records.
3. Generate the OAuth credentials and add them to your Claude config:

Where HubSpot gets interesting is in the query patterns. Some questions work beautifully. For example, "list the deals in our Q2 pipeline that are in stage Demo Booked" comes back fast and clean. Other queries hit schema friction because HubSpot's data model is wide. Asking Claude to summarise activity across a contact's whole timeline can pull more events than the tool wants to return at once. The fix is to pre-narrow the question. Give Claude the contact ID and the date range, not the whole history.

We do not give Claude write scopes by default. The CRM is the system of record for sales handover, and a Claude session that quietly re-stages a deal is exactly the kind of bug we do not want chasing.

Adding Meta Ads

Meta is the strictest of the three on permissions, and the messiest setup. There is no official Meta MCP server today; instead there are several well-maintained community options. We use the Pipeboard implementation as our default. The repo is at github.com/pipeboard-co/meta-ads-mcp, with fallbacks documented in the repo.

The setup pattern is OAuth against your Meta business app, with a long-lived access token scoped to a specific ad account.

1. Create or use an existing Meta business app on developers.facebook.com. The app needs ads_read at minimum, and ads_management if you want Claude to be able to pause campaigns.
2. Generate an access token via the Graph API explorer, then exchange the short-lived token for a long-lived one. The community MCP repos document the exact oauth/access_token call.
3. Production access requires app review. For internal tooling (you, your agency, your marketing team) that is fine. For anything user-facing, plan two extra weeks for the review.

Add the server to your Claude config:

The behaviour to be careful about. Claude can ask for ad-creative-level data and the API will happily return image URLs and video URLs. Those URLs are signed and time-limited, but they are publicly addressable while they live. If you do not want creative assets in your conversation history (a not-unreasonable position for unreleased campaign work), tell Claude to summarise creative names and IDs without pulling the URLs. Or use a community MCP variant that strips them at the server.

By default we limit Claude to read on Meta. Letting an LLM pause a campaign is a feature we would build only with a human-in-the-loop confirmation step, and we have not yet had a use case that justified the work.

The morning briefing workflow

This is the actual use case. Three MCPs connected, Claude sitting on top. One prompt that runs every weekday at 8am and produces a marketing report.

The prompt looks roughly like this (real version is longer and brand-specific):

We trigger this from a small scheduling layer (in our case, a scheduled task in our internal business OS) rather than relying on Claude to schedule itself. That keeps the trigger source visible and makes the run easy to retry if the GA4 API is having a bad morning.

A real briefing (anonymised, but otherwise as it ran for a B2B SaaS client) looks like this:

The point is not the briefing format. You can rewrite it for whatever you actually care about. The point is that without MCP, this report needs three separate dashboards, three sets of credentials, and a person to coordinate them. With MCP, it runs as one prompt against three servers and lands in your inbox before the kettle boils.

Security considerations

Worth a non-negotiable section. MCP servers touching marketing data are a real security surface. They hold credentials that can read your traffic, your CRM, and your ad spend. A compromised MCP host is a compromised marketing stack.

The practices we follow:

Token scoping. Read scopes only, by default, on every server. Write scopes are added per use case after a deliberate decision. The HubSpot and Meta tokens we use day to day cannot modify anything.

Access revocation. Service-account JSON keys, OAuth credentials, and long-lived access tokens all live under ~/.config/mcp/, with chmod 600 and one revocation path each. We keep a short text file in the same directory listing every credential and the revocation URL. If a laptop is lost, every credential gets revoked from that list within ten minutes.

Rotation. GA4 service-account keys rotate every 90 days. HubSpot OAuth refresh tokens are bound to a Developer Platform app we own; if anything looks off, the app gets removed and recreated. Meta long-lived tokens get refreshed every 60 days as a calendar item.

What not to do. Do not put production credentials in a project file checked into git, even a private one. Do not run an MCP server you have not read the source of. Do not give a community MCP write scopes on day one — start with read, add write only after you trust the implementation. And do not connect Claude to a customer-data MCP from a personal account. Use a dedicated tooling identity per workspace.

The threat model is closer to "small Mac developer machine" than "production infra." Treat your local MCP setup with the same care you would treat the credentials in any other dev environment: locked down user account, encrypted disk, no shared logins.

Privacy and compliance. Connecting Claude to HubSpot or GA4 means an AI assistant can read personal data about your contacts, prospects, and visitors. Under GDPR (and equivalent regimes in California, the UK, and elsewhere) that processing has to fit your existing lawful basis and the data-handling commitments you have already published. Three concrete things to check before going live: that your privacy policy reflects AI-assisted analysis as a processor or sub-processor where relevant; that your DPA with HubSpot and Google still covers the new flow; and that any deletion or right-to-be-forgotten request you process in HubSpot is not contradicted by data sitting in Claude conversation history. In practice we keep Claude conversations involving customer data short-lived and never paste raw PII into a shared workspace.

What broke during setup

Honest list. Every one of these cost us time we will not get back.

Service-account property grant missed. First GA4 MCP setup failed silently with 403s for the first hour. The Cloud-level IAM grant was correct. The GA4-property-level grant in Property Access Management was not. The error message did not say which it was.

Hallucinated GA4 field names. Without a schema reference loaded, Claude asked the API for pagePath (which works in some surfaces) when the Analytics Data API expects pagePathPlusQueryString. The API returned an INVALID_ARGUMENT and Claude apologised and tried a different combination. With a schema crib loaded into the system prompt, the issue stopped.

HubSpot rate limits on full timeline pulls. "Summarise everything for this contact" can pull hundreds of timeline events and trip the rate limiter on a free or starter HubSpot tier. The fix is the pre-narrowing pattern above — give Claude a date range, not the whole history.

Meta token expiry. Long-lived Meta tokens are 60 days, not forever. Ours expired silently one Friday and Monday's briefing came back with "Meta Ads MCP returned: invalid OAuth access token." It was thirty seconds to refresh and a calendar reminder to do it next time.

Query timeouts on slow GA4 queries. Some GA4 reports (especially funnel-style queries with many dimensions) take twenty to thirty seconds to return. The default MCP timeout in Claude Desktop is shorter than that. The fix was either narrowing the query or raising the timeout in the server config.

Edge case: campaign with zero spend. The Meta MCP returned an empty array for a campaign that had paused at midnight, and Claude treated the absence of data as a normal answer rather than flagging it. Now the briefing prompt explicitly asks for a flag whenever a previously-active campaign returns zero impressions.

None of these are deal breakers. All of them are the kind of thing that turn up in week one and get sanded down.

Cost at production scale

We get this question a lot, and the honest answer is that the per-call MCP overhead is small but the token cost compounds across a high-frequency workflow. Take the daily briefing as the worked example. The prompt itself is ~200 tokens. Each MCP tool call adds the tool's request and response payload to the conversation — for GA4 it is typically 500-2,000 tokens of structured data per query, depending on dimensions. Over the four to seven tool calls a typical briefing makes, the input context grows to roughly 8,000-15,000 tokens. The output report is another 400-800.

Anthropic's published API pricing (check current rates at the time you cost this; pricing changes) is in the order of single-digit dollars per million input tokens for the mid-tier models and higher for the top tier. At those rates, a single briefing costs cents, not pounds. A daily briefing across a calendar year sits comfortably inside a Claude Max subscription (which is what we use; see our take on when Claude Max pays for itself).

The variable that actually matters is how often you run it. Once a day is cheap. Once an hour, in our experience, is where the question of token cost vs human attention budget starts to flip. At hourly cadence the briefing is competing with itself and you stop reading them.

Get the configurations

The three MCP server configurations covered above (GA4, HubSpot, Meta Ads) are in our public skills repo at github.com/robotic-pixels/marketing-skills under skills/claude-mcp/. The morning briefing prompt is in the same repo. Fork it, edit the brand-specific bits, drop it into your Claude config, and you have the same setup we use, minus the credentials.

If you want the bigger context — how MCP fits into the broader Claude-for-marketing toolchain, including building brand-aligned Claude Skills so Claude does not produce generic templates, or the rank tracker we built on Claude Code and DataForSEO, the Claude for Marketing pillar hub is the entry point.

For attribution-specific work, the GA4 MCP is the natural connection into our attribution coverage, where most of the same data shows up,, far less click-through to assemble.

Frequently asked questions

Do I need Claude Max to use marketing MCP servers? No. Claude Pro works with MCP servers in Claude Desktop. Max gives you higher usage limits, which matters if you run a daily briefing or use Claude for live analysis throughout the day. For a once-a-week briefing, Pro is enough.

Can Claude write back to HubSpot or Meta Ads? Yes, if you grant write scopes. We do not, by default. Read-only is the safer setup until a specific use case justifies write. When you do enable write, scope it tightly. For example, allow updating contact custom fields, but not deal stages.

What happens if the MCP server is down? Claude reports the tool error and continues the conversation without the data. The briefing run will note the missing data and produce a partial report. We treat partial reports as an alert; it is rare enough that we investigate every one.

Is there a hosted alternative to running these locally? Yes for HubSpot. The official MCP at mcp.hubspot.com is hosted. Yes for Meta Ads via several community providers (Pipeboard offers a hosted endpoint). GA4 currently is local-first. The official Google server runs as a local subprocess, although hosted variants exist.

How does this compare to a Zapier or Make-based integration? Zapier and Make are flow-control. They trigger on events and push data on schedules. MCP is request-driven. Claude decides when to ask for data. They solve different problems; you can run both. We use scheduled flows for things that always need to happen, and MCP for analysis Claude is doing on demand.

Takeaway

MCP is a young protocol and the marketing-specific MCP ecosystem is still small enough that getting in early is realistic. The category is not Bermuda Triangle. The pattern is the same on every server: enable the platform's API, scope a credential, point Claude at it, and start writing prompts that span data sources. The morning briefing is the cheapest first use case we know of, and the one we still run every weekday.

If you want to see the actual code, the configurations, and the briefing prompt as we run them, the repo is here. If you want help wiring this up for your own marketing stack, that is what we do — we build AI-first marketing systems and we are always happy to talk about whether one would help. Get in touch.

Built with Claude

This post was produced using Claude as a research, drafting, and editing partner.

• Models: Claude Opus 4.6 for drafting and structural editing; Claude Sonnet 4.6 for fact-checking and the humanise pass.
• Workflow: brief → claim-evidence binding (DataForSEO + WebSearch verification of the three MCPs) → first draft → humanise pass → hard-rules validation → final review.
• Word count: approximately 2,950 words.
• Human review: Alexander (final).

For more on how RP produces content with Claude at production scale, see the Claude for Marketing pillar hub.