Meta Ads MCP: dynamic registration invalid_client_metadata
Meta's ads MCP rejected a direct public-client registration on 2026-09-06 (invalid_client_metadata), so Sume uses a pre-approved Meta client id.
If a Meta Ads MCP connection fails at registration with invalid_client_metadata and "Dynamic registration is not available for this client", the client was not pre-approved. Sume saw exactly that on 2026-09-06 and solved it by configuring a Meta client id that is approved for its callback URL, instead of relying on dynamic registration.
What was checked
Sume's workspace integrations doc records that Meta's protected resource metadata returned resource: https://mcp.facebook.com/ads, and that an unauthenticated initialize request returned HTTP 401 pointing at that metadata URL. The authorization metadata advertised Facebook v26 authorization, Graph v26 token exchange, S256 PKCE, public-client authentication and a registration endpoint.
What failed
A direct public-client registration attempt was rejected with invalid_client_metadata and the message above. Advertising a registration endpoint is not the same as accepting any client.
What Sume does instead
The server environment sets META_ADS_MCP_CLIENT_ID to a client that has approval for the callback URL, which is /api/integrations/meta-ads/callback on the web host. If that value is not set, Connect still tries the advertised dynamic registration, and when registration fails the page shows a connection error. The development demo stays usable either way.
| Step | Result |
|---|---|
| Metadata resource | https://mcp.facebook.com/ads |
| Unauthenticated initialize | HTTP 401 with metadata URL |
| PKCE method | S256 |
| Direct public registration | Rejected: invalid_client_metadata |
Rollout is account-level too
Sume's doc lists what must be verified per environment and account: consent, exact tool schemas under each grant, read-only scope acceptance, and Meta's account rollout flag (is_ads_mcp_enabled). A successful fixture is never reported as a successful Meta consent.
If you hit this yourself
If you are wiring Meta's server into your own client, a registration error like this means you need a client id that Meta has approved for your redirect URI. If you only need ad data in a Sume agent, use the Meta Ads row on the Integrations page and skip registration entirely. For the direct route see adding Meta's server to Claude Code, and note that this post describes what was observed in September, which can change.
Reading the error text
The two parts of the message do different jobs. invalid_client_metadata is the registration error code from the OAuth dynamic registration flow. The sentence "Dynamic registration is not available for this client" tells you the refusal is about this client, not about a malformed request. Fixing JSON fields will not help.
The practical lesson is to separate discovery from permission. Discovery documents tell you where the endpoints are. Whether your client may use them is a separate decision made by the vendor.
Related posts
More in Integrations
- n8n webhook auth is Basic, Header or JWT: verify Sume's HMAC yourself
n8n's Webhook node offers Basic, Header and JWT auth, none of which checks Sume's HMAC. Verify sume-v1 over timestamp.raw_body in code, 300 second window.
- n8n video workflow: Respond immediately vs Sume's 30-second sync wait
In n8n, use Respond immediately and let Sume call back. Sume's sync mode waits at most 30 seconds, too short for most video jobs, so avoid the last-node wait.
- Notion API image block with a Sume URL: PNG works, WebP is not listed
Notion's external image block needs a directly hosted, public URL, and its file-type list has no WebP. Ask Sume for png or jpeg, then append the block.
- Notion audio block from a Sume music URL: the extension check
Notion's external audio block lists .mp3, .wav, .ogg, .oga and .m4a. Check that the Sume artifact URL path ends in one; if not, use Notion's File Upload.
Written by Sume