X Ads MCP

X Ads MCP ist der offizielle, remote betriebene Model-Context-Protocol-Server von X für die X Ads API. Der Streamable-HTTP-Endpunkt lautet https://ads-api.x.com/mcp. Laut X kann ein MCP-fähiger Client die angebotenen Werkzeuge automatisch entdecken und damit Kampagnenkonten lesen, Kampagnen- und Reichweitenanalysen abrufen sowie Anzeigenkampagnen verwalten. Die primäre Dokumentation ist https://docs.x.com/x-ads-api/mcp. Das ist kein allgemeiner Server für Timeline-, Such-, Direktnachrichten- oder sonstige Standardzugriffe auf X: Er ist auf die Werbeplattform, Ads-Konten, Kampagnen, Creatives, Targeting und Ads-Analytics begrenzt.

Was der Ads-Server kann – und was nicht

Die X-Dokumentation führt Werkzeuge für Ads-Konten und Lesedaten auf, darunter Kampagnen, Line Items, Finanzierungsinstrumente, promotete Posts, Targeting-Kriterien und aktive Entitäten. Analytics-Werkzeuge liefern Account-Statistiken und Kampagnen-Reichweitenschätzungen. Für die Vorbereitung von Zielgruppen gibt es Suchen nach Interessen und Orten. Schreibwerkzeuge können Kampagnen und Line Items anlegen oder aktualisieren, Targeting hinzufügen oder entfernen, Nullcast-Ad-Posts erzeugen und Posts promoten.

Das bedeutet nicht, dass ein KI-Client damit beliebig auf X zugreift. Der Server ersetzt keine allgemeine X API, verwaltet keine privaten Nachrichten und erweitert keine Rechte außerhalb der Ads API. Auch der eigentliche Zugriff richtet sich nach der jeweiligen App-Freigabe und den Rollen im Ads-Konto. X unterscheidet etwa Account Administrator, Ad Manager, Campaign Analyst, Organic Analyst und Creative Manager. Ein Agent erhält nur die Funktionen, die der angemeldete Nutzer, die autorisierte App und das konkrete Ads-Konto zulassen.

OAuth, Scopes und Account-Grenzen

Für die MCP-Verbindung wird laut X eine eigene App in der X Developer Console benötigt, mit Ads-Projektzugriff und Read-and-Write-App-Berechtigung. Der Nutzer authentifiziert sich mit seinem eigenen OAuth-2-Token; für den Remote-MCP nennt X die Scopes ads.read, ads.write und offline.access. ads.read schaltet Lesen und Analytics frei. Wer nur analysieren möchte, sollte ads.write weglassen: Schreibwerkzeuge scheitern dann autorisiert statt versehentlich Änderungen vorzunehmen. offline.access erlaubt das Aktualisieren des Tokens; ohne diesen Scope laufen Zugriffstoken laut X nach kurzer Zeit ab und können nicht automatisch erneuert werden.

Die OAuth-Grenze ist relevant für Agenten: Der Server sieht nur Ads-Konten, auf die dieser Nutzer Zugriff hat. Eine einzelne X-App kann nach der X-Dokumentation nur einen aktiven OAuth-Grant pro App-und-Nutzer-Kombination halten; eine Anmeldung in einem zweiten Client kann den ersten Token-Satz widerrufen. Für mehrere Clients ist deshalb je Client eine eigene App sinnvoll. Zugangstoken, Refresh-Tokens, Client-Secrets und Callback-Codes gehören nie in Prompts, Versionskontrolle oder Screenshots. Native Clients verwenden PKCE und benötigen kein Secret; bei vertraulichen Clients gelten die von X dokumentierten Authentifizierungsanforderungen.

Kampagnenänderungen und menschliche Freigabe

Der MCP-Server kann externe Werbeobjekte verändern. X reduziert einen Teil des Risikos, indem neu erstellte Kampagnen und Line Items immer PAUSED starten; Geld wird laut Anbieter erst ausgegeben, wenn ein Nutzer sie ausdrücklich aktiviert. Das ist eine sinnvolle Schutzschicht, aber keine vollständige Genehmigungsstrecke. Die Tools activate_campaign und activate_line_item können diese letzte Aktivierung ausführen. Bei Budget, Targeting, Creatives, Audience-Änderungen oder Promotion sollte deshalb eine Person die beabsichtigten Parameter, Kontozuordnung und Freigabe vor dem Aktivieren prüfen. Ein separater Analyse-Client ohne ads.write ist für Reporting und Planung die sicherere Grundeinstellung.

