Kostenloses Tool

MCP-SSE-Tester

Prüfe, ob dein MCP-Server tatsächlich über den HTTP+SSE-Transport antwortet — und ob das für die Clients, die dir wichtig sind, noch reicht.

Funktioniert mit Streamable-HTTP- und SSE-Endpunkten, zum Beispiel https://mcp.example.com/mcp
Dieser Server benötigt eine Authentifizierung
Wird nur für diese eine Anfrage verwendet und nie gespeichert.

Funktionieren ist nicht dasselbe wie verkaufbar

Wenn der Transport stimmt, bleibt das Problem, dass niemand sieht, was dein Server kann. MCP Showcase macht aus derselben URL ein Live-Playground mit Doku für jedes Tool.

So funktioniert es

link
SSE-Endpunkt einfügen

Meist der Pfad, der auf /sse endet — Server hängen ihn allerdings an verschiedenen Stellen ein.

play_circle
Wir verbinden uns wie ein Client

Zuerst Streamable HTTP, dann SSE — und das Ergebnis sagt dir, welcher Transport tatsächlich geantwortet hat.

checklist
Sehen, was der Transport hergibt

Handshake, Protokollversion und die vollständige Tool-Liste, dazu das rohe Request-Log.

Was HTTP+SSE eigentlich ist

Der ursprüngliche HTTP-Transport für MCP. Der Client öffnet einen langlebigen Server-Sent-Events-Stream, um Nachrichten vom Server zu empfangen, und schickt eigene Nachrichten per POST an einen separaten Endpunkt. Zwei Endpunkte, je eine Richtung. Es funktioniert — und hinter Proxys und Load Balancern ist es genau so sperrig, wie man es erwartet.

Füge deinen Endpunkt oben ein: Wir verbinden uns so, wie es ein echter Client tut — zuerst Streamable HTTP, dann SSE — und sagen dir, welcher tatsächlich geantwortet hat.

Warum ein reiner SSE-Server aus einem Client verschwinden kann

Das ist der Fehlerfall, den man verstehen sollte, denn er erzeugt keine Fehlermeldung. Aktuelle Clients versuchen zuerst Streamable HTTP, und nicht alle fallen zurück. Ein Server, der nur SSE spricht, ist für diesen Client dann schlicht nicht vorhanden — er meldet einen leeren Server oder gar nichts, statt eines Transportfehlers. In deinen Logs sieht nichts falsch aus, weil dich nichts erreicht hat.

Wenn dein Server früher in einem Client auftauchte und nach einem Update aufgehört hat, prüfe das zuerst.

Solltest du umstellen?

Wenn du den Server kontrollierst: ja. Streamable HTTP ist ein Endpunkt statt zwei, verbindet sich sauber neu und ist das, worauf sich das Ökosystem geeinigt hat. Unterstütze beides, solange du Nutzer auf älteren Clients hast, und lass SSE danach fallen. Wenn du den Server nicht kontrollierst, sagt dir diese Seite immerhin, mit welchem Transport du es zu tun hast, bevor du anfängst, deinen Client zu debuggen.

Verwandte Tools

Der Transport ist nicht der schwere Teil

Wenn ein Client deinen Server erreicht, bleibt das Problem, dass niemand erkennen kann, was er tut. Eine Tool-Liste ist keine Vorführung, und ein Interessent installiert keinen Client, um es herauszufinden. MCP Showcase richtet sich auf dieselbe URL und erzeugt ein Live-Playground mit generierter Doku für jedes Tool — damit die Bewertung deines Servers einen Klick kostet.

Häufig gestellte Fragen

Der ursprüngliche HTTP-Transport für MCP: Der Client öffnet einen langlebigen Server-Sent-Events-Stream für Nachrichten vom Server und schickt eigene Nachrichten per POST an einen separaten Endpunkt. Er wurde von Streamable HTTP abgelöst, das beides über einen Endpunkt erledigt.

Es ist abgelöst, nicht entfernt. Etliche Server sprechen weiterhin nur SSE und etliche Clients unterstützen es weiterhin — aber neuere Clients versuchen zuerst Streamable HTTP und manche fallen nicht mehr zurück. Genau deshalb kann ein reiner SSE-Server still aus einem Client verschwinden, der ihn vorher gesehen hat.

Fast immer wegen des Fallback-Verhaltens. Ein Client, der Streamable HTTP versucht und nicht zurückfällt, findet an einem reinen SSE-Endpunkt nichts — und meldet das meist als leeren Server statt als Transportfehler.

Wenn du den Server kontrollierst: ja — ein Endpunkt statt zwei, robuster bei Reconnects, und es ist das, was aktuelle Clients erwarten. Unterstütze während der Umstellung beides, wenn du bestehende Nutzer hast.

Dieser Tester nennt ihn ausdrücklich in der Ergebniszusammenfassung, zusammen mit der ausgehandelten Protokollversion. Das Request-Log darunter zeigt die tatsächlichen Aufrufe, wenn du sehen willst, warum einer fehlgeschlagen ist.

Weitere kostenlose MCP-Tools