The short answer

You do not need a separate AI setup for every Google Ads login. The cleaner approach is to connect each Google login as its own named profile, save the accounts that profile can reach, and then identify the target account by customer ID when you work.

But first check whether you actually need multiple logins. One Google user can already have access to many advertiser accounts through a Google Ads Manager account (MCC). A second login becomes useful when access is split across different Google users or when the accounts you need sit below a nested manager-account boundary that your current connection does not traverse.

The practical rule: organize by access path, not by client. A profile represents a Google login and its permissions – not a campaign, client, or reporting view.

Table of Contents

Multiple accounts and multiple logins are different problems

Agencies often use “multi-account” to describe several different setups. Separating them avoids unnecessary OAuth connections.

One Google login, many client accounts

If your Google user has direct access to several advertiser accounts – or access through one MCC – you may only need one HireOtto profile. Google’s access model lets a user inherit access through a linked manager account, and HireOtto includes directly accessible accounts plus the accounts immediately under each accessible MCC.

Several Google logins, separate account portfolios

You need multiple profiles when client access has been granted to different Google users. This is common after acquisitions, with freelancer-plus-agency teams, or when clients insist on inviting a specific operations inbox.

An MCC inside another MCC

Google Ads supports manager accounts nested inside other manager accounts. Google’s API can retrieve those hierarchies recursively, but an application still decides how it discovers and stores accounts. HireOtto currently looks one level below each account directly visible to a connected Google login. It does not automatically continue through another MCC.

If the account you need sits below an inner MCC, connect a different Google login that has direct access to that inner MCC. Renaming or reconnecting the same Google user does not change what Google makes available to that user, so it does not extend the account boundary.

A simple profile strategy that scales

Treat the setup as a small access map. Before authenticating anything, list the Google users, the manager accounts they can enter directly, and the advertiser accounts your team actually needs.

1. Map the access paths

For each Google login, record:

  • the email or internal owner;

  • the MCCs or advertiser accounts it can access directly;

  • the child accounts directly under those MCCs;

  • the Google Ads access level; and

  • whether another connected profile already covers the same accounts.

This exposes duplicate logins and deeper manager structures before they become an authentication mystery.

2. Start with the broadest useful primary login

Connect the Google user that covers the largest relevant portfolio through direct access or a first-level MCC. Complete OAuth, select only the accounts you intend to use, and save them. Completing consent without saving accounts leaves the connection unusable.

Connect my Google Ads account to HireOtto.

3. Add another profile only when it adds a new access path

Give each additional profile a short operational nickname. Names such as agency_mcc, client_ops, or jane_gmail make the source of access obvious. Avoid naming a profile after a single advertiser if that login covers many advertisers.

Connect another Google Ads account. Call it "client_ops".

Open the returned authorization link and deliberately choose the different Google user. After consent, select and save the required accounts.

4. Refresh after Google Ads access changes

A saved account list is not automatically updated every time a client grants or removes access in Google Ads. Refresh the relevant login after an invitation is accepted, a client is linked under an MCC, or a permission changes.

Refresh accounts for the Google login connected as client_ops, then show the account name and customer ID for every saved account.

5. Verify every profile with a read-only check

Do not make a campaign change as the first test. Confirm the account list, choose a customer ID, and request a small report or campaign listing.

Using customer ID [CUSTOMER_ID], list enabled campaigns and their daily budgets. Do not make any changes.

If the expected advertiser is missing, stop there. Check the Google user, its direct access, the MCC level, whether the accounts were saved, and whether the profile was refreshed.

How the AI should choose the right account

A natural-language account name is convenient, but names are not unique. Two clients can both have an account called “US Search,” and the same advertiser may appear through more than one access path. Use customer IDs as the final routing key.

A reliable operating pattern is:

  • ask the assistant to list accounts with account name, customer ID, connected profile, and Google login;

  • select the intended customer ID explicitly;

  • run a read-only query to confirm context;

  • describe the proposed change and request a preview; and

  • approve the write only after checking the account, scope, dates, and units.

For customer ID [CUSTOMER_ID], review the last 30 days and propose budget changes. 
Show the current and proposed values first. 
Do not apply anything until I approve.

The profile answers “which Google identity provides access?” The customer ID answers “which advertiser should this request affect?” Keep both visible in important workflows.

Permissions still apply

Connecting a Google login does not give it new Google Ads privileges. The Google Ads API follows the access level assigned in Google Ads, including access inherited through a manager hierarchy. A read-only user can inspect eligible accounts and reports but cannot make campaign changes.

That makes Google Ads access levels a useful control. Give each connected Google user only the permissions it needs, remove stale client access, and use a dedicated operations login when that fits the agency’s governance model. The OAuth consent itself should not be treated as proof that every requested action is allowed – or strategically sensible.

What does not work

Connecting the same Google user twice

A second profile name does not create a second permission set. If both OAuth flows use the same Google user, both see the same direct-access accounts and the same inherited access.

Assuming the outer MCC exposes every descendant

A Google user may be able to navigate a deeper hierarchy in Google Ads, while a particular integration’s account-discovery workflow stops earlier. With HireOtto, plan around directly accessible accounts plus one child level per connected login.

Using account names as the only identifier

Names change and can collide. Keep the Google Ads customer ID in prompts that report on or change a specific account.

Testing access with a write

A paused campaign edit is still a real account change. Validate identity, account coverage, and permissions with a read-only request before any mutation.

Forgetting to save or refresh accounts

OAuth can succeed while the usable account list remains empty because no accounts were saved. New access granted later also requires a refresh before it appears.

How HireOtto turns multiple logins into one working surface

HireOtto lets Agency-plan users connect additional Google logins as named profiles inside the same AI client. It can list saved accounts across those connections, refresh a specific connected email after access changes, and route Google Ads work to the profile associated with the selected customer ID. That removes the need to maintain a separate Claude or ChatGPT connector for every Google user.

For nested MCCs, HireOtto’s current account discovery deliberately stops after the first child level. Connect a separate Google user with direct access to the inner MCC, save that profile’s accounts, and then verify the target customer ID before running any workflow. Human review still matters for account selection, access governance, and all consequential writes.

For the exact setup and limits, use the HireOtto authentication guide and Google Ads MCP tools reference. If you have not connected HireOtto yet, begin with the quickstart guide.

Copy-paste setup checklist

  • Inventory every Google user that currently holds client access.

  • Draw the MCC hierarchy and mark which managers each user can access directly.

  • Choose one primary login that covers the broadest relevant portfolio.

  • Connect additional profiles only when they add a distinct Google identity or deeper direct-access point.

  • Use short, descriptive profile names without colons.

  • Select and save the required accounts during OAuth.

  • Refresh the relevant connected login after access changes.

  • Verify each account with a read-only query.

  • Use customer IDs for routing and request previews before writes.

  • Review Google Ads user access regularly and remove stale permissions.

Frequently asked questions

Can one HireOtto connection manage accounts from multiple Google users?

Yes. Multi-profile support lets Agency-plan users connect multiple Google logins through one HireOtto connector and use their saved Google Ads accounts from the same AI client.

Do I need one profile per client?

Usually not. Create profiles per Google login or distinct access path. One profile can cover many advertiser accounts when the connected user has direct access or first-level MCC access.

Why is an account missing even though I can see it in Google Ads?

Common causes are that the account was not selected and saved during OAuth, access was granted after the last refresh, the wrong Google user was connected, or the advertiser sits below a nested MCC that HireOtto does not traverse automatically.

Can I connect the same Gmail under another profile name to reach a nested MCC?

No. A new nickname does not change the Google user’s direct-access accounts. Use a different Google login that has direct access to the inner MCC.

Does a Google Ads OAuth connection bypass read-only access?

No. Google Ads API requests follow the user roles configured in Google Ads. The connected user’s effective access level determines which actions are allowed.

Should every team member share the same Google login?

Not necessarily. Use your agency’s security and accountability policy. Separate user access can improve attribution and offboarding, while a dedicated operations login may simplify automation. In either case, grant the minimum Google Ads access needed and review it regularly.

About Me

I’m Suyash – badminton junkie, ex‑GroupM ad‑ops grunt, first marketer at a B2B SaaS startup, and creator of Hiretto: Google Ads MCP Server.

My mission: less clicking, more thinking.

Let’s build leverage together.

Reply

Avatar

or to participate