What MCP actually is
MCP — the Model Context Protocol — is a standard way for an AI assistant to call tools that live outside itself. The assistant does not gain new abilities by being told about your data; it gains them by being handed a set of callable functions and the permission to call them. An MCP server is the thing that exposes those functions.
That is the whole idea. Everything interesting is in what the server chooses to expose and what it refuses to.
Why Google Ads needs a server, not better prompting
People spend a lot of effort trying to prompt their way to good Google Ads answers. It does not work past a point, and the reason is structural: the model cannot see the account. No prompt makes yesterday's spend appear.
A Google Ads MCP server closes that gap. It authenticates against the Google Ads API on your behalf, translates "which campaigns are pacing behind" into the query that answers it, and hands the result back as data the assistant can reason over. The assistant is doing the reasoning; the server is doing the reaching.
The second reason is writes. Reading is only half of paid search. Adding negatives, adjusting a budget, building a campaign — those are API calls, and calls need a caller with credentials, a permission model, and an audit trail. That is a server's job, not a chat's.
What tools a Google Ads MCP server exposes
The shape is fairly consistent across implementations. Roughly:
Account discovery — list the ad accounts the connected login can reach, and which one is currently selected. This is the first call any working setup makes, and it is the standard way to test that a connection is live.
Campaign and ad group reads — campaigns with status, budget, bidding strategy, and performance over a date range; ad groups and keywords beneath them.
Search term reads — the query-level report, which is where most wasted spend hides and the single most valuable thing to be able to ask for in plain language.
Metric reads — spend, impressions, clicks, conversions, conversion value, over arbitrary windows and with comparisons.
Budget and bid writes — change a campaign's daily budget or its bidding configuration.
Negative keyword writes — add negatives at ad group, campaign, or list level.
Campaign creation — assemble a campaign with ad groups, keywords, and responsive search ads. On a well-behaved server this always lands paused.
If a server exposes creation but not paused creation, that is a design decision you should refuse.
Read and write are separate scopes on purpose
A connector asks for OAuth scopes, and the granularity matters. Read-only access lets an assistant report, diagnose, and audit — genuinely useful, and it cannot break anything. Write access adds the ability to change the account.
Keeping them separate has a practical payoff: you can start read-only, learn what the assistant is good at on your own data, and grant write access when you have decided you trust the workflow. It also means an accidental prompt cannot cause a change that was never authorised in the first place.
On LoomaScale's server the two are distinct scopes (ads.read and ads.write), and a connector created without the write scope will read happily and refuse every change — which is a confusing failure until you know it is the scope, so it is worth checking first when edits get rejected.
Hosted or self-hosted
You have two options, and they trade off cleanly.
Self-hosted. You run the server, you hold the Google Ads API developer token, you manage the OAuth app, refresh tokens, quota, and errors. Full control, no third party in the path, and a real amount of maintenance. Getting a developer token approved for anything beyond test accounts is itself a process.
Hosted. Someone runs it, you authorise your account against it, and you get a URL to paste into your assistant. Faster by an order of magnitude, and the trade is that you have to evaluate the operator rather than the code.
Neither is the right answer universally. If you manage ad accounts for a living and have engineering capacity, self-hosting is defensible. If you want to be asking your account questions this afternoon, hosted is the honest choice. Google's own server, hosted operators and developer toolkits all sit in our roundup of seven Google Ads MCP servers, scored on exactly the read-versus-write line this article draws. The Meta connectors are a separate field with separate names, ranked here.
If you want to read one before deciding, ours is open source: google-ads-mcp is the server described above, MIT licensed, with the spend guardrails and the 43 tools documented in full.
Want to use one instead of building one? Connect Claude to Google Ads with LoomaScale, or ChatGPT. One click from the assistant's own directory, no code.
Five things to check before trusting a server
Whatever you connect, these are the questions worth asking. They are also the questions worth asking about us.
1. Does it gate anything that spends? Campaigns created paused, budget changes proposed rather than applied. If a server will silently push a live campaign, no other feature compensates.
2. How granular are the scopes? "Full access to your Google Ads" is not a permission model. Read and write should be separable, and you should be able to see which you granted.
3. What does it store? There is a big difference between a server that reads your account live on every request and one that copies your campaign data into its own database. Ask, and prefer the former.
4. What happens at the rate limit? The Google Ads API has quotas. A server that fails loudly and tells you to retry is better than one that silently returns partial data an assistant will then reason over as if it were complete.
5. Which assistants does it support? ChatGPT and Claude both speak MCP, but the way you add a server differs: both have a directory a listed server connects from in one click — LoomaScale is listed in both — while an unlisted server has to be added by hand: as a custom connector in Claude, in developer mode in ChatGPT.
Connecting one, concretely
For LoomaScale the server is at https://api.loomascale.com/mcp, and the process is the same shape for any hosted MCP server:
1. Create an account with the operator and connect your Google Ads through Google's own sign-in. This is the step that establishes which ad account the assistant may reach — the assistant never sees your Google password. 2. Add the server in your assistant. In Claude, LoomaScale connects from Claude's connector directory in one click plus a sign-in — see connect Claude to Google Ads. In ChatGPT, LoomaScale installs from the plugin directory in one click — see connect ChatGPT to Google Ads. 3. Authorise. The server shows its own consent screen and you approve the scopes. 4. Test with account discovery. "List all my Google Ads accounts, then show the campaigns in each one with their status and daily budget." A working connection answers with real account names; a broken one tells you which of the four steps failed.
What this is not
An MCP server does not make an assistant a media buyer. It removes the excuse that the assistant cannot see the data. Judgement, strategy, and accountability stay where they were. The server plus the model on top of it is what gets called a Google Ads AI agent, and that guide covers what the combination should and should not be trusted with.
What it does remove is the tax: the exports, the screenshots, the twenty minutes of clicking to apply a decision you made in ten seconds. For most accounts that tax is the majority of the work.
More detail on what the connection can and cannot do is in the documentation. If you would rather see one connected than read about it, Google Ads and ChatGPT, connected has the setup on video and a table of how an MCP server differs from a reporting connector.
