Kostenloses Tool

MCP-OAuth-Checker

Finde heraus, was ein nicht authentifizierter Client beim Verbinden sieht — ob dein Server OAuth verlangt und ob er das so kommuniziert, dass Clients damit etwas anfangen können.

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
Server-URL einfügen

Kein Token nötig. Genau darum geht es: zu sehen, was ohne eines passiert.

play_circle
Wir verbinden uns anonym

Und folgen der Discovery, die dein Server bekannt gibt — genau so, wie ein Client es täte.

checklist
Sehen, was offenliegt

Ob OAuth verlangt wird, was ohne Autorisierung erreichbar ist und wie der Rest der Oberfläche bewertet wird.

Wie OAuth bei MCP aussieht

Ein Server, der Autorisierung verlangt, antwortet auf eine nicht authentifizierte Anfrage mit 401 und verweist auf die Metadaten seines Autorisierungsservers. Der Client findet von dort die Endpunkte, durchläuft den Flow und versucht es mit Token erneut. Genau dieser Discovery-Schritt ist der springende Punkt: Er macht das Verbinden mit einem geschützten Server zu etwas, das ein Client automatisch erledigen kann, statt zu etwas, das ein Nutzer von Hand konfigurieren muss.

Diese Seite verbindet sich völlig ohne Zugangsdaten mit deinem Server und meldet, was ein Client vorfinden würde.

Nichts zurückzugeben ist nicht dasselbe wie 401 zurückzugeben

Für einen Menschen sieht beides nach „keine Tools" aus, für einen Client sind es völlig verschiedene Dinge. Ein klares 401 mit Discovery-Metadaten sagt dem Client, was er als Nächstes tun soll. Eine leere Tool-Liste sagt ihm, dass der Server keine Tools hat — er hört also auf, und der Nutzer sieht einen Server, der sich einwandfrei verbunden hat und nichts tut. Wenn dein Server Autorisierung verlangt, sollte er das so sagen, dass Clients damit etwas anfangen können.

Was vor der Autorisierung erreichbar ist

Das lohnt sich bewusst zu prüfen. Schon die Namen der Tools beschreiben deine Interna — ein Server, der Tools anonym auflistet und nur die Aufrufe ablehnt, gibt also immer noch eine Landkarte von sich preis. Für einen öffentlichen, lesenden Server ist das in Ordnung; bei allem anderen gehört die Tool-Liste hinter dieselbe Schranke wie die Aufrufe.

Was hier nicht passiert

Es wird kein Autorisierungs-Flow abgeschlossen — dafür braucht es einen echten Nutzer und einen echten Zustimmungsdialog. Geprüft wird, was ein nicht authentifizierter Client sieht und wie dein Server seine Anforderungen signalisiert. Wenn du ein statisches Bearer-Token statt des Discovery-Flows nutzt, ist der Auth-Checker die passende Seite dafür.

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

Ein Server, der Autorisierung verlangt, antwortet auf eine nicht authentifizierte Anfrage mit 401 und verweist auf die Metadaten seines Autorisierungsservers. Der Client findet von dort die Endpunkte, durchläuft den Flow und versucht es mit Token erneut. Erst der Discovery-Schritt macht das automatisch, statt dass ein Nutzer es konfigurieren muss.

Wenn er OAuth verlangt, ist das meist richtig so — die Tool-Liste sollte vor der Autorisierung nicht lesbar sein. Entscheidend ist, ob er ein klares 401 mit Discovery-Metadaten zurückgibt oder einfach eine leere Liste, mit der ein Client nichts anfangen kann.

Nur wenn die Tools etwas tun. Für einen wirklich öffentlichen, lesenden Server ist das in Ordnung. Schreiben sie Daten, geben sie Geld aus oder erreichen sie interne Systeme, kann jeder, der die URL findet, sie auflisten und aufrufen.

Nein. Geprüft wird, was ein nicht authentifizierter Client sieht und wie dein Server seine Anforderungen signalisiert. Einen Autorisierungs-Flow abzuschließen braucht einen echten Nutzer — genau das passiert, wenn du den Server als Playground anbindest.

Das ist verbreitet und für Maschine-zu-Maschine-Nutzung praktikabel, verlagert die Schlüsselrotation aber auf dich. Der Auth-Checker deckt diesen Fall ab; auf dieser Seite geht es um den Discovery-basierten Flow.

Weitere kostenlose MCP-Tools