Prüfen Sie, ob Ihr MCP-Server wirklich funktioniert. URL einfügen und einen Pass/Fail-Bericht zu Verbindung, Handshake, Transport und bereitgestellten Tools erhalten.
Eine grüne Checkliste beweist, dass Ihr Server funktioniert. Sie zeigt einem Kunden nicht, was er tut. Richten Sie MCP Showcase auf dieselbe URL und erhalten Sie ein Live-Playground zum Ausprobieren im Browser.
Ein bereitgestellter Endpunkt, kein lokaler Prozess. Bei Bedarf ein Bearer-Token ergänzen — es wird einmal verwendet und nie gespeichert.
Ein echter MCP-Handshake, zuerst Streamable HTTP, dann SSE als Fallback — genau so, wie Claude, Cursor oder VS Code es tun.
Ein Bericht Prüfung für Prüfung, dazu das vollständige Request- und Response-Log — ein Fehler zeigt damit auf den konkreten Schritt statt auf eine allgemeine Meldung.
Füge oben eine Model-Context-Protocol-URL ein: Dieser MCP-Server-Tester führt einen echten Client
dagegen aus — dieselbe Abfolge, die Claude Desktop, Cursor oder VS Code beim Verbinden ausführen.
Er öffnet die Verbindung, führt den initialize-Handshake aus, handelt eine
Protokollversion aus und ruft tools/list auf. Jeder Schritt wird einzeln als
bestanden oder fehlgeschlagen ausgewiesen.
Genau diese Trennung ist der Punkt. Ein Client, der deinen Server nicht sieht, liefert eine einzige nutzlose Fehlermeldung; hier bekommst du sieben Antworten und erfährst, ob der Endpunkt nicht erreichbar ist, der Handshake scheitert, der Transport nicht passt oder die Tool-Liste schlicht leer ist.
initialize wird abgeschlossen und eine
Protokollversion ausgehandelt. Ein Server, der TCP annimmt, hier aber scheitert, läuft zwar,
spricht aber kein MCP.
Das ist der häufigste Grund, zu einem gehosteten Tester zu greifen, und es ist fast immer eines
von drei Dingen. Der Endpunkt ist nicht öffentlich erreichbar — er lauscht auf localhost, steht
hinter einer Firewall, oder das Deployment ist noch nicht durch. Der bereitgestellte Pfad
unterscheidet sich vom lokalen: MCP-Server werden unter /mcp, /sse oder
im Root eingehängt, und der Pfad, der mit mcp dev funktioniert hat, ist nicht immer
der, den dein Hoster freigibt. Oder der bereitgestellte Build ist schlicht älter als der lokale.
Das Request- und Response-Log unter dem Ergebnis unterscheidet alle drei Fälle. Ein abgelehnter Verbindungsversuch sieht ganz anders aus als ein 404, und ein 401 sagt dir, dass der Server in Ordnung ist und ein Token erwartet.
Es wird nie ein Tool aufgerufen. Geprüft wird die darunterliegende Ebene — Verbindung, Handshake, Bereitstellung —, die funktionieren muss, bevor ein Agent überhaupt etwas aufrufen kann. Ob ein Tool seine Eingaben validiert oder das richtige Ergebnis liefert, sagt dieser Test nicht. Für die Tool-Schemas selbst nutze den MCP Inspector; ob du einen Agenten überhaupt darauf richten solltest, beantwortet der Security Scanner.
Eine grüne Checkliste sagt dir, dass die Technik funktioniert. Einem potenziellen Kunden sagt sie gar nichts — er kann keinen Handshake lesen, und eine Liste von Tool-Namen ist keine Demo. Genau dafür ist MCP Showcase da: Richte es auf dieselbe URL, und du bekommst eine teilbare Playground-Seite, auf der jeder die Tools im Browser ausprobieren kann, mit generierter Dokumentation pro Tool und fertigen Einrichtungs-Snippets für den eigenen Client.