PullMD Teil 12: Spec-Compliant ist nicht genug – Einfach erklärt
Version 2.0 meines Markdown-Service war draußen, mit echten Nutzer-Konten. Und die brauchte ich als Grundlage für den nächsten Schritt: OAuth. Das ist ein standardisiertes Anmeldeverfahren, im Grunde dasselbe wie “mit Google anmelden”. Damit sollte Claude im Webbrowser meinen Server direkt nutzen können, ohne dass ich Inhalte selbst rüberkopieren muss.
Claude Code und ich haben diese Anmeldung auf einem eigenen Entwicklungszweig gebaut, getestet und auf meinen Ubuntu-Entwicklungsserver hochgeladen. Dann wollte ich den Server in claude.ai eintragen.
Die Fehlermeldung, die keine war
claude.ai-Web, Einstellungen, “Add custom connector”. Adresse eingegeben. Erwartung: ein Browserfenster öffnet sich, ich bestätige den Zugriff, fertig.
Stattdessen kam: “Couldn’t reach the MCP server”. MCP steht für Model Context Protocol, die Schnittstelle, über die Claude mit externen Werkzeugen redet. Die Meldung hieß also sinngemäß: “Ich komme nicht an deinen Server ran.” Mehr nicht. Kein Detail, kein Fehlercode, kein Hinweis worauf.
Was nicht passierte, war das eigentliche Rätsel
Ich habe in die Server-Logs geschaut, die Protokolle, die mein Server über jeden Zugriff führt. Da steht normalerweise jede Anfrage drin, jeder Versuch, jeder Klopfer an der Tür.
Da stand: nichts. Kein einziger Zugriff während all der Versuche. Niemand klopfte auch nur an die Tür.
Zur Kontrolle habe ich von verschiedenen Stellen aus selbst angeklopft: vom eigenen Netzwerk, vom Handy, von einem fremden Rechner irgendwo im Internet. Überall kam ich problemlos durch. Das Problem lag nicht auf meiner Seite des Kabels.
Alle Pflichtprüfungen bestanden
Die Anmeldung folgt einem öffentlichen Regelwerk, einer sogenannten “Spec”. Das ist eine Art Bauplan, an den sich alle halten, damit verschiedene Systeme zusammenarbeiten können. Wer spec-konform ist, hat sich an alle Regeln gehalten.
Wir haben alle acht relevanten Prüfungen einzeln durchgespielt, von einem dritten Standort aus. Jeder einzelne Endpunkt, also jede Stelle, an der mein Server antwortet, gab genau das zurück, was die Spec vorschreibt. Acht von acht grün.
Ab da haben wir aufgehört, im eigenen Code nach Fehlern zu suchen. Etwas anderes musste falsch sein.
Jemand anderes hatte das Problem schon
Eine Suche auf GitHub später: ein öffentliches Ticket im Anthropic-Repo, eröffnet einen Tag vor meinem Reddit-Post. Ein Startup namens Helferlain, eine Online-Plattform, deren gesamtes Geschäftsmodell darauf aufbaut, dass Nutzer ihren Claude-Pro-Account via MCP anbinden können. Launch-Termin innerhalb von 30 Tagen, zahlende Beta-Kunden, die auf die Integration warten.
Die Symptome: exakt identisch. Server konform, Logs leer, “Couldn’t reach the MCP server”. Der Entwickler hatte sogar live mitprotokolliert, während er es versuchte: null eingehende Anfragen. Seine Diagnose: Anthropic startet den Anmelde-Vorgang gar nicht erst. Irgendetwas auf deren Seite weist den Server ab, bevor überhaupt ein Verbindungsversuch rausgeht.
Jemand anderes hatte schon eine Woche mit demselben Problem gerungen, mit deutlich höherem Druck.
Datenpunkt hinzufügen
Ich habe in diesem Ticket einen Kommentar hinterlassen, kurz und sachlich:
“Same symptom on a different server — adding a data point. Setup: Custom MCP server, OAuth 2.1 spec-compliant. […] Server-side evidence: Traefik access log shows ZERO requests from claudeai-proxy during repeated ‘Add custom connector’ attempts.” —
syswave-dev(Issue-Kommentar)“Gleiches Symptom auf einem anderen Server – füge einen Datenpunkt hinzu. Eigener MCP-Server, spec-konform. […] Beleg auf meiner Seite: das Server-Protokoll zeigt null Anfragen vom Claude-Proxy bei wiederholten Verbindungsversuchen.” –
syswave-dev
Dazu habe ich die Referenz-ID geschrieben, die claude.ai mir nach dem Fehlschlag angezeigt hatte. Eine Art Quittungsnummer, falls Anthropic in den eigenen Protokollen nachschauen will, was bei diesem Versuch passiert ist.
Ein zweiter Server als Beweis
Am nächsten Morgen habe ich mit Claude Code einen zweiten, unabhängigen Server gebaut. Komplett anderer Unterbau: andere Programmiersprache, andere Datenbank. Aber dieselben Spec-Regeln, dieselbe Sorgfalt.
Diesen zweiten Server wollte ich ohnehin bauen. Und er war zugleich das beste Argument im Ticket: wenn zwei völlig unabhängige Server auf verschiedenen Grundlagen exakt gleich scheitern, kann der Fehler nicht an meinem Code liegen.
Zweiter Kommentar im Ticket:
“Built a second independent OAuth-MCP server (different codebase, different stack — TypeScript/PostgreSQL instead of JavaScript/SQLite). Same exhaustive spec compliance, same symptom on ‘Add custom connector’ in claude.ai web UI. […] Two independent codebases failing identically rules out implementation-specific bugs on the user side.” —
syswave-dev(Issue-Kommentar)“Einen zweiten unabhängigen OAuth-MCP-Server gebaut (andere Codebase, andere Werkzeuge – TypeScript/PostgreSQL statt JavaScript/SQLite). Gleiche Spec-Sorgfalt, gleiches Symptom in der claude.ai-Web-Oberfläche. […] Zwei unabhängige Server, die identisch fehlschlagen, schließen Bugs auf meiner Seite aus.” –
syswave-dev
Neue Quittungsnummer, selber Befund. Damit war die Frage “was habe ich falsch gemacht?” beantwortet: nichts.
Die Auflösung
An dem Morgen, an dem ich diesen Artikel eigentlich schreiben wollte, hatte das Ticket eine neue Antwort. Von einem Mitarbeiter bei Anthropic. Das Ticket wurde geschlossen:
“#256 captured an
x-deny-reason: host_not_allowedheader from Anthropic’s egress proxy, which is a strong signal that the underlying cause is a host allowlist on our side rather than anything in your server.” — @localden (Anthropic, Issue-Close)“In einem anderen Ticket hat jemand einen Header von Anthropics ausgehendem Proxy abgefangen, der ‘host_not_allowed’ sagt – ‘dieser Host steht nicht auf der erlaubten Liste’. Das deutet stark darauf hin, dass die Ursache eine Freigabe-Liste auf unserer Seite ist, nicht etwas in deinem Server.” – @localden (Anthropic)
In Klartext: Anthropic führt eine Liste erlaubter Server-Adressen. Wer nicht draufsteht, kommt nicht durch, und zwar so früh, dass der eigene Server gar nichts davon mitbekommt. Kein Klopfen, kein Türsummen, einfach Stille.
Es war kein Bug in meinem Code. Es war eine Tür, die ich von meiner Seite aus nicht öffnen kann.
Das Ticket wurde mit einem größeren zusammengelegt, das weitere betroffene Server und Quittungsnummern sammelt. Die OAuth-Version meines Tools liegt fertig im Regal. Freigeben kann ich sie nur noch nicht: wann die Liste aufgeht, liegt nicht in meiner Hand. Im Reddit-Thread vom 28. April habe ich den Stand kurz festgehalten, für alle, die denselben Weg gehen wollten.
Was ich nicht in der Hand hatte
Über die letzten Teile hinweg zog sich ein roter Faden: Dinge, die anders liefen als gedacht.
In Teil 9 war es die Resonanz auf Reddit, mit der ich nicht gerechnet hatte. Mehr Aufmerksamkeit, mehr Nachfragen, mehr Anregungen als geplant.
In Teil 11 war es ein Umweg in der Architektur, den ich nicht eingeplant hatte. Anfragen von außen haben die Reihenfolge meiner Aufgaben verändert.
Und hier, in Teil 12, ist es eine Hürde, die ich gar nicht beeinflussen kann: eine Liste auf der anderen Seite, auf der mein Server noch nicht steht. Bei den ersten beiden hätte ich anders planen oder priorisieren können. Hier nicht: der Code ist fertig und spec-konform, der Rest liegt bei jemand anderem.
Wer auf der Infrastruktur eines anderen aufbaut, muss solche Wartezeiten akzeptieren. Das ist keine Beschwerde, sondern gehört einfach dazu. Ich habe deshalb dokumentiert statt mich zu ärgern: was gebaut wurde, was geprüft wurde, welche Quittungsnummern ich habe, was die Diskussion ergeben hat. Wer dasselbe Problem hat, findet das beim Suchen.
Teil 12 von 15 der PullMD Serie.
← PullMD Teil 11: Multi-User-Pivot | PullMD Teil 13: Eine alte Regel →