MCP users should not need to submit design documentation for Basic API access

[JasonBroderick]

Problem

To use this official Google Ads MCP server with real (non-test) accounts, users must apply for Basic API access via the Google Ads API Center. That application requires submitting a "Design Documentation" document describing your tool's architecture, API services called, UI mockups, business model, and data flow.

This process was designed for developers building custom third-party applications on top of the Google Ads API. It is a complete mismatch for end-users of an official Google-published MCP server.

As an end-user, I did not build the tool — I installed it from this repo. I don't have UI mockups because it's a CLI integration. I don't have an architecture diagram because the architecture is this repo's code. The only way to complete the application is to fabricate a design document describing software I didn't write, pretending I'm a third-party tool developer when I'm simply trying to use Google's own official MCP to read my own ad performance data.

This wastes time for both applicants and Google reviewers, and forces users through a process that has nothing to do with their actual use case.

Impact

• Users who install this MCP and attempt to query their own accounts are immediately blocked by the test-account restriction
• The README doesn't mention this blocker — it says "get a Developer Token" but doesn't explain that the default token only works with test accounts and that a separate application process is required
• The existing application pathway forces MCP users to misrepresent their use case to fit a form designed for custom tool developers
• This creates significant and unnecessary friction for what should be a straightforward setup

What should change

The process for obtaining production API access as an MCP end-user needs to be fundamentally different from the process for third-party tool developers. MCP users are not building tools — they are using an official Google tool to access their own data. The current pathway does not acknowledge this distinction.

Possible approaches (not exhaustive):

1. A streamlined application path for official MCP users that does not require design documentation, since the "design" is this repo and Google already knows what it does
2. A simplified verification step — e.g. confirming account ownership and read-only intent, rather than submitting fictional architecture documents
3. At minimum, document the current reality — the README should warn users that a fresh developer token starts at test-account access, link to the Basic access application, and provide guidance on how to navigate the design documentation requirement for this specific use case

Environment

• Google Ads MCP installed via pipx run --spec git+https://github.com/googleads/google-ads-mcp.git google-ads-mcp
• Connected to Claude Code (Anthropic CLI)
• Developer token at test-account access level
• Three accessible customer accounts, all returning: "The developer token is only approved for use with test accounts. To access non-test accounts, apply for Basic or Standard access."

[Raibaz]

Have you considered Explorer access?

The requirements and the procedure to obtain it are significantly easier than the ones to obtain Basic or Standard access.

I will also update the documentation to mention this, you're right that it should be clearer about it.

[JasonBroderick]

Have you considered Explorer access?

The requirements and the procedure to obtain it are significantly easier than the ones to obtain Basic or Standard access.

I will also update the documentation to mention this, you're right that it should be clearer about it.

I didn't know about it until you just mentioned it, will take a look at it now. I don't understand why access can't be granted in the same way that access is granted for Google Cloud services using our already existing google cloud services account or Oauth 2 etc and why Ads API in particular has to be so unnecessarily complicated.

But I agree with you that more clarity in the docs would be helpful :)

Here's an example of a somewhat more thorough walk through from a 3rd party, although it still only gives a 1 sentence explanation of Explorer Access (which it says is "automatic" which it obviously isn't):

https://github.com/kLOsk/adloop

[JasonBroderick]

The instructions for Explorer Access are still dire I'm afraid. In a whole article, all it says about explorer access is:

"Explorer Access level with an Approved status. This means that Google was able to automatically review and approve your developer token application for Explorer Access level."

Explorer access should just be the default level of access, there is no good reason not to let people explore their own account data that is unnecessarily obstructive. And there seems to be no way to "apply" for Explorer access, you are either granted it automatically, or you can apply for Basic Access by providing a pint of blood and sacrificing your first born child. 😅

Any help much appreciated :)

[ZLeventer]

Strong +1 on this. I'm setting up Google Ads MCP for our B2B marketing ops team (e2open) and hit the exact same friction. We have active Google Ads accounts, a legitimate developer token, and the only thing we want to do is read our own campaign performance data through an official Google-published MCP server.

The design documentation requirement is absurd for this use case. I shouldn't need to submit UI mockups and architecture diagrams for a tool Google built. The current process forces MCP end-users to cosplay as third-party tool developers.

At minimum, the README should be upfront about this blocker. Right now it says "get a Developer Token" as if that's a single step, when in reality:

1. You get a test-account-only token immediately
2. You discover it doesn't work with real accounts
3. You find out you need Basic access
4. You discover Basic access requires design documentation for a tool you didn't build

Even a clear warning in the README with guidance on how to navigate the application as an MCP end-user would save people significant time.