Google Ads MCP Servers Compared: Official, Hosted and Self-Hosted Options

Choose a hosted Google Ads MCP service when your priority is getting marketers connected quickly without owning infrastructure. Choose Google’s official server when you want a Google-maintained starting point and have the engineering capacity to configure, host, secure, and update it. Build or fork a custom self-hosted server only when control over tools, data handling, or internal workflows is valuable enough to justify ongoing engineering.

There is one important wrinkle: “official” and “self-hosted” are not opposites. Google’s official server is open-source software that you can run locally or deploy yourself. “Official” describes who maintains the code; “hosted” and “self-hosted” describe who operates it.

That distinction matters more than a long feature checklist. The real decision is who owns authentication, deployment, write safety, account routing, monitoring, upgrades, and support after the first successful query.

A server may be maintained by Google, by a commercial provider, by an open-source community, or by your own team. Maintainer reputation can influence release quality and support, but it does not tell you where the server runs or who stores credentials.

A self-operated server runs in your environment: a laptop, an internal host, or cloud infrastructure you control. A hosted server runs in the provider’s environment and is exposed as a remote MCP endpoint. Operation determines who handles uptime, OAuth callbacks, token storage, logging, patching, and incident response.

This is why Google’s official server belongs in two categories at once: it is official code and, unless you are in a limited hosted program, a self-operated deployment.

Use the matrix as a shortlist, not a substitute for testing the exact release and tool catalog you plan to connect. Google Ads permissions still apply in every model.

Google’s official server is the clearest baseline for teams that want a Google-maintained package and direct access to the underlying Google Ads API. It is written in Python and supports local stdio or remote Streamable HTTP deployments, including a Cloud Run path. Authentication can use OAuth 2.0 or a service account.

Google’s repository now documents dynamic OAuth through a Streamable HTTP deployment, plus file, Redis, Firestore, or memory-backed OAuth state. Those options are useful, but they are still operating decisions your team owns.

This is the publication-sensitive part of the comparison. Google’s current developer integration guide still labels the server “read-only” and lists account discovery, GAQL search, and resource metadata. But the official repository’s latest release, v0.0.6, was published on November 2, 2026 with asset and label management. The repository documents a propose-and-confirm workflow for those mutations and allows the write namespaces to be disabled.

The practical conclusion is not that one source is “right” and the other is “wrong.” It is that the deployed version and tools configuration are the source of truth. Pin the package version, inspect the exposed tools in your AI client, and test a non-destructive validation path before assuming a server is read-only or read/write.

Even in v0.0.6, write scope is narrow compared with full campaign management. The documented mutations cover assets, video upload, labels, and label associations – not arbitrary bid, budget, campaign, ad group, keyword, or conversion changes.

The official server accepts a login customer ID per tool call or as a default. It can also support dynamic OAuth when deployed as a remote service. That gives technical teams the building blocks for multi-user or multi-account access, but the operator still decides how profiles are named, tokens are isolated, tenants are separated, and users select the right hierarchy.

For most requests, the agent also needs a target customer ID. When an operator moves among many accounts, explicit customer IDs and login-customer-ID handling become part of prompt and workflow design.

Choose the official server when you want a Google-maintained base, primarily need reporting and GAQL access, can own the deployment, and are comfortable verifying release-specific mutations.

A custom self-hosted server gives you maximum control over the tool surface. You can expose only approved actions, encode internal naming rules, add validation, integrate ticketing or approval systems, and route requests through your own infrastructure.

The first working query is not the finish line. The long-term cost is maintaining a trustworthy operational system as Google Ads, MCP clients, and your own requirements change.

Choose a custom server when Google Ads automation is a product capability or durable internal platform – not a side project – and you have an owner for security, reliability, and release management.

A hosted service packages the server, OAuth flow, platform integration, and ongoing maintenance behind a remote MCP endpoint. The buyer connects an AI client, authorizes Google Ads, and uses the provider’s supported tools.

