Multiple ad accounts in Claude: one call, one account

You hold four ad accounts. You ask which of them had the worst week. Back comes a confident ranked table — and nothing in it tells you whether it read four accounts, or three, or the same one twice. That is the shape of every multi-account problem here: nothing errors, nothing looks wrong, and the only open question is which accounts the answer was about.

One call, one account

The listing tool is the only place the plural exists. Read on 2026-09-10, it describes itself as retrieving

the list of ad account IDs that the current user has access to

After that, the plural stops. The entity reader, the performance-trend tool, the activity log and the advertiser-context tool each declare ad_account_id as a required parameter, and each takes exactly one. The trend tool is explicit about the boundary: entity IDs you scope it with must all be the same type and must belong to the account you named.

So a portfolio question is not a portfolio query. It is a loop, run by the assistant, whose results are added up in prose afterwards. Meta returns no combined figure and never sees the combined question — which puts every cross-account number in the category that has to be checked against Ads Manager before you act on it. It gets narrower still: the entity reader states that account-level requests support neither filtering nor sorting, so even inside one account, “rank these” happens after the data arrives rather than in the request.

Running several accounts through one assistant is a routine problem before it is a tooling problem. The Claude Ads Operator course builds that routine, starting from attaching the connector properly.

Two flags, and they gate different things

Both instructions are written to the assistant rather than enforced at the door: the schema says that if the first flag is false, do not use that account ID or any ad objects under it in subsequent calls. That is guidance arriving in the same channel as everything else the model reads, and worth treating as guidance. The rollout flag is a server-side gate you cannot switch on yourself; the queryable flag is a narrower state that leaves the rest of the surface working. In a portfolio you will usually hold some of each, which is exactly why a whole-list question can come back short without saying so.

Three things that bite once there is more than one

1. Entity IDs from the wrong account are dropped, not rejected silent

   Paste a list of campaign IDs gathered from two accounts and the reader does not fail. Its own parameter documentation says IDs that do not match the requested level or ad account are omitted, and listed in an additional-info block beside the result. The table you get is correct and incomplete, and the note explaining why is somewhere you were not looking.

   The trade: the fix is one call per account, which is slower and eats more of the conversation than the single paste you wanted to do.

2. The error tool is the one read that does fan out useful

   The delivery-error tool takes a list of entity IDs rather than an account, and its schema says several may be provided and that an account ID returns the errors of its child entities. That makes a one-call sweep for delivery blockers across a set of accounts the only genuine cross-account read on the surface — and the first thing to run on a Monday if you hold several.

   The trade: its scope is narrower than the word error suggests. It covers hard delivery stops on child objects, and rules out pacing problems, restricted accounts and ad rejections in its own description.

3. One chat is one traced conversation, whoever it is about

   Every tool requires a conversation ID the assistant generates once and then repeats. The parameter says it

   groups the calls belonging to one conversation with the advertiser so they can be traced together

   and that a new one is started only when a genuinely new conversation begins. Pair that with the field on every call carrying the operator’s request in their own words, and a session hopping between three clients is filed at Meta as a single thread that did so.

   The trade: a chat per account means retyping context you would rather carry over.

It will answer a portfolio question. It will not have read a portfolio.

What the guides describe, and what they are describing

Search this and the useful-looking results are mostly about somebody else’s server. The page ranking for the multi-account configuration question sits on the vendor blog Ryze AI (Ira Bodnar, last updated 25 June 2026); it promises switching between accounts by name in one chat, no re-auth, no separate login per client, and an assistant that remembers which account you are in. Read it closely and that describes Ryze’s own connector, not Meta’s — the article never quotes the official surface. Workspace separation is a real reason third-party servers exist, and this blog has been fair to that trade before. The mistake is carrying the promise across to the official endpoint, where the only thing that switches account is the ID in the next call.

• Asking for a total across accounts and treating it as data. Nothing at Meta computed it. It is addition performed in the chat, on figures fetched one account at a time.
• Assuming the account list tells you who manages what. It names owners; agency access is documented as not shown.
• Reading the two flags as one. An account can be usable for errors, activity history and catalog work while the entity reader is closed to it.
• Letting one chat roam across clients. It is traced as one conversation and each call carries the request in your words.

Try this tonight Ask for your ad account list and nothing else, then read the two flag columns and the business column before any performance question. Write down the accounts where either flag is false, and the ones whose owning business is not the one you expected. That short list is the set of accounts a portfolio question can quietly skip — and from tonight it is what you scope your questions around, one account at a time, instead of discovering it inside an answer.