Warum der automatische OAuth-Flow bei MCP in Antigravity scheitert (und wie du es fixt)

Das Model Context Protocol (MCP) ist der aktuelle Hype in der KI-Welt: Statt für jeden Dienst eigene REST-API-Wrapper zu bauen, klinkt sich dein KI-Agent (wie Google Antigravity) direkt über eine standardisierte Schnittstelle in externe Tools ein.

Klingt genial? Ist es auch! Zumindest in der Theorie.

In der Praxis stößt man schnell auf ein gewaltiges Problem: Der automatische OAuth-Flow für Remote-MCP-Server. Auch dynamic client registration (DCR) genannt. Wenn du versuchst, Dienste wie HeyGen oder Meta Ads über deren offizielle Remote-MCP-Endpoints anzubinden, fliegen dir plötzliche 401 Unauthorized Fehler um die Ohren.

Übrigens funktioniert OAuth mit Claude und ChatGPT/Code ganz problemlos. Nur Google macht wieder mal Probleme.

In diesem Beitrag zeige ich dir genau, was hinter dem automatischen OAuth-Flow in MCP steckt, warum er in Antigravity aktuell oft fehlschlägt und wie wir das Problem mit zwei konkreten Praxisfällen (HeyGen & Meta Ads) über lokale Stdio-Server dauerhaft gelöst haben.

Was ist das Model Context Protocol (MCP) und der OAuth-Flow?

Das von Anthropic ins Leben gerufene Model Context Protocol (MCP) unterscheidet grundsätzlich zwei Wege, wie ein Agent mit Tools kommuniziert:

