google-meta-ads-ga4-mcp: One Remote MCP Server for Google Ads, Meta Ads and GA4
Google Ads MCP + Meta Ads MCP + GA4 in one server for Claude, ChatGPT, Cursor & n8n — 250+ tools, hosted remote MCP, OAuth login, no API keys. By Ryze AI.
At a glance
- What is it?
- Ryze AI's repository bundles Google Ads, Meta Ads and GA4 tools behind a single hosted MCP endpoint with OAuth login. The design removes local API key setup, but it also moves the credential boundary to a third party, and the repository itself ships no server code to inspect.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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 split across the three: 150+ for Google Ads, 80+ for Meta Ads, 20+ for GA4. 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 material shows product pages for google-ads-mcp and meta-ads-mcp, setup guides under docs/ for ChatGPT, Claude, Cursor, Windsurf and n8n, a Codex config at configs/codex_config.toml, an llms.txt index, and a banner asset. No server implementation, no tool schemas, no deployment manifests appear in the supplied material. 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, n8n, Codex CLI, Gemini CLI and Cline are listed as supported, with per-client guides under docs/ and a TOML config for Codex. 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. The README does not document token lifetimes, scope selection or a revocation path, so those are questions for 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. On Google Ads the README claims campaign management across Search, Display, Shopping, PMax, Demand Gen, Video and App; Keyword Planner integration with volume, CPC and competition data; portfolio bidding strategies and shared budgets; Responsive Search Ads and other creative formats; custom and remarketing audiences plus customer match; performance metrics down to keyword and ad level with search terms and ROAS calculations; extensions including sitelinks, callouts, calls, images, prices, promotions, structured snippets and lead forms; experiments; negative keyword sets; labels; and conversion tracking with conversion uploads and value rules. On Meta Ads it lists campaign CRUD with objective support, ad set budget and placement controls, creative management with image and video upload plus carousel and collection formats, custom and lookalike audiences, lead forms and lead retrieval, product catalogs and feeds, performance insights with breakdowns, page posts and boosted posts, and business management for users, pages, Instagram accounts and pixels. On GA4 it lists standard, pivot and realtime reports, audience and channel group listing, and property configuration covering data streams, enhanced measurement and data retention. The GA4 surface is the thinnest of the three, and the README gives no detail on how report dimensions and metrics are parameterised, which is where most GA4 tooling becomes awkward.
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 two minutes. 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 full read and write across all platforms and lists destructive operations such as deleting campaigns and updating budgets. An assistant with that tool set and an ambiguous prompt is a real failure mode, and the supplied material does not describe confirmation steps, dry-run modes, or per-tool permission scoping. 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, setup guides, the llms.txt index and the Codex TOML config. It does not license the hosted connector, and nothing in the supplied material describes the terms under which the service is provided or what happens to data it processes. 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 and no changelog, 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 the README itself flags Google Ads API v20 in a badge and those 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.
Community notes