MCP auf der Edge: Was sich ändert, wenn MCP sicher in jedem POP ausgeführt wird

Model Context Protocol (MCP)-Server bieten KI-Agenten eine standardisierte Möglichkeit, Tools aufzurufen, Ressourcen zu lesen und Prompts gebündelt abzurufen. 

Die meisten MCP-Server laufen in einer herkömmlichen Cloud-Architektur: eine Region, hinter einem Loadbalancer, mit einer Session pro Client. Das ist durchaus nachvollziehbar – bis ein Agent am anderen Ende der Welt vierzig Tool-Aufrufe tätigt, um eine Aufgabe zu erledigen, und jeder Aufruf innerhalb seiner Entscheidungsschleife eine transkontinentale Hin- und Rückreise erfordert. Diese Fernverbindungen summieren sich schnell und beeinträchtigen die Leistung Ihrer App erheblich.

Der Betrieb Ihres MCP-Servers als WebAssembly-Binärdatei auf Fastly Compute in all unseren Rechenzentren, unterstützt und geschützt durch unsere globale Plattform mit mehr als 620 Tbit/s, verändert grundlegend, was MCP für Agenten und die Menschen, die sie kontrollieren, leisten kann. Wir haben gerade ein Beispielprojekt veröffentlicht, das genau das ermöglicht und auf das Ihre Programmieragenten bei der Modernisierung Ihres eigenen MCP-Stacks zurückgreifen können. 

Sie müssen nicht mehr für Nischen-Hosting bezahlen oder Ihren Server in einer einzelnen geografischen Region isolieren. Außerdem können Sie das gesamte Projekt lokal mit Viceroy, der lokalen Compute-Laufzeit von Fastly, testen, bevor Sie es im Netzwerk bereitstellen. Im Folgenden erläutern wir, wie das Ausführen von zustandslosem MCP auf der Edge unter der Haube funktioniert.

Latenz dort beheben, wo es darauf ankommt: in der Agenten-Schleife

Agenten machen nicht nur einen einzigen Aufruf und stoppen dann. Sie entdecken Tools, rufen eines auf, lesen das Ergebnis, rufen ein anderes auf und durchlaufen manchmal ein Dutzend Schleifendurchläufe, bevor sie antworten. Jeder einzelne dieser Hops liegt auf dem kritischen Pfad des Workflows des Agenten. Wenn Sie Ihren MCP-Server in einer herkömmlichen Architektur hosten, kann es bei einem Endnutzer-Entwickler auf der anderen Seite der Welt, der auf Ihren MCP-Server angewiesen ist, zu einer Gesamtverzögerung von bis zu 500 ms pro Aufruf kommen – und sein Agent führt möglicherweise Dutzende von Aufrufen pro Aktion aus. Diese Verzögerung summiert sich schnell und führt zu einer furchtbaren User Experience für den Endnutzer. 

Auf der Edge ist der Server nur Millisekunden von dem Ort entfernt, von dem eine Anfrage ausgeht. Es gibt keine Beschränkung auf eine bestimmte Herkunftsregion und keinen Rücktransport zu einem eigenen Rechenzentrum. Der Tool-Katalog, der Aufruf-Dispatch, die Authentifizierungsprüfung: alles wird am nächstgelegenen POP verarbeitet. Bei einem kommunikationsintensiven Agenten-Workload summiert sich die Einsparung von Hunderten von Millisekunden bei jedem Aufruf zu einer spürbar schnelleren agentischen Schleife.

Designbedingt zustandslos – sodass jeder POP antworten kann

Die neueste MCP-Revision (2026-07-28) ist so entwickelt, dass sie zustandslos ist. Dies entspricht eher den Best Practices für HTTP, und wir freuen uns, die Agentic AI Foundation bei ihren Forschungen rund um dieses Thema und künftige Durchbrüche zu unterstützen.

Der wesentliche Unterschied in dieser Revision besteht darin, dass es keinen Initialisierungs-Handshake gibt. Jede Anfrage enthält ihre eigene Identität und ausgehandelte Funktionen in einem _meta-Block, und jeder Status, der zwischen Aufrufen erhalten bleiben muss, wird mit der Anfrage übermittelt, anstatt auf dem Server zu verbleiben.

Da keine Session an eine Maschine gebunden ist, ist ein zustandsloses Edge-Deployment jetzt viel überzeugender als in früheren Spezifikationen. Mit dieser Implementierung auf einer modernen Plattform wie der von Fastly: 

• Ihr MCP-Server wird sofort überall bereitgestellt. Eine Anfrage kann in jedem Fastly-Datacenter weltweit eingehen und korrekt verarbeitet werden.

• Die Skalierung erfolgt horizontal und automatisch ohne Kaltstartverzögerung. Fastly startet Ihren MCP-Server in weniger als 50 Mikrosekunden.

• Jede Anfrage wird in unserer WebAssembly-basierten Laufzeit sicher isoliert, wodurch jegliches Noisy-Neighbor-Sicherheitsrisiko eliminiert wird.

Sie erhalten die betriebliche Einfachheit einer global verteilten Plattform mit einer einzigen Bereitstellung.

Langlaufende und mehrstufige Aufgaben, ohne eine Verbindung offenzuhalten

