google-meta-ads-ga4-mcp: One Remote MCP Server for Google Ads, Meta Ads and GA4

Three Ad Platforms Behind One MCP Endpoint

The problem this repository addresses is fragmentation. A marketer or agency working across Google Ads, Meta Ads and Google Analytics 4 normally opens three dashboards, and if they want an AI assistant to touch that data, the README's own framing is that existing MCP servers cover one platform at a time, which means installing and configuring several tools. This project's answer is a single server that exposes the Google Ads API, the Meta Marketing API and the GA4 Data API as MCP tools. The README claims 250+ tools across the three. The intended audience is agencies and in-house marketing teams that already live in these platforms and want campaign creation, keyword research, creative upload, audience building and reporting driven from a chat client. The README positions write access as a differentiator against what it calls the official Google MCP, which it describes as read-only. That is the core pitch: one connection, three platforms, read and write.

What Actually Sits in the Repository

This is the part that needs to be stated plainly, because it changes how you evaluate everything else. The README documents a remote MCP server hosted at connector.get-ryze.ai, not a server you build and run from this repository. The repository shows product pages for google-ads-mcp, google-analytics-mcp and meta-ads-mcp, docs/ and configs/ folders, an assets/ folder, an llms.txt index, glama.json, server.json and a CHANGELOG.md. No server implementation, no tool schemas, no deployment manifests appear in the repository. The repository is MIT licensed, so whatever source it does contain is permissively licensed, but an MIT licence on documentation and configuration files does not grant you the hosted service. If you are evaluating this as an engineer who wants to read the handler code behind a tool that deletes a campaign, you cannot do that from what is described here. Treat the repository as the client-side documentation surface for a hosted product.

Connecting Claude, ChatGPT, Cursor and n8n

Setup is deliberately short. For Claude Code the README gives one command: claude mcp add ryze --transport http https://connector.get-ryze.ai/mcp. For claude.ai, Claude Desktop, ChatGPT and Cursor, the instruction is to open Settings, then Connectors, then Add custom connector, paste the same URL, and sign in with the Google or Facebook account that owns the ads. The README states there are no API keys, no developer token and nothing to install. Windsurf and n8n are also listed as supported. The one configuration value that matters is the endpoint URL itself; authentication is handled by OAuth against the ad platform account rather than by a token you paste into a config file. That is the mechanism: the MCP client speaks HTTP to the hosted connector, the connector holds the platform credentials, and the assistant sees tools rather than API keys. Token lifetimes, scope selection and a revocation path are questions to settle with the vendor before you connect a production account.

Tool Coverage Across Google Ads, Meta Ads and GA4

The breadth is the selling point and it is worth reading the list as a scope statement rather than a feature list. Across the platforms the README says you create campaigns, research keywords, upload creatives, build audiences and pull performance reports by chatting with your assistant. The Google Analytics MCP product page is described as covering GA4 reports, realtime data and AI-referral traffic from ChatGPT, Claude, Gemini and Perplexity.

Where the Hosted Model Becomes the Constraint

The trade-off is structural. A remote MCP server means your assistant's requests, and the ad account access behind them, pass through infrastructure operated by Ryze AI rather than running on your machine. The README presents this as a benefit: no API keys, no developer token, connect in 30 seconds. It is also the reason some teams cannot use it. If your organisation requires that ad platform credentials never leave your own environment, or that every code path that can pause a campaign be reviewable, a hosted connector is the wrong shape regardless of how many tools it exposes. The write scope compounds this. The README advertises read and write access, with writes such as budgets, bids and pausing going through an approval step. Even with that gate, an assistant with write tools and an ambiguous prompt is a real failure mode. The second constraint is dependency: because the server is not in the repository, your uptime and behaviour are tied to the vendor's endpoint, and the MIT licence gives you no remedy if the service changes or stops.

How This Differs From Single-Platform MCP Servers

The honest alternative is running separate MCP servers, one per platform, on your own machine. That is precisely the arrangement the README argues against, and the argument is fair on setup cost: three servers means three sets of credentials, three processes and three configuration blocks. But the difference is not just convenience, it is where the trust boundary sits. A self-hosted Google Ads MCP server holds your developer token and refresh token locally; you can read its source, pin a version, and see exactly which API calls a tool makes. The unified hosted approach trades that inspectability for a single URL and OAuth. Neither is strictly better. If you only use Google Ads, the multi-platform argument evaporates and a single-platform server you host is the simpler dependency. The unified server earns its place when you genuinely need cross-platform reporting, for example combining GA4 conversion data with Google Ads and Meta Ads spend in one assistant session, because that is the workflow that otherwise requires stitching three tools together. The README's audit walkthrough, which shows Claude pulling data across Google Ads and Meta Ads into one report, is the clearest illustration of the case where the bundle matters.

Licence, Maintenance and What You Are Actually Depending On

The repository is MIT licensed. That covers the files present in the repository: READMEs, the docs/ and configs/ folders, and the llms.txt index. It does not license the hosted connector. The README links to a pricing and signup page at get-ryze.ai and describes a free trial, so the commercial terms live there, not in the licence file. Maintenance cost on your side is close to zero if you stay on the hosted endpoint, since there is nothing to upgrade; the flip side is that you have no version pinning, because no releases are listed. If the vendor changes tool behaviour, your prompts and n8n workflows absorb that change without warning. The maintenance question worth asking before adoption is not how often the repository is updated but how the connector handles Google Ads API and Meta Marketing API version deprecations, since those API versions retire on a schedule set by Google, not by this project.

Editorial conclusion

Adopt this if your team already runs Google Ads, Meta Ads and GA4 and you want an assistant to read and write across all three without managing developer tokens or a local process; the single command 'claude mcp add ryze --transport http https://connector.get-ryze.ai/mcp' is the whole install. Do not adopt it if your policy forbids routing ad account access through an external OAuth broker, or if you need to audit or patch the server code, because the repository documents the connector rather than shipping it. Before connecting a live account, verify three things: whether the OAuth grant is read-only or includes write scope, which Google Ads and Meta Marketing API permissions the connector requests, and what the hosted service retains after a report is generated. If the repository still contains only READMEs, setup guides and config snippets at your review date, treat it as documentation for a hosted product, not as an open source server you can self-host.

Frequently asked questions

Official sources

1. irinabuht12-oss/google-meta-ads-ga4-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README