One key. Two tokens. No context-switching.

The MCP server takes one bearer key on every request and resolves your Meta access token server-side when a tool actually needs it. You never paste a Meta token into your MCP client.

The BrandMov key

Generate one on /dashboard/mcp. Send it as a standard bearer:

Authorization: Bearer bm_live_your_brandmov_key

That single header authenticates every tool in this server — competitor watchlists, swipe files, Meta read calls, Meta writes (when enabled). Revoke anytime from settings; the key stops working instantly.

Meta tokens, resolved server-side

When a Meta-API tool runs, the server looks up your Meta access token in the order:

1. Explicit access_token kwarg on the tool call.
2. X-Meta-Access-Token HTTP header on the request.
3. The token stored on your account (set by Connect Meta Ads — partner-share or paste).
4. META_ACCESS_TOKEN env var (self-hosted stdio transport only).

Stored Meta tokens are encrypted with Fernet (AES-128-CBC + HMAC), keyed by a secret that never leaves our servers.

Per-request override

Managing multiple brands or running an agency? Add an extra header on a specific request to switch Meta tokens without touching your stored connection:

Authorization:        Bearer bm_live_your_brandmov_key
X-Meta-Access-Token:  EAAG...the_other_brands_token

Auth errors

If a Meta tool is called before you’ve connected, the response is structured so your agent can recover gracefully:

{
  "error": {
    "message": "Meta Ads authentication required",
    "auth_required": "meta",
    "action_required": "Pass access_token or set X-Meta-Access-Token header"
  }
}