MCP-Spec 2026 aus Sicht eines Ads-Servers im Betrieb

Die MCP-Spezifikation vom 2026-07-28 entfernt Sitzungen auf Protokollebene, überführt Tasks und MCP Apps in ein formales Erweiterungs-Framework, verschärft die OAuth-Regeln und stuft Dynamic Client Registration zugunsten von Client ID Metadata Documents als veraltet ein. PaidSync betreibt produktiv einen Remote-MCP-Server mit 630+ Ads-Tools über 14 Plattformen für Claude- und ChatGPT-Clients, und dies sind Arbeitsnotizen dazu, was jede Änderung aus dieser Sicht bedeutet. Am ersten Tag geht nichts kaputt; veraltete Funktionen haben ein Mindestfenster von zwölf Monaten.

Jede Protokollaussage unten stammt aus dem offiziellen Release-Beitrag und dem Changelog vom 2026-07-28, beide zum Schreibzeitpunkt am 1. August 2026 gelesen. Die Meinungen sind unsere. Der Release-Beitrag nennt Zahlen zum Umfang, die zeigen, warum diese Revision wichtig ist: knapp eine halbe Milliarde SDK-Downloads pro Monat über die wichtigsten SDKs, die TypeScript- und Python-SDKs jeweils mit über einer Milliarde Downloads insgesamt, und Honeycomb meldet, dass fast 20 Prozent seiner monatlichen interaktiven Abfragen inzwischen von Agenten stammen. Die Berichterstattung von The Register gibt wieder, dass die Maintainer sie als wichtigste Veröffentlichung seit dem Start von Remote-MCP bezeichnen. Von unserem Platz aus stimmt das ungefähr, und der Großteil der Bedeutung ist betrieblich statt spektakulär.

Was sich am 28. Juli änderte

Zustandsloser Kern und Retry-Problem

Die zentrale Änderung: Der Handshake initialize/notifications/initialized entfällt, ebenso der Header Mcp-Session-Id. Jede Anfrage trägt nun Protokollversion, Client-Fähigkeiten und Client-Identität in _meta, und ein neuer verpflichtender RPC server/discover lässt Clients Fähigkeiten vorab abfragen. Änderungsbenachrichtigungen vom Server zum Client werden in einem einzigen optionalen Stream subscriptions/listen zusammengefasst. Die praktische Wirkung, auf die die Maintainer abzielen und die The Register hervorhebt, ist, dass jede Anfrage jede Server-Instanz hinter einem gewöhnlichen Load Balancer erreichen kann, mit gewöhnlichen Kubernetes-Werkzeugen und ohne gemeinsamen Session-Store.

Hier die ehrliche Einschätzung aus Betreibersicht: Die Protokollsitzung war nie der Ort, an dem unser harter Zustand lag. Bei einem Ads-Server sind die wichtigen Zustände OAuth-Berechtigungen, die gewählte Werbekonto-Auswahl, Ausgabenlimits und Ratenbudgets pro Plattform. Dieser Zustand liegt in einer Datenbank, die dem authentifizierten Nutzer zugeordnet ist, denn er muss eine unterbrochene Verbindung überleben. Der alte Handshake fügte eine zweite, fragile Sitzung hinzu, die unabhängig von der echten sterben konnte, und ein Deploy oder Neustart des Balancers kappte Protokollsitzungen, während die Auth-Sitzungen intakt waren. Diese Schicht zu streichen beseitigt eine ganze Klasse verwirrender Fehler. Der Ersatz der Spezifikation für legitimen Zustand über mehrere Aufrufe hinweg sind vom Server erzeugte Handles, die als gewöhnliche Tool-Argumente weitergereicht werden, was Ads-Abläufe ohnehin so lesen: Konto auswählen, ein Handle erhalten, es weiterreichen. Signieren Sie sie und lassen Sie sie ablaufen, denn jede Instanz kann sie jetzt kalt empfangen.

Die scharfe Kante ist die Wiederholungssemantik

Unter der Zustandslosigkeits-Geschichte steckt die Änderung, die am ehesten Vorfälle mit echtem Geld verursacht: SSE-Stream-Resumability und erneute Zustellung von Nachrichten entfallen. Nach 2026-07-28 verliert ein unterbrochener Antwort-Stream die laufende Anfrage, und der Client muss sie als neue Anfrage mit neuer Request-ID erneut senden. Bei get_campaign_performance kostet eine Wiederholung nichts. Bei einer Kampagnenerstellung oder Budgetänderung ist eine blinde Wiederholung der Weg, auf dem ein Agent doppelt ausgibt. Wenn Ihr Server Geld verändert, brauchen Ihre Tool-Verträge Idempotenz-Keys und Ihr Backend Deduplizierung, denn der Transport verspricht nicht mehr, das ursprüngliche Ergebnis erneut zuzustellen. Unsere ausgelieferten Schreibaktionen sind mit den Flags dry_run und confirm_destructive abgesichert, was den Schadensradius begrenzt, aber ein Gate ist keine Deduplizierung. Behandeln Sie beide als getrennte Kontrollen und bauen Sie beide.

Tasks passen endlich zu Ads-Arbeit

Tasks verlässt den experimentellen Kern und wird zur offiziellen Erweiterung io.modelcontextprotocol/tasks. Das Redesign ersetzt den blockierenden Aufruf tasks/result durch Polling über tasks/get, ergänzt tasks/update für Eingaben vom Client zum Server mitten in der Aufgabe und lässt Server Task-Handles unaufgefordert zurückgeben, ohne Opt-in pro Anfrage. Der Beitrag von The Register hebt den Aspekt der Dauerhaftigkeit hervor: Tasks werden über stabile Handles adressiert, sodass ein Client eine Task-ID speichern und das Polling nach einem Absturz oder Neustart fortsetzen kann.

Ads-Arbeit ist von Natur aus lang laufend. Ein Audit über einen MCC mit 200 Kampagnen. Eine Massenpause über die Anzeigengruppen einer ganzen Saison, genau die Art Arbeit, für die unsere Dokumentation zu Meta-Massenoperationen existiert. Ein plattformübergreifender Bericht über 90 Tage. Heute muss all das innerhalb der Frist fertig werden, die der Proxy vor Ihrem Server erzwingt, und jede Produktivumgebung hat so einen Proxy. Poll-basierte Tasks passen zu schlichter HTTP-Infrastruktur: kein gehaltener Stream, den man betreuen müsste, nichts, was ein Edge-Timeout mittendrin kappen könnte.

tasks/update ist für Ads der leise wichtige Teil. Eine Task, die mitten in der Ausführung Eingaben annimmt, kann vor ihrer zerstörerischen Hälfte pausieren und nachfragen. Heute besteht ein Freigabe-Gate aus zwei Tasks: ein Probelauf, dann eine ausdrückliche Bestätigung. Mit Tasks kann dasselbe Sicherheitsmuster eine einzige dauerhafte Operation mit einer menschlichen Pause darin sein, was für Agenten, die mehrstufige Arbeit planen, die bessere Form ist. Der Vorbehalt ist struktureller Art: Erweiterungen sind standardmäßig deaktiviert und brauchen ein ausdrückliches Opt-in auf beiden Seiten, daher zahlt sich das aus, wenn Claude und ChatGPT Client-Unterstützung ausliefern, nicht vorher.

MRTR ersetzt vom Server ausgelöste Anfragen

Vom Server ausgelöste Anfragen (roots/list, sampling/createMessage, elicitation/create) werden durch das Muster der Multi Round-Trip Requests ersetzt. Ein Server, der mehr Informationen braucht, gibt ein Ergebnis mit resultType: "input_required" samt seinen Fragen zurück; der Client wiederholt die ursprüngliche Anfrage mit den in inputResponses angehängten Antworten. Jedes Ergebnis trägt nun ein verpflichtendes resultType, und Ergebnisse von Servern älterer Protokolle, die es weglassen, müssen als vollständig behandelt werden, was gemischte Versionsflotten beherrschbar hält.

Elicitation war der Weg, wie ein Server mitten in einem Aufruf fragte: „Welches Ihrer 14 Werbekonten meinten Sie?“ MRTR behält die Frage und kehrt die Mechanik um. Der Server kann eine offene Frage nicht mehr im Prozessspeicher parken, weil die Wiederholung auf einer anderen Instanz landen kann; jeder Kontext, den die Frage braucht, kommt in requestState. Das nachzurüsten ist lästig und von der Konstruktion her richtig. Es formalisiert auch eine Lektion, die jeder Remote-Ads-Server früh lernt: Chat-Clients verschwinden ständig mitten im Gespräch, sodass jede Frage mitten in einer Operation, die nicht wiederaufnehmbar ist, eine Operation verwaist zurücklässt. Wir haben genug halb fertige Abläufe gesehen, um das für die Spezifikation als Aufholen an die Realität zu werten.

Autorisierung wird schwerer falsch umzusetzen

Drei Verschärfungen, alle belegt im Changelog. Autorisierungsserver sollten den Parameter iss gemäß RFC 9207 in Autorisierungsantworten aufnehmen, und Clients müssen ihn vor dem Einlösen eines Codes gegen den erfassten Aussteller validieren. Client-Zugangsdaten sind nun ausdrücklich an den Autorisierungsserver gebunden, der sie ausgestellt hat: nach Aussteller indiziert, nie über Aussteller hinweg wiederverwendet, bei Wechsel des Ausstellers neu registriert. Und Clients müssen bei der Registrierung einen application_type angeben, was eine seit Langem bestehende Klasse abgelehnter Localhost-Redirects für CLI- und Desktop-Agenten behebt. Enterprise-Managed Authorization kommt ebenfalls als formale Erweiterung, die Organisationen zentrale Kontrolle darüber gibt, welche MCP-Server ihre Agenten nutzen dürfen.

Warum das bei Ads-Servern wichtiger ist als bei den meisten: Ein einziges Bearer-Token für einen Remote-Ads-MCP-Server steht vor echten Werbekonten bei Google, Meta und LinkedIn, mit echten Budgets dahinter. Genau dafür wurden OAuth-Mix-up-Angriffe erfunden, und die Validierung von iss ist die Standard-Gegenmaßnahme. Die meisten neuen Pflichten landen im Client-Code, funktionieren aber nur, wenn Server korrekte Autorisierungs-Metadaten veröffentlichen, gegen die validiert werden kann. Zur Klarstellung: Die heute ausgelieferte Basis von PaidSync sind Metadaten des Autorisierungsservers nach RFC 8414 und Metadaten geschützter Ressourcen nach RFC 9728 an den Well-Known-Pfaden, eine veröffentlichte security.txt, eine MCP Server Card und ein Agent-Auth-Manifest sowie Sitzungswiderruf, damit ein Nutzer einen verbundenen Client jederzeit kappen kann. Das ist die aktuelle stabile Revision, sorgfältig umgesetzt, keine Umsetzung von 2026-07-28; wir sagen das offen, weil eine Spezifikation zu lesen nicht heißt, sie auszuliefern.

DCR raus, CIMD rein

Dynamic Client Registration (RFC 7591) ist als Registrierungsmechanismus von MCP zugunsten von Client ID Metadata Documents formal veraltet. Sie bleibt aus Gründen der Abwärtskompatibilität für Autorisierungsserver verfügbar, die noch nicht umgestellt haben. Bei CIMD ist die client_id eine HTTPS-URL, die der Client-Betreiber kontrolliert, und der Autorisierungsserver ruft die Metadaten des Clients von dieser URL ab.

Dafür hätten wir zweimal gestimmt. Bei DCR registrierte sich jeder unbekannte Agent selbst in Ihrem Autorisierungsserver: anonyme Zeilen, selbst angegebene Namen, null Reputation und ein regelmäßiger Aufräumjob für Registrierungen, die nie jemand genutzt hat. CIMD ändert die Frage am Tor von „Hat sich dieses Ding registriert?“ zu „Wem gehört diese Domain?“ Für einen Server, der Werbeausgaben absichert, ist dieser Unterschied richtlinientauglich. Er macht Allowlists bekannter Agent-Plattformen möglich und macht den Zustimmungsbildschirm ehrlich: Der Client-Name, den ein Nutzer freigibt, ist durch eine Domain belegt, nicht vom Client selbst eingetippt. Der Migrationsrat ergibt sich von selbst: DCR während des Veraltungsfensters am Laufen halten, CIMD für jeden Client bevorzugen, der es mitbringt, und jetzt die Vertrauensrichtlinie entwerfen, denn die Richtlinie ist der schwere Teil, nicht das Parsen.

MCP Apps und die Änderungen darunter

MCP Apps

MCP Apps kommt als offizielle Erweiterung im neuen Erweiterungs-Framework. Die Dokumentation zu Erweiterungen beschreibt sie so, dass Server interaktive UI-Elemente, Diagramme, Formulare, Videoplayer, inline in Unterhaltungen anzeigen können. Für Ads-Arbeit liegen die Kandidaten auf der Hand: ein Ausgabentrend als echtes Diagramm statt einer ASCII-Tabelle, eine Kampagnenvorschau vor dem Start, ein Freigabeformular für eine Massenänderung mit einem Kontrollkästchen pro Kampagne. Ein gerendertes Freigabeformular ist eine deutlich bessere Sicherheitsfläche als ein freies „Ja, bestätigen“. Gleicher Vorbehalt wie bei Tasks: Opt-in auf beiden Seiten, also bestimmt die Client-Übernahme den Takt.

Header und Caching

Streamable-HTTP-POSTs müssen nun die Header Mcp-Method und Mcp-Name tragen, damit Gateways routen und Ratenlimits setzen können, ohne JSON-Bodys zu parsen. Bei 438 Live-Tools auf unserem Server ist Richtlinienkontrolle pro Tool am Edge, strengere Limits für Mutations-Tools, WAF-Regeln, die nie einen Body anfassen, eine günstige Fähigkeit, die wir gern nehmen. Listenergebnisse (tools/list und verwandte) müssen nun ttlMs und cacheScope tragen, womit Clients endlich aufhören können, einen großen Tool-Katalog bei jedem Zug neu zu laden. Die Spezifikation legt Servern auch nahe, Tools in deterministischer Reihenfolge zurückzugeben, um Prompt-Cache-Treffer des LLM zu verbessern; bei Katalogen unserer Größe ist das ein direkter Hebel für die Token-Kosten. Über den Zielkonflikt bei der Katalogröße haben wir in warum die Tool-Anzahl ein Vorteil ist geschrieben.

Abkündigungen mit Frist

Roots, Sampling und Logging sind zusammen mit dem älteren HTTP+SSE-Transport veraltet, unter einem neuen Feature-Lebenszyklus, der ein Übergangsfenster von mindestens zwölf Monaten garantiert. Nichts davon tut hier weh. Sampling auf Serverseite war an einer Abrechnungsgrenze immer die falsche Form, denn es bedeutet, dass ein Tool-Server die Modell-Tokens von jemand anderem ausgibt; Logging wandert nach stderr oder OpenTelemetry, was Produktionsserver ohnehin tun. Die Lebenszyklus-Richtlinie selbst ist der Gewinn: Abschaltungen kommen jetzt mit einem Zeitplan, nach dem sich planen lässt, statt als Überraschung.

Was sich nicht ändert

Checkliste für die erste Woche (Agent-Builder)

Wenn Sie einen Remote-MCP-Server betreiben oder bauen, ist das die Reihenfolge, in der wir arbeiten würden, basierend auf dem Betrieb eines Servers in Produktion.

Zu ChatGPT hinzufügen: Öffnen Sie PaidSync.ai im Plugin-Verzeichnis von ChatGPT, installieren Sie es und melden Sie sich an.

Zu Claude hinzufügen: Öffnen Sie PaidSync.ai im Connector-Verzeichnis von Claude, klicken Sie auf Verbinden und melden Sie sich an.

Häufig gestellte Fragen

Weiterlesen

Was ist MCP für Werbung Die Einführung → Verbinden Sie Ihre Werbekonten mit Claude Einrichtungsanleitung → PaidSync vs Google Ads MCP (offiziell) Vergleich →