Google Ads MCP vs API for AI Agent Development in 2026
TL;DR
- The official Google Ads MCP server is strictly read-only. It exposes three tools (list_accessible_customers, search for GAQL reporting, and get_resource_metadata). Any write action, creating a campaign, adjusting a bid, pausing a campaign, lives only in the API.
- The MCP server is self-hosted, not a Google-hosted remote endpoint. You run it locally over stdio or deploy it yourself on Cloud Run. The Workspace MCP servers are Google-hosted; the Ads one is not.
- Both paths still require a Google Ads developer token plus OAuth credentials. MCP does not remove the developer-token gate, the access-level quota, or the per-user OAuth requirement.
- The API supports user OAuth with offline refresh tokens and service accounts (Workspace domain-wide delegation only). That is the only viable path for headless, scheduled, multi-account automation.
- Neither path stores, rotates, or revokes the per-user tokens for you. Scalekit's Agent Auth and Token Vault handle that for both paths, and its Google Ads connector adds the write tools the official MCP omits.
Your agent needs to work with Google Ads. It needs to pull campaign performance, answer questions about spend, and in many cases adjust budgets or pause campaigns on behalf of your users. Google now ships an official Google Ads MCP server and the Google Ads API has been production-grade for years.
Both paths work, but they are not interchangeable: one of them cannot write to your account at all, and that single constraint decides most of the architecture. Here is the decision framework.
What's Google Ads MCP Server
The Google Ads MCP server is Google's official bridge from an MCP client to the Google Ads API, shipped and maintained by the Google Ads API team in 2026. It is written in Python, speaks the stdio transport for local use, and authenticates with OAuth 2.0 or a service account. One detail defines it: this implementation is strictly read-only; it cannot modify bids, pause campaigns, or create new assets.
Where it runs
Unlike the Google Workspace MCP servers, there is no Google-hosted remote endpoint for Ads. You either run the server locally, or you self-host it. The official guide documents deploying it on Cloud Run and pointing your client at your own URL. That choice is yours to operate, scale, and secure.
What's The Google Ads API
The Google Ads API is the full programmatic surface for Google Ads: reporting through Google Ads Query Language (GAQL), record reads, and mutates for every write operation. It is gRPC-first with a REST interface, and it covers campaigns, ad groups, ads, budgets, bidding, conversions, audiences, keyword planning, and billing. Authentication combines an OAuth credential with a developer token issued from a Google Ads manager account.
Official docs:
What your agent can actually do with Google Ads MCP server and/or API?
The MCP server covers account discovery and reporting cleanly. Everything that changes the account is API-only.
Where the read-only ceiling sits
The gap here is not a missing-tool problem that ships next month. The server exposes exactly three tools by design: a search that executes GAQL requests to fetch resource metrics, budgets, and status; list_accessible_customers; and get_resource_metadata. Reporting and diagnostics live inside that surface. Every mutate operation lives outside it.
Why that decides the build
If your agent only reads, the MCP server is a clean fit. The moment your agent needs to act on the account, pacing budgets, adjusting bids, pausing underperformers, the MCP server cannot participate. That work goes through the API, and no configuration flag changes it.
The auth path each one puts you on
Both paths sit behind the same developer-token gate. What differs is the credential model around it.
MCP auth: OAuth or service account, still token-gated
- The MCP server authenticates with OAuth 2.0 or a service account, configured through environment variables that include GOOGLE_ADS_DEVELOPER_TOKEN and GOOGLE_PROJECT_ID. Out of the box, the local server runs with a single set of credentials.
- For per-user OAuth across many advertisers, you deploy the server yourself and wire up an OAuth proxy.
- The developer token, the GCP project, and the per-user consent are all still your responsibility.
API auth: user OAuth, service accounts, and the developer token
- There is no single API key; you assemble a developer token, an OAuth client ID and secret, and a refresh token.
- The Authorization Code flow with an offline refresh token lets an agent act as a specific user and keep operating headless after the session ends.
- Service accounts work too, but only for Google Ads accounts managed under a Google Workspace domain with domain-wide delegation.
- When a manager account reaches a child account, you also pass login-customer-id, or calls fail with a permission error.
The identity reality for multi-tenant agents
Both paths produce one OAuth credential per authorizing user, plus the shared developer token. For a B2B agent serving many advertisers, that is N user tokens to store and refresh, and a developer token whose access level caps your daily operations. The MCP path does not give you tenant isolation; the API path does not give it either. That is the infrastructure you build or buy.
What you own in production
With the self-hosted MCP server, Google maintains the tool definitions, but you own the deployment: the container, the Cloud Run service, the OAuth proxy for per-user identity, token storage, and refresh. With the API, you own the full stack: GAQL construction, mutates, pagination, retries, the token lifecycle, and version pinning.
API limits as a hard constraint
Access is metered per developer token by access level. Explorer Access allows up to 2,880 operations per day against production accounts; Basic Access allows up to 15,000 operations per day; Standard Access allows an unlimited number of operations for most services.
Rate limits apply on top of these, regardless of access level. An agent that issues several sequential calls per user action burns a daily budget faster than a traditional integration. Monitor usage from day one; both paths count against the same quota.
When to use the Google Ads MCP server
- Your agent is read-only by design: reporting, diagnostics, and performance questions inside an interactive assistant where a user is present for OAuth
- You want zero glue code for GAQL reporting and account discovery
- You can self-host comfortably and operate a single-tenant or low-tenant footprint
- You accept that any write action is out of scope and handled elsewhere
When to use the Google Ads API
- Your agent must write: create or pause campaigns, adjust bids or budgets, build ad groups, upload conversions
- You run headless or scheduled automation with a stored refresh token or a Workspace service account
- You operate across many advertiser accounts and need per-account credential isolation and revocation
- You need Keyword Planning, Customer Match, batch processing, or SearchStream at volume
- You need explicit API versioning for a deterministic pipeline
The credential problem that exists on both paths
Both paths hand you a token per user
Whether the agent reaches Google Ads through the read-only MCP server or the API, every user who authorizes it produces an OAuth credential. Fifty advertisers means fifty refresh tokens, each with its own lifecycle. The token type is similar across paths; the management burden is identical.
The developer token neither path manages
Layered on top is the developer token. It is a shared, long-lived secret tied to your manager account and your access level. Neither the MCP server nor the API stores it securely, rotates it, or revokes it for you. Leak it or lose track of which deployment holds it, and you have an org-wide exposure, not a per-user one.
Where Scalekit's Agent Auth fits
Scalekit's Agent Auth resolves the per-user Google Ads credential on every tool call, so actions and audit entries stay tied to the user who authorized them, not a shared bot account. The same auth layer works whether you front the official read-only MCP, self-host your own server, or call the API directly. The path decision does not change what you need at the credential layer.
Token Vault: credentials out of the agent runtime
Scalekit's Token Vault stores every credential encrypted with AES-256, isolated per tenant, and refreshed automatically before expiry. Tokens never appear in prompts, logs, or LLM context; the agent receives an opaque reference and the result of a call, never the secret itself. Revocation is a single dashboard action that invalidates the connection on the next tool call.
Using Scalekit to connect a Google Ads agent
The connector and its tools
Scalekit ships a managed Google Ads connector under the connection name googleads. It goes past the read-only ceiling: alongside reads it exposes write actions, which the official MCP server does not. Verified tools include googleads_campaigns_list (list campaigns with status and budget filters), googleads_campaign_get (retrieve a single campaign with budget, bidding, and schedule details), and googleads_ad_groups_list (list ad groups within a campaign), plus performance-metric retrieval, keyword listing, and daily budget updates. The authoritative, current list lives in the connector docs.
Scoped tool calling with LangChain
The agent should not receive a flat catalog of every Google Ads tool. list_scoped_tools returns only the tools the current user's connected account is authorized to call, already formatted for the model. You then bind those tools into the agent and let it run; execute_tool runs each call under the resolved user identity. The connectionNames value must match the connection name configured in your Scalekit dashboard exactly; a mismatch is the most common integration error.
Why scoping matters for accuracy and cost
A model picks tools from whatever is in context. Hand it a full catalog and tool selection degrades while token overhead climbs before the agent does any work. Scoping the surface to the handful of tools a user is authorized to call reduces both failure modes. The fix is not better prompting; it is surface reduction.
Virtual MCP Server for a scoped, per-user endpoint
If you prefer an MCP endpoint over direct SDK calls, Scalekit's Virtual MCP Server gives every agent role a scoped, user-specific MCP URL with no server to deploy, host, or maintain. You configure once in the dashboard which connection and which tools the role can see; Scalekit generates a server you point your client at. The endpoint is static and looks like https://yourcompany.scalekit.com/mcp/v3/servers/<server-id>.
Before each run, a short-lived session token is minted scoped to that user's connected account, so one server definition serves all users without credential sharing. Setup details are in the vMCP configuration guide, the quickstart, and an end-to-end Claude managed agent example.
Agent auth logs and observability
For multi-tool, multi-tenant agents, attribution is the hard part. Scalekit logs every delegation: who authorized, which agent, which tool, which scope, and the result, with a 90-day audit trail that is SIEM-exportable.
A shared service account would collapse all of this into one identity; per-user connected accounts keep each action traceable to the human who triggered it.
That is what an enterprise security review asks for, and it is the same whether the agent reads through MCP or writes through the API.
When the tool you need is not there yet
Scalekit's Google Ads connector covers campaign, ad group, keyword, metric, and budget operations. If your agent needs a Google Ads action that is not yet exposed, request it in the Scalekit Slack community or talk to the team.
Which one to build against
If your agent only reads Google Ads, reporting, diagnostics, performance questions for a user who is present to authorize, the official MCP server is the fast path, and its read-only boundary is a feature for that use case. If your agent has to act, adjusting budgets, pausing campaigns, building ad groups, uploading conversions, or it runs headless across many advertiser accounts, build against the API. Most production ad agents end up needing both reads and writes, which means the API is doing the real work. Either way, the credential problem is the same, and that is what needs production-grade infrastructure.
Browse the Scalekit Google Ads connector and the connector docs.