Ads- und Kundendaten, Modellpfad und Prompt Injection

Werkzeugantworten können Kampagnenleistung, Reichweitenwerte, Finanzierungsinformationen, Zielgruppen- oder Standortkriterien sowie promotete Inhalte enthalten. Die Ads API kann außerdem Custom Audiences mit X-, Web- oder Mobile-Daten verwalten; diese Daten sind besonders schutzbedürftig. Der Datenpfad ist nicht nur „X zu X“: X liefert Resultate an den MCP-Client, und der Client entscheidet, welche Tool-Resultate er an das verbundene Sprachmodell weitergibt. Bei einem gehosteten Modell können diese Inhalte somit zusätzlich zum Client und zu X beim Modellanbieter verarbeitet werden. Vorher müssen Datenschutzvorgaben, Auftragsverarbeitung, Aufbewahrung und die Client- bzw. Modellkonfiguration geprüft werden.

Unvertraute Namen, Posts, Zielgruppenbezeichnungen oder Analysefelder können Text enthalten, der wie Handlungsanweisungen wirkt. Das ist Prompt Injection, nicht eine vertrauenswürdige Anweisung des Nutzers. Der Agent sollte Tool-Daten als Daten behandeln, Schreibaktionen niemals allein aus solchen Inhalten ableiten und Aktivierungen manuell bestätigen lassen. Verwende nach Möglichkeit getrennte Lese- und Schreibsitzungen und ein Ads-Testkonto für erste Versuche.

Limits, Betrieb und Quellcode

X dokumentiert für die Ads API Token- und teilweise Ads-Konto-bezogene Rate Limits. Die aktuell maßgeblichen Limits und Reset-Zeitpunkte stehen in HTTP-Response-Headern; Client oder Agent sollte diese auswerten, Abrufe bündeln, nur seit der letzten Synchronisierung aktualisierte Daten anfragen und bei 429 bzw. erschöpften Kontingenten warten statt aggressiv zu wiederholen. Schreiboperationen sind nicht automatisch durch die gleichen konto-bezogenen Limits abgedeckt wie Leseoperationen.

X veröffentlicht für X Ads MCP eine offizielle Remote-Dokumentation und einen Gateway-Endpunkt, aber zum Review am 2026-09-08 kein öffentliches, X-betriebenes Quellcode-Repository dieses Ads-spezifischen Servers. repo_url und GitHub-Sterne sind daher absichtlich leer. Das öffentliche Repository xdevplatform/xMCP betrifft einen separaten allgemeinen X-API-MCP-Server und darf nicht als Quellcode oder Popularitätswert für X Ads MCP ausgegeben werden. Social Media und Automatisierung passen, weil der Server Werbeaktivitäten auf X kontrolliert lesbar, analysierbar und automatisierbar macht.

Eigene X-Developer-App mit Ads-Projektzugriff, ein X-Nutzer mit Zugriff auf mindestens ein Ads-Konto sowie ein MCP-Client mit Streamable-HTTP- und OAuth-2-Unterstützung.

In der X Developer Console eine Native App mit Read-and-Write-Berechtigung und passender Callback-URI anlegen, Ads Project aktivieren und den Client mit https://ads-api.x.com/mcp verbinden. Für Lesezugriff nur ads.read offline.access anfordern; ads.write erst für genehmigte Änderungen ergänzen.

claude mcp add x-ads https://ads-api.x.com/mcp --transport http --client-id YOUR_OAUTH2_CLIENT_ID --callback-port 8080

OAuth 2 mit dem eigenen X-Nutzer und den Scopes ads.read, optional ads.write sowie offline.access. Native Clients nutzen PKCE; Tokens und Callback-Codes geheim halten.

Nur die Ads-Konten und Ads-API-Funktionen, die für den OAuth-Nutzer, die X-App und die jeweilige Ads-Konto-Rolle freigegeben sind. ads.write erlaubt verändernde Werkzeuge.

X übermittelt Ads-API-Ergebnisse an den MCP-Client. Der Client bestimmt, welche Tool-Ergebnisse an das verbundene Modell weitergereicht werden; bei gehosteten Modellen können Ads- und Kundendaten daher zusätzlich beim Modellanbieter verarbeitet werden.

ads.write kann Kampagnen, Targeting, Creatives und Aktivierungen verändern. Prompt Injection in Tool-Daten, Token-Diebstahl, Weitergabe von Audience-/Leistungsdaten und übersehene Rate Limits sind relevante Risiken. Mit ads.read beginnen, Secrets schützen und Aktivierungen manuell prüfen.