1. Local Stdio Transports: Der KI-Agent startet lokal auf deinem Rechner ein Script oder ein CLI-Tool (in Python, Node.js etc.) und kommuniziert über stdin/stdout. Authentifiziert wird meist simpel über Umgebungsvariablen wie API_KEY.
2. Remote SSE Transports: Der Agent verbindet sich über Server-Sent Events (SSE) mit einem gehosteten Remote-Server im Netz (z. B. https://mcp.heygen.com/mcp/v1/ oder https://mcp.facebook.com/ads).

Bei Remote MCP wollen die Anbieter (zu Recht) vermeiden, dass du geheime API-Keys im Klartext teilen musst. Stattdessen setzen sie auf OAuth 2.0 (PKCE).

Wie der OAuth-Flow eigentlich funktionieren sollte:

1. Dein Agent schickt einen initialize-Request an den Remote-MCP-Endpoint.
2. Der Server antwortet mit 401 Unauthorized und einem OAuth-Challenge-Header.
3. Deine Entwicklungsumgebung (IDE oder CLI) fängt das ab, öffnet automatisch ein Browserfenster und lässt dich einloggen.
4. Nach dem Login schickt der Server ein Access-Token an den Agenten zurück, und die Tools stehen bereit.

Das Problem: Warum der OAuth-Flow in Antigravity scheitert

In der Realität gibt es bei Antigravity (CLI & Agent Runner) zwei Hauptgründe, warum dieser schicke OAuth-Flow fehlschlägt:

1. Fehlendes interaktives Browser-Handling im Background-Runner: Im Gegensatz zu voll integrierten Desktop-Apps fängt der Hintergrund-Prozess der CLI den OAuth-Handshake oft nicht sauber mit einem Browser-Popup ab. Der initialize-Call scheitert schlicht mit einem 401 Unauthorized, und Antigravity wirft den Server komplett aus der Tool-Liste.
2. Restriktive API-Scopes & Beta-Sperren: Remote-Endpoints wie Metas mcp.facebook.com/ads verlangen spezifische Beta-Berechtigungen (z. B. ads_mcp_management). Übergibst du dort einen normalen, voll gültigen Graph-API-Token als Bearer-Header, lehnt der Remote-Server diesen strikt ab.
3. Redirect URL: Wenn der Anbieter des MCPs die Redicrect URL für deinen Client (Antigravity) nicht hinterlegt hat, schlägt der OAuth-Prozess auch fehl. So war es bei mir mit Heygen.

Praxis-Fall 1: HeyGen Remote MCP

Das Problem

Beim Versuch, den offiziellen Remote-Endpoint von HeyGen einzubinden, sah die ursprüngliche mcp_config.json so aus:

{
  "mcpServers": {
    "heygen": {
      "serverUrl": "https://mcp.heygen.com/mcp/v1/"
    }
  }
}

Beim Start meldete Antigravity sofort:
Encountered error in step execution: server name heygen failed to load: calling "initialize": sending "initialize": Unauthorized

Der Remote-Endpoint verlangte zwingend den OAuth-Login im Browser. Über die Antigravity-Settings > Customization konnte ich den Prozess zwar starten, jedoch schlug der Prozess trotzdem fehl.

Der Fix

Statt auf den OAuth-Remote-Server zu setzen, haben wir das offizielle Python-Paket heygen-mcp in der lokalen Python-Umgebung installiert und die Konfiguration auf Stdio umgestellt:

{
  "mcpServers": {
    "heygen": {
      "command": "/Users/jochen/.gemini/mcp-venv/bin/heygen-mcp",
      "env": {
        "HEYGEN_API_KEY": "sk_V2_DEIN_HEYGEN_API_KEY"
      }
    }
  }
}

Ergebnis: Antigravity startet das Paket lokal, nutzt deinen HeyGen API-Key im Hintergrund und stellt alle Avatar- & Video-Tools ohne jeglichen Login-Frust bereit!

---

Praxis-Fall 2: Meta Ads Remote MCP

Bei Meta Ads war das Problem noch tückischer.

Natürlich konnte auch der Meta Ads MCP nicht einfach über OAuth im Browser authentifiziert werden.

Das Problem

Metas offizieller Server https://mcp.facebook.com/ads lieferte trotz hinterlegtem Authorization: Bearer <TOKEN> Header folgenden Fehler:

{
  "title": "This resource is restricted to certain users. Please verify your identity and try again",
  "detail": "Authorization Error",
  "status": 401
}

Obwohl der Token bei direkten REST-Abfragen an graph.facebook.com/v20.0/ mit 200 OK perfekt funktionierte und alle Werbekonten zurücklieferte, verweigerte der Remote-MCP-Server den Dienst.

Der Fix: Ein eigener lokaler FastMCP Server

Da der Meta-Token völlig intakt war, haben wir in wenigen Zeilen Python einen eigenen lokalen Stdio MCP Server mit der Bibliothek FastMCP gebaut:

meta_ads_mcp.py (Script):

#!/usr/bin/env python3
import os
import httpx
from mcp.server.fastmcp import FastMCP

# MCP Server Instanz erstellen
mcp = FastMCP("meta-ads", instructions="Meta Ads Management & Reporting Tool")

ACCESS_TOKEN = os.environ.get("META_ACCESS_TOKEN")
GRAPH_URL = "https://graph.facebook.com/v20.0"

@mcp.tool()
def meta_get_ad_accounts() -> str:
    """Listet alle verknüpften Meta Werbekonten auf."""
    url = f"{GRAPH_URL}/me/adaccounts"
    params = {
        "access_token": ACCESS_TOKEN,
        "fields": "id,name,account_status,currency,account_id"
    }
    with httpx.Client(timeout=30.0) as client:
        r = client.get(url, params=params)
        return r.text

@mcp.tool()
def meta_get_insights(ad_account_id: str, date_preset: str = "last_30d", level: str = "account") -> str:
    """Holt Performance-Metriken (Spend, CPC, CTR, ROAS) für ein Konto oder eine Kampagne."""
    if not ad_account_id.startswith("act_"):
        ad_account_id = f"act_{ad_account_id}"
    url = f"{GRAPH_URL}/{ad_account_id}/insights"
    params = {
        "access_token": ACCESS_TOKEN,
        "date_preset": date_preset,
        "level": level,
        "fields": "campaign_name,spend,impressions,clicks,cpc,ctr,purchase_roas,date_start,date_stop"
    }
    with httpx.Client(timeout=30.0) as client:
        r = client.get(url, params=params)
        return r.text

if __name__ == "__main__":
    mcp.run()

Anpassung in der mcp_config.json:

Statt der Remote-URL verbinden wir Antigravity jetzt mit unserem lokalen Script:

{
  "mcpServers": {
    "meta-ads": {
      "command": "/Users/jochen/.gemini/mcp-venv/bin/python3",
      "args": [
        "/Users/jochen/.gemini/mcp-venv/bin/meta_ads_mcp.py"
      ],
      "env": {
        "META_ACCESS_TOKEN": "EAANh1gp_DEIN_META_TOKEN"
      }
    }
  }
}

Das Resultat: Der lokale Server startet in Millisekunden. Antigravity kann sofort Live-Daten abfragen. Im Test z. B. €18.706,86 Spend und einen ROAS von 1,91x für die beste Kampagne ausgelesen!

Fazit & Empfehlung für deine MCP-Praxis

Remote-MCP-Server mit OAuth klingen nach der Zukunft, stecken in vielen CLI-Agenten aber noch in den Kinderschuhen oder scheitern an verdeckten API-Beschränkungen der Anbieter.

Mein Tipp:
Wenn ein Remote MCP Server in Antigravity einen 401 Unauthorized wirft, verschwende keine Zeit damit, Header an Remote-URLs zu hängen.

Baue dir stattdessen mit FastMCP (Python) oder dem TypeScript MCP SDK einen kleinen lokalen Stdio-Wrapper. Du behältst die volle Kontrolle über deine API-Tokens, vermeidest lästige Browser-Logins und deine Agenten laufen stabil und blitzschnell!