Hosted does not remove Google’s permission model. The connected Google identity and its effective role still determine which accounts and actions are available.

Choose a hosted service when time-to-value and marketer usability matter more than controlling every infrastructure layer, and when the provider’s defined tool catalog covers the workflows you actually need.

Ask for the live tool list, not a marketing label. Separate reporting, discovery, planning, validation, and mutation. “Read/write” can mean anything from creating one asset type to managing campaigns, budgets, ads, keywords, conversion actions, and bidding settings.

A safe workflow should make the account, object, current value, proposed value, and scope visible before a change is committed. After the write, it should read back the saved state. For bulk changes, ask how partial failures and rollback are handled.

Google Ads uses advertiser accounts and manager-account hierarchies. The login customer ID selects the hierarchy used to evaluate access. A server that works for one direct account may still be awkward for an agency switching among several MCCs or Google identities.

Google Ads does not use a separate OAuth scope for read-only versus read/write. The API follows the user’s Google Ads role. Read-only access can inspect reporting and account information; Standard or Admin access is needed for many changes, while Admin is required for account-user and certain linking tasks.

For self-hosting, ask who patches dependencies, rotates secrets, monitors failures, stores OAuth state, and handles new API versions. For a hosted provider, ask the same questions as vendor due diligence rather than assuming they disappear.

Compare subscription or usage fees with engineering time, infrastructure, monitoring, security review, support, and upgrade work. “Free open source” can be economical for a capable platform team and expensive for a marketing team that has to borrow engineers for every incident.

Then run a small proof of value with one account: list accessible customers, pull a seven-day campaign report, inspect permissions, and test the safest available validation or proposal path. Do not begin with a bulk write.

HireOtto is the hosted option in this comparison. You connect its remote Google Ads MCP endpoint to an MCP-capable AI client, authorize Google Ads through OAuth, select the accounts you want available, and work from the conversation. You do not need to build a Google Cloud app, configure server credentials, or operate a local process.

For this workflow, HireOtto can discover authorized accounts, report and analyze performance, research keywords, inspect change history, run supported audits, and create or update supported Google Ads entities. Its current tools include campaign, ad group, ad, keyword, negative-keyword, budget, bidding, asset, conversion-action, Performance Max, and Demand Gen workflows. Availability still depends on the exact tool, plan, object state, Google Ads role, and platform validation.

Agency teams can connect multiple Google profiles on the Agency plan. HireOtto discovers direct accounts plus one level of child accounts beneath an accessible MCC. It does not automatically traverse a nested MCC beyond that level; to reach deeper accounts, connect another Google login with direct access to the inner manager account.

HireOtto is not an autonomous media buyer. The marketer still owns the objective and approval. For important changes, name the customer ID and affected entities, inspect the proposed values, approve the intended scope, and read the live state back after the tool runs. If the connected Google role cannot perform an action – or HireOtto does not expose that action – the server cannot bypass the limitation.

Check the Google Ads MCP tools reference, review authentication and manager-account access, and then connect Google Ads to your AI tool.

The public package is designed for you to run locally or deploy yourself. Google’s guide also refers to a limited hosted-endpoint pilot, but the normal public path is self-operated. Confirm current hosted availability before planning around it.

The answer depends on the release and configuration. Google’s developer guide still describes the current implementation as read-only, while the official v0.0.6 release adds asset and label mutations with propose-and-confirm safety. Verify the installed version and exposed tools.

No. Hosting location does not override Google Ads access. The connected identity’s role and the selected manager hierarchy still control effective permissions.

Yes, but account discovery and routing vary. Evaluate customer-ID selection, login-customer-ID handling, multiple OAuth identities, token isolation, and nested manager hierarchies – not just whether a demo can query two accounts.

Google’s current integration guide says developer tokens were sunset on September 9, 2026 and the latest server uses Google Cloud project access levels instead. Older tutorials and pinned versions may still describe the previous setup, so follow the documentation for the exact release you deploy.