„Zustandslos“ klingt in der Regel unvereinbar mit „lang laufend“. Die beiden Fortsetzungsmechanismen der Spezifikation sorgen dafür, dass es funktioniert, und unsere Implementierung stützt sich auf beide:

• Multi-Round-Trip-Anfragen (MRTR): Ein Tool kann mitten im Aufruf pausieren, um den Client um Eingaben zu bitten, und später fortgesetzt werden. Der In-Flight-Status wird in einem opaken Token versiegelt, das der Client beim nächsten Aufruf zurücksendet. Es wird keine Verbindung offengehalten; jede beliebige Instanz nimmt die Arbeit wieder auf.

• Die Tasks-Erweiterung: ein Tool, das lang andauernde Aufgaben auslösen und ein Task-Handle zurückgeben kann. Der Client fragt nach Abschluss ab, anstatt den Socket für die gesamte Dauer offen zu halten. Dies passt gut zum Anfragemodell von Fastly.

Beide Fortsetzungstoken sind mittels authentifizierter Verschlüsselung kryptografisch versiegelt und an die Identität des Aufrufers gebunden, sodass das Modell „Zustand reist mit der Anfrage“ nicht zu einer Möglichkeit wird, Arbeit zu fälschen oder zu kapern.

Der Tool-Katalog, aus dem Cache ausgeliefert

Discovery- und Listing-Aufrufe – server/discover, tools/list, prompts/list, resources/list – liefern für jeden Aufrufer dieselbe Antwort und ändern sich selten. Sie eignen sich perfekt dazu, über die Native-Caching-Funktion von Fastly auf der Edge gecacht zu werden.

Der Server versieht diese Antworten mit Hinweisen zur Aktualität und zum Cache-Geltungsbereich, sodass der Cache den Tool-Katalog weltweit für Agenten bereitstellen kann, ohne den Handler jedes Mal erneut auszuführen. Alles, was davon abhängt, wer anfragt, wird automatisch aus dem Cache ausgeschlossen und gelangt niemals über Anfragen hinweg nach außen.

Sicherheit wird durchgesetzt, bevor etwas Ihren Origin erreicht

Da Fastly allem vorgeschaltet ist, womit Ihre Tools tatsächlich kommunizieren, ist es der richtige Ort, um den Zugriff durchzusetzen. Wir haben darauf geachtet, folgende Funktion in den Prototyp zu integrieren:

• Die Authentifizierung ist standardmäßig auf „fail-closed“ gestellt:  eine Fehlkonfiguration führt zu einem gesperrten oder nicht verfügbaren Endpunkt, niemals zu einem stillschweigend offenen.

• Bearer-Tokens werden auf der Edge verifiziert:  ES256 JWTs werden anhand eines gecachten JWKS validiert, sodass nicht authentifizierte oder fehlerhaft formatierte Anfragen abgelehnt werden, bevor sie Ihnen nachgelagert Kosten verursachen.

• Autorisierung ist standardmäßig verweigert (Default-Deny) und bereichsbezogen: ein Aufrufer muss über die spezifischen Scopes verfügen, die ein Tool deklariert; ein Tool, das keine deklariert, ist unter Autorisierung nicht aufrufbar.

• Anfrage-Bodys werden vor dem Parsen begrenzt: JWKS-Abrufe sind SSRF-geschützt und interne Fehler werden für das Debugging mit Korrelations-IDs unkenntlich gemacht.

Eine nicht autorisierte oder missbräuchliche Anfrage wird innerhalb von Fastly gestoppt und erreicht Ihr Backend nie.

Unterstützt durch die volle Leistungsfähigkeit der Fastly-Plattform

Der MCP-Prototyp läuft in Fastly Compute. Das bedeutet, dass er die gesamte Netzwerkstabilität und alle Fähigkeiten der Plattform als Rückenwind erhält, wie z. B.:

• Kaltstarts unter 50 Mikrosekunden

• sichere Isolation über unsere WebAssembly-Laufzeit

• DDoS-Schutz mit einem Klick

• über 620 Tbit/s Kapazität, wenn Sie sie brauchen

• Request Collapsing zur Vermeidung eines Thundering-Herd-Problems, wenn Ihr Produkt viral geht

Die zustandslose MCP-Spezifikation und die Laufzeitumgebung von Fastly verstärken sich gegenseitig: Das Protokoll wurde so konzipiert, dass der Zustand mit der Anfrage übertragen werden kann, und genau dort, an der Edge, kommt dieses Design am besten zur Geltung. Was zuvor ein Service war, der normalerweise auf eine einzige Region beschränkt und an eine Sitzung gebunden ist, wird nun zu etwas, das überall ist – in direkter Nähe jedes Agenten, der ihn aufruft.

Steuern Sie KI- und Agenten-Traffic mit ARC mithilfe von Rate Limits pro Schlüssel, Ausgabenkontrollen, detailliertem Logging und automatischem Anbieter-Failover.

Entdecken Sie, wie Fastly for AI Teams dabei unterstützt, agentenbasierte Apps auf der Edge zu entwickeln, zu schützen und zu betreiben.

Um es auszuprobieren, sehen Sie sich das Projekt auf GitHub an.