Meta Ads MCP for agencies: one agent, many client accounts

A Meta Ads MCP connection for an agency is one login that reaches every client you manage. That is the feature, and it's also the whole risk. A brand running its own account can't launch in the wrong one. You can, in one sentence, and the agent will report success.

This is one part of our guide to AI agents for Meta ads. It covers the agency case only: several brands, one agent, and the four places they get mixed up.

How one connection reaches every client account

Meta grants access at the moment a call is made. If your system user, or the person who logged in, is assigned to an ad account in Business Settings, the existing token can use that account immediately. No new token, no new scopes, no reconnecting the assistant.

Add a client on Monday and the agent can spend in their account on Monday. Nothing in the connection asks which client a task is for. That question is yours to answer, every time, and an agent left to answer it will pick whatever came first in the list.

One limit to know: this covers accounts inside your own business portfolio. An account owned by the client's business has to be shared with yours as a partner, and Meta may want Business Verification before it allows full control.

The four places clients get mixed up

The ad account

The obvious one. The agent is asked to "launch the approved ads" and there are six accounts it could mean.

We started with a default account, as most tools do, and it worked for as long as there was a single brand. The second brand made the default a trap, and the sharpest edge is somewhere you might not look: switching an ad on. If activation looks up "the account" and gets the default, it can act in an account the ad doesn't live in. Ours finds the account from the ad itself, through its ad set and campaign. An ad already knows where it lives. Nothing should ask again.

The Page

Easier to miss, and worse when it happens. The ad account decides who pays. The Page decides whose name is on the ad. An ad for one client published under another client's Page is visible to the public, with a brand's name on something it never saw.

Our rule now: the Page belongs to the client's project. A single install-wide Page setting still exists, but it is read only while there is exactly one project. With two or more, a project that names no Page is refused at launch. It would be easy to fall back to the other brand's Page and keep things moving, and that's exactly the behaviour we removed.

The audience

We once had a launch path with a fallback audience: adults 18 to 65 in the United States, optimised for link clicks. Then a campaign for a school audience in another country was created with nothing specified, and it took the fallback. It was paused, as everything we create is, so it cost nothing. It was also one click from spending a client's budget on the wrong continent.

There is no default audience any more. A launch needs the client's saved campaign settings, or it needs places, ages, objective and optimisation goal spelled out. Missing any of them is an error, and the error is the feature.

The results

This one loses no money on the day and costs the most over a quarter. If the agent reads performance across every account at once, it learns that a certain hook "wins". It wins for a snack brand's impulse buyers. It says nothing about a B2B client's procurement leads. Feed that blended lesson into both clients' next briefs and each gets ads shaped by the other's customers.

Scope every read that feeds creative decisions to one client: results, references, voice samples, rejected concepts. Blending is correct in one case only, a single brand spread over several accounts.

The rule underneath all four: never guess

Every one of those failures came from a helpful default. So the rule we ended up with is blunt. When there is one project, a call that names none gets that one. When there are several, a call that names none is refused, and the refusal lists the projects so the agent can ask or pick properly.

It feels strict for about a day. After that you notice the agent has started saying which client it's working on at the top of every task, because it has to.

A launch follows the same rule from the other side. It takes its project from the concepts being launched, refuses a batch that mixes two brands, and accepts only that project's campaign settings.

What to share across clients, and what to keep apart

The right-hand column is short on purpose. Shared instructions are where a brand leaks without anyone opening the wrong account: we once wrote one client's event line and dark background into a prompt every project used, and they appeared in another client's ads. We now run a check that fails the build if any client's name, product or colour appears in shared code or shared instructions.

Who can do what, per client

An agency has more than one person and more than one way in. Our split is by how much we can see of the confirmation step:

• An operator's own agent, run from a terminal, gets every tool, with a permission prompt in front of each one that spends.
• A personal access token never gets approval or activation.
• A chat app connected by OAuth, such as Claude, ChatGPT or Gemini, also never gets anything that spends or that sets a brand's identity. Its confirmation screens belong to the app, and we can't promise what they show.

Each grant is one person in one workspace, and it can be disconnected from that person's settings without touching anyone else's.

Reporting back to the client

Clients don't need a login to your tooling, and giving them one creates a second approval path nobody planned. We give each project a read-only link that shows its live ads and results. Nothing internal is on it: no rejected concepts, no reasoning notes, no render costs. The link can be rotated or switched off from the board.

If you're setting this up now, do the project split before you connect anything that can write. The next thing to settle is spend, which is the subject of the guardrails for an AI agent running Meta ads.