is_ads_mcp_enabled: false — what it means, what to do

You followed the setup, the connector authenticated fine, and then the first real question came back with a flag instead of an answer. Nothing you configured is wrong.

What almost nobody says out loud: Meta does not document this. I checked their connector documentation for permissions, rate limits, rollout eligibility and this flag by name. None of it is covered. So everything written about it, including this page, is observation rather than policy — and you should weigh it accordingly.

What it actually means

Access is being switched on account by account. The flag is Meta reporting the state of that switch for the account you asked about. It is not a permissions problem on your side, not a missing scope, and not something a support ticket resolves faster.

The check worth running

List every ad account you can access. For each one, report
whether the ads MCP is enabled and the last 7 days of spend.

If one comes back enabled, you are done — work in that account. If none do, the honest position is that you are waiting, and no amount of reconfiguring changes it.

While you wait, the routine itself is free and readable — it is the part that matters more than the plumbing. Take the skill →

What to do instead of waiting

1. Read the routine now, connect later FREE

   The connector is plumbing. The thing that changes your week is knowing what to ask on Monday, how to find real winners rather than high-ROAS accidents, and what never to automate. That is published in full, free, and none of it needs a working connector to learn. The trade: reading it is not the same as running it — but you arrive ready instead of starting from zero.

2. Build your own app and go straight at the API BEST ROUTE

   The rollout gate is on the connector, not on the Marketing API underneath it. You can register your own Meta app, generate a token scoped to your own ad accounts, and have Claude talk to the API directly — today, with no gate and no third party holding your credential.

   The part everyone gets wrong: this does not require App Review. App Review is for reaching ad accounts belonging to other businesses. For accounts you own or administer in your own Business Manager, a system user token is enough, and you can have one in about fifteen minutes.

   The rough shape: create an app at developers.facebook.com and add the Marketing API product, then in Business settings create a system user, assign it the ad accounts you want it to reach, and generate a token with ads_read (and ads_management only if you intend to write). Long-lived user tokens expire after 60 days; system user tokens do not, which is the whole reason to use them. The trade: you now own a credential. It belongs in an environment variable, never in a repo, and it is worth scoping to read-only until you trust what you have built.

3. Know which tier you land in — and that the names changed

   A new app starts on the lower Marketing API tier, which is enough to work with your own accounts; the higher tier mainly raises rate limits. The thing worth knowing is that Meta renamed all of this on 4 May 2026, and almost every guide still uses the retired names.

   What guides still say	What Meta calls it now
   Ads Management Standard Access (AMSA)	Marketing API Access Tier
   Standard Access	Limited Access
   Advanced Access	Full Access

   Meta also lowered the bar for the upper tier: 500 Marketing API calls in the past 15 days, down from 1,500, with an error rate under 15% across the last 500 calls. Nothing in your code changes — existing access carries over — but if you are following a tutorial that talks about "Advanced Access", you are reading something written before May and you should assume other parts of it have aged too.

4. Use a third-party server in the meantime

   Third-party MCP servers wrap Meta's Marketing API and have no rollout gate, so they work today. Everything you will find on GitHub is one of these — Meta publishes no repository of its own. They also generally want a long-lived access token rather than an OAuth login, which is a real difference in what you are handing over — the honest comparison is here. The trade: you are accepting a credential arrangement you would not choose if the official path were open to you. Set a reminder to revisit it when your account flips.

5. Get the account ready

   Write your naming convention. Write down your target CPA, your margins, your do-not-claim list. Every one of those makes the first session after you get access dramatically more useful, and none of them require the connector. The trade: it is unglamorous prep work with no immediate payoff.

The flag is a queue you cannot jump. The API underneath it is not gated at all, which is why "wait for access" is the wrong instinct if you actually need this working this week.

Things that do not work

• Reconnecting the connector. It authenticated correctly. The flag is about the account, not the connection.
• Re-granting permissions. This is not a scope problem, so widening scopes changes nothing.
• Creating a new ad account. A fresh account is not more likely to be enabled, and you inherit none of your history.
• Waiting on support. There is no queue position to escalate; it is a rollout, not a ticket.

One caveat worth carrying into that check: an account can pass this gate and still refuse to answer — enabled and queryable are separate flags.

Try this tonight Run the multi-account check first — it takes under a minute and it is free. If every account comes back false, the own-app route is the one that gets you working this week rather than whenever the rollout reaches you.

Once it does flip, the setup takes about three minutes and the first thing worth doing is a read-only week.