Google released version 0.0.6 of its open-source Google Ads MCP server on November 2, 2026, and with it the first tools in the project's public history that can change a Google Ads account. The release adds four write tools that create assets, upload videos to YouTube and manage labels, each gated behind a two-step dry run and checksum. Those tools are switched on by default. No announcement accompanied the release, and Google's developer integration guide, last updated on October 30, still describes the server as strictly read-only.

In Short

Google's official bridge between AI assistants and Google Ads, which until now could only read account data, can now create assets, upload videos and manage labels after a quiet update on November 2. The change matters to agencies and in-house teams that approved the tool on the basis of Google's "read-only" description, because the new write tools are on by default and the documentation has not caught up. Campaigns, budgets, bids and keywords remain out of reach, but anyone installing the server the way Google's guide describes now gets a version that can write to the account unless the new tools are switched off in a configuration file.

What changed on November 2

The release appeared on GitHub as v0.0.6, tagged at commit 7452a9d, with a two-line changelog. According to the releases page, the substantive change is pull request #139, titled "Implement asset and label management with propose-and-confirm flow," followed by #142, which bumped the version number. Both are credited to the GitHub user Raibaz, who appears as a contributor on every release since v0.0.3. The Python package went up on PyPI the same day, at 15:48 UTC on November 2, according to the PyPI release history. The release ships a 54.8 KB wheel and a 46.7 KB source archive alongside a SHA256SUMS file.

The server is an implementation of the Model Context Protocol, the open standard that lets AI applications discover and call external tools. Google introduced it on October 7, 2025. "This initial release is read-only, meaning it can be used for reporting and diagnostics but will not make changes to your account," Dean Lukies of the Google Ads API team wrote in the announcement on the Google Ads Developer Blog. PPC Land covered that launch on October 11, 2025, when the server exposed two tools: search and list_accessible_customers.

Version 0.0.6 brings the tool count to seven. The three read tools are unchanged: search runs Google Ads Query Language (GAQL) requests, list_accessible_customers returns the account IDs the authenticated user can reach, and get_resource_metadata describes the fields available on a resource such as a campaign. The server also exposes four reference resources: the Google Ads API discovery document, metrics, segments and the latest API release notes.

The four new tools, according to the repository README, are:

  • create_asset, which creates text, image, YouTube video, sitelink, callout and structured snippet assets, plus "other asset types via extra_params."
  • upload_video_asset, which uploads a local video file to YouTube through the Google Ads API "using a background task so it can be referenced by video assets."
  • manage_labels, which creates, updates and removes account labels.
  • manage_label_associations, which attaches labels to, or removes them from, customer accounts, campaigns, ad groups and ad group criteria such as keywords.

Inside the asset and video tools

The published source code for version 0.0.6 adds detail the README leaves out. Image assets accept PNG, JPEG and GIF files and are capped at 20 MB, whether the image arrives as a local file path or as base64-encoded data. Local file paths only work when the server runs on the same machine as the AI client. Remote deployments have to send the image inline. Sitelinks require link text and at least one final URL, with two optional description lines, while a callout needs only its text. Tracking templates, final URL suffixes and custom URL parameters can be set on any asset.

Video uploads are more restricted. The tool accepts 11 file formats, from MP4 and MOV to WebM and WMV, and runs only in local mode. Privacy defaults to unlisted, and according to the tool's description, public uploads are limited to brand channels. If no YouTube channel ID is supplied, the video goes to a Google-managed YouTube channel linked to the ads account. Because uploads can be large, the tool runs as a background task, using the tasks mechanism that the Model Context Protocol moved into an extension in its July 2026 specification.

How propose and confirm works

Every write runs twice. On the first call, a parameter called validate_only defaults to true. The server validates the request, and for assets and labels it sends the operation to the Google Ads API as a dry run that checks the change without executing it. It then returns a list of human-readable "change_items" and a checksum. Only a second call, with validate_only set to false, the exact same parameters and that checksum, commits the change.

According to the README, the checksum is "bound to the customer ID and parameters," and the second step "requires passing the exact same parameters and customer_id together with the checksum returned in step 1 after explicit user approval. Any missing or mismatched checksum is rejected before mutating the account."

That design guarantees one thing: what gets written matches what was validated. It does not guarantee that a person looked at it. Thomas Wismer, a Swiss digital marketing consultant who tested the release today, made the point directly in a blog post on his agency's site. "Whether a human approved it in between, the server cannot check: waiting for the user's OK is an instruction in the tool description," he wrote. "If you want a hard stop, add your own."

PPC Land's reading of the published code supports that and goes slightly further. The checksum is a SHA-256 digest computed from the customer ID and the operation parameters, with no secret key and no expiry. The server keeps no record of proposals between calls: on the confirming call it recomputes the digest from the parameters it receives and compares the two. The checksum therefore proves the parameters did not change. It does not prove that a dry run took place, or that anyone approved one. The message returned after validation tells the AI model to show the proposed changes to the user and wait for explicit confirmation, but that is an instruction to the model, not a control the server enforces.

The video tool is a partial exception to the README's description of a Google Ads API dry run "where supported." For uploads, the first call performs only local checks, such as file format and whether the file exists, and computes the checksum. No request reaches Google until the confirming call. To stop a file being swapped between the two calls, the checksum includes the file's size and modification time.

The tools also carry MCP annotations, the hints that AI clients can use when deciding how to present a tool call. Both label tools are marked as potentially destructive. The asset and video tools are marked as write tools that are not destructive.

Switched on by default

Which tools the server exposes is controlled by a file called tools_config.yaml. In version 0.0.5, the bundled default enabled three namespaces: customers, search and metadata. In version 0.0.6, two more lines appear: labels: true and assets: true.

"A default tools_config.yaml with all tools enabled is bundled with the package, so the server works out of the box with no extra setup," the README states. "For strictly read-only deployments, set labels: false and assets: false in your tools_config.yaml." The server looks for a configuration in a fixed order: a path set in the GOOGLE_ADS_MCP_TOOLS_CONFIG environment variable, then a file in the current working directory, then the bundled default. If an explicitly named file is missing or any resolved file is invalid, the server refuses to start.

The installation route matters here. Google's integration guide configures the server with pipx run --spec git+https://github.com/googleads/google-ads-mcp.git, which runs whatever is on the repository's main branch rather than a fixed release. Wismer flagged this in his post: the command "always pulls the latest code from the main branch," and pinning a release tag is the way to control when new write tools arrive. The README does document an alternative that runs a specific version published on PyPI.

The credential was never read-only

A detail in the source code explains why the change required no new permissions from users. The server authenticates with the https://www.googleapis.com/auth/adwords scope, the single OAuth scope Google publishes for the Google Ads API. A code comment in version 0.0.5 acknowledged that Google Ads does not offer a separate read-only scope and that read-only behaviour came from the limited set of tools the server exposed. In version 0.0.6, the same comment now says read and write capabilities are governed by tools_config.yaml and the propose-and-confirm workflow.

In other words, the OAuth grant that users gave the server in October 2025 already permitted writes at the API level. What kept the server read-only was its own code. That code has now changed.

The documentation says otherwise

Google's guide, titled "Google Ads MCP server: Developer integration guide" and last updated on October 30, 2026, lists the server's key specifications as "Mode: Read-only (current release)." Its section on core capabilities describes only the three read tools and ends with a note: "This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets."

For anyone running version 0.0.6, the first and last of those claims no longer hold: the server is not read-only, and it can create assets. Bids and campaign status remain out of reach. The guide also describes the server as giving an AI client "read-only access to live account data" when it introduces Google's companion tools.

"Version 0.0.6 went up on GitHub on November 2. No blog post, no announcement, and Google's own docs still call the server read-only," Wismer wrote in a LinkedIn post today. "I only noticed because I went through the release history." His blog post, dated today, says that as of November 9 the last post about the MCP server on the Google Ads Developer Blog is the October 2025 launch, and that "the only primary source is the release on GitHub." PPC Land found no Google announcement of version 0.0.6.

For writes beyond the MCP server, the guide points elsewhere. It directs developers who need "to generate client library code for mutate operations" to the Google Ads API Developer Assistant, a plugin for Google Antigravity and Claude Code, and recommends Google's Ads API agent skills, which include google-ads-api-mcp-setup, google-ads-api-account-diagnostics and google-ads-api-quickstart.

Tool names that changed

Wismer's post identifies a second issue for existing users: tool names now carry a namespace prefix. Under the default configuration, search becomes search_search, list_accessible_customers becomes customers_list_accessible_customers and get_resource_metadata becomes metadata_get_resource_metadata. The new tools follow the same pattern, so create_asset is exposed as assets_create_asset. "Permission lists and allowed-tools in skills that use the old names silently lose access," he wrote. "Two of my skills did."

The renaming is not new in version 0.0.6, however. PyPI packages show the namespacing first shipped in version 0.0.2 on September 9, 2026, alongside tools_config.yaml and the get_resource_metadata tool. Wismer's own timeline dates the configuration system to June 3, 2026 on GitHub. Anyone moving from the original October 2025 package, version 0.0.1, or from older code on the main branch, sees the new names for the first time. Anyone who already ran a version from September onward does not. Google's integration guide, meanwhile, still lists the tools by their unprefixed names.

A test in a live account

Wismer, who founded Wismer Marketing and has advised Swiss small and medium-sized businesses on search and paid advertising since 2019, ran the new tools today in a client account, with the client's permission, through Claude Code. According to his blog post, he ran a dry run for a label and a callout asset first. Both validated and returned planned changes and a checksum without writing anything. He then committed the label, read it back with a GAQL query and found it present with status ENABLED and the correct description. A second propose-and-confirm cycle removed it, and a further query showed status REMOVED. The callout was never committed.

"Created a test label, read it back, removed it again. Works," he summarised on LinkedIn.

Later the same day, he created a test sitelink the same way. It appeared in the account's asset library immediately, but was not attached to any campaign. Wismer also described a safeguard of his own: a Claude Code hook that asks for his approval before any call with validate_only set to false.

What it still cannot do

The limits are significant for anyone hoping to hand campaign management to an agent. According to Wismer's post, and consistent with the tool list in the package, version 0.0.6 cannot:

  • create or edit campaigns, ad groups or ads;
  • change budgets, bids, bidding strategies or status, such as pausing or enabling;
  • add keywords or negative keywords;
  • attach a new asset to a campaign or ad group.

The last limit shapes how useful the asset tool is in practice. Labels can be attached to campaigns, ad groups and keywords, but assets cannot. "Assets only land in the library; I found no tool for the link in v0.0.6," Wismer wrote. A sitelink created by an agent therefore does nothing until a person, or another tool, links it to a campaign.

Wismer also noted that a community pull request with tools for campaign status, budgets and negative keywords, #137, was closed by its author two minutes after it was opened, with the note "opened by mistake." For budgets, target CPA and status changes, he uses his own script on the Google Ads API with a dry run, explicit confirmation, a read-back and a change log. "Third-party MCP servers cover more of the API, but they hold a token with access to every account under your manager account," he wrote.

Thirteen months of releases

The release history shows how slowly the project moved after its launch, then how quickly it picked up. According to PyPI, version 0.0.1 was published on October 22, 2025, fifteen days after the blog announcement. The next version, 0.0.2, did not appear until September 9, 2026, nearly eleven months later. Four more followed within eight weeks.

According to the GitHub releases page:

  • v0.0.3, September 10, 2026, removed developer token validation (pull request #121).
  • v0.0.4, September 25, 2026, fixed "cross-client MCP Streamable HTTP interoperability" (#108) and added an optional login-customer-id parameter to every tool that can use it (#124), which matters for access through manager accounts.
  • v0.0.5, October 9, 2026, upgraded the FastMCP framework "for upstream fix of Oauth access tokens being logged" (#126), relaxed version constraints (#131) and bumped the version number (#132).
  • v0.0.6, November 2, 2026, added asset and label management.

The v0.0.5 entry deserves a second look. It indicates that, before that upgrade, the framework underneath the server could write OAuth access tokens to logs, an upstream issue fixed in FastMCP rather than in Google's code. The changelog gives no further detail.

Wismer's timeline, built from commit and release dates on GitHub, adds two points not visible on the releases page: label tools first appeared in the code on May 26, 2026, and propose-and-confirm was added to all write tools on October 19, 2026. None of that code reached a published package until November 2. PPC Land checked the PyPI source packages for versions 0.0.1 through 0.0.6: the asset, label and video tool files, and the propose-and-confirm module, first appear in 0.0.6.

The repository page lists 1.1k stars, 356 forks, 177 commits and 14 contributors, with four open issues and nine open pull requests. Python makes up 99.5% of the code.

Developer tokens, Cloud projects and remote hosting

The releases also track a wider change in how Google grants API access. Google's integration guide says developer tokens "were sunset on September 9, 2026, and are no longer required in the latest version of the Google Ads MCP server because API access levels are associated with the Google Cloud project." PPC Land reported the change as effective on September 10, 2026, when access levels began to follow the Cloud project used to generate OAuth credentials. Version 0.0.3, released on September 10, removed the server's developer token check.

The MCP server had already put pressure on that system. In February, Google acknowledged a backlog of developer token applications as it introduced an Explorer Access tier, with the MCP server and the Developer Assistant among the drivers of application volume. When PPC Land covered the launch in October 2025, a developer token was still one of the setup requirements.

Remote deployment is where the new write tools raise the stakes. Google's guide describes hosting the server on Google Cloud Run, deployed with the --allow-unauthenticated flag so that AI clients such as Claude and ChatGPT can connect using end-user OAuth. Authentication then happens inside the application. The guide includes a caution: "Never omit GOOGLE_ADS_MCP_OAUTH_CLIENT_ID and GOOGLE_ADS_MCP_OAUTH_CLIENT_SECRET when deploying with --allow-unauthenticated." Without those variables, it explains, the server "cannot enforce authentication and falls back to Application Default Credentials (ADC), exposing the container's service account credentials to unauthenticated callers."

That warning was written for a read-only server. With asset and label tools enabled by default, a misconfigured deployment of version 0.0.6 would expose account changes as well as account data, to whatever the service account can reach. The video upload and local image path options are disabled in remote mode, but base64 image assets, text assets, sitelinks, callouts and label changes are not.

The guide lists redirect URIs for claude.ai, chatgpt.com and Antigravity, and mentions an allowlisted pilot of a hosted endpoint, for which it gives no further detail. The README separately describes a local deployment using rootless Podman under WSL. It notes that the endpoint keeps stateful Streamable HTTP enabled to support both older MCP clients that use session IDs and newer clients built on the sessionless MCP specification of July 28, 2026.

Two further notes in the README apply to every deployment. "The MCP Server will expose your data to the Agent or LLM that you connect to it," the first reads. The second says an extra header is added to API calls "to help us collect usage data." The code appends the string google-ads-mcp and the package version to the x-goog-api-client header on each request.

Where Google sits against Amazon and Meta

Google's first write tools arrive well after rival ad platforms opened account changes to AI agents. Amazon Ads put its MCP server into closed beta on November 13, 2025, with tool groups covering account management, billing, campaign management and reporting. By February 2, 2026, its server had moved to open beta with tools for launching campaigns. Meta followed on April 29, 2026 with Meta Ads AI Connectors, which let agents such as Claude create and edit ads, ad sets and entire campaigns. In March, IAB Tech Lab's agent registry reached 10 entries, all of them MCP servers.

Set against those, Google's official server now writes to the outer edges of an account: the asset library and the label system. The decisions that move money, from budgets to bids to keywords, stay with the Google Ads interface, scripts, the API itself or third-party servers. Unofficial Google Ads MCP servers with broader write access fill part of that gap, and it is the gap Wismer cites for keeping his own budget script.

Why this matters for advertisers and agencies

For most marketers, the practical effect is narrow but real. Labels are the organising layer that many agencies use for reporting, automated rules and Google Ads scripts. An agent that can create, rename, remove and attach labels can change what those systems act on, even without touching a budget. Assets, by contrast, have no effect until they are linked, which limits what a mistaken asset creation can do.

The bigger issue is the gap between the code and the description. Agencies and in-house teams that approved Google's server for client accounts on the basis of the words "read-only," in the launch post or in the guide, may now be running something different. That happens without any change on their side if they launch it the way the guide describes. Permission lists keyed to old tool names can fail without warning. And the main safeguard, the instruction to wait for user approval, lives in a tool description that a large language model is asked to follow rather than in a control the server enforces.

None of that makes the release unusual for open-source software, where a GitHub changelog often is the announcement. The difference here is that Google introduced this server to advertisers, in its own words, as read-only. Will the documentation change before more teams notice? On November 9, a week after the release, it had not.

Timeline

Summary

Who: Google's Google Ads API team, which maintains the open-source Google Ads MCP server on GitHub, and advertisers, agencies and developers who connect AI assistants such as Claude, Gemini and ChatGPT to Google Ads accounts. Thomas Wismer, a Swiss digital marketing consultant, tested and documented the change.

What: Version 0.0.6 of the server adds four write tools, create_asset, upload_video_asset, manage_labels and manage_label_associations, each behind a two-step propose-and-confirm flow with a checksum. The tools are enabled by default. They cannot change campaigns, budgets, bids or keywords, or attach assets to campaigns. Google's integration guide still describes the server as strictly read-only.

When: The release went out on November 2, 2026, nearly 13 months after the read-only launch on October 7, 2025. Wismer tested it and published his findings on November 9, 2026.

Where: On GitHub in the googleads/google-ads-mcp repository and on PyPI, with no announcement on the Google Ads Developer Blog.

Why: It is the first time Google's official MCP server can change a Google Ads account. Teams that rely on the "read-only" description, or on old tool names in permission lists, are affected if they install the server the way Google's guide describes, and the main approval step depends on the AI model following instructions rather than on a control enforced by the server.