Etappe 06 / 06 · Der gemeinsame Einstieg
Diese Website ist jetzt auch ihre eigene MCP-Adresse
Im Browser eine Website, im KI-Client eine MCP App: Hinter derselben Adresse mussten zwei unterschiedliche Aufrufe zuverlässig zusammenfinden.
01
Die Idee
Die Homepage ließ sich bereits als MCP App öffnen – zunächst über eine zusätzliche Adresse mit einem technischen Unterpfad. Verständlicher ist es, wenn du einfach die Homepage-Adresse verbinden kannst.
Das Ziel für den 15. Oktober lautete deshalb: christian-igel.tech bleibt die normale Website und wird zugleich der Einstieg für den MCP-Client.
02
Wo es hakte
Ein Browser erwartet eine lesbare Seite. Ein MCP-Client stellt Anfragen an Werkzeuge und App-Inhalte. Der Server muss beide Aufrufarten an derselben Adresse richtig behandeln.
Der erste veröffentlichte Versuch lieferte für die neue Route einen 404-Fehler. Die Website war damit noch kein erfolgreich geprüfter MCP-Einstieg. Außerdem musste die Anmeldung genau zu dieser Adresse passen; eine neue URL darf keine alten Zugriffsregeln aushebeln.
03
Wie es weiterging
Die fehlerhafte Fassung wurde zurückgeschaltet und die Zuordnung im Webserver korrigiert. Danach wurden die Website, der öffentliche MCP-Einstieg und die App-Inhalte über die tatsächliche Domain geprüft.
Normale Browseraufrufe liefern die Homepage. MCP-Anfragen gehen an die bestehende Anwendung. Die frühere MCP-Adresse bleibt für vorhandene Verbindungen nutzbar. Gäste erhalten die öffentlichen Inhalte; geschützte Bearbeitung folgt weiterhin den bestehenden Rechten.
04
Was heute davon bleibt
Für neue Verbindungen kannst du dieselbe Adresse verwenden, die du auch im Browser aufrufst: https://christian-igel.tech/. Die Website und ihre MCP-Ansicht entstehen aus derselben Homepage-Quelle.
Der Rückschritt war dabei Teil der Lösung: Erst die Prüfung an der echten Adresse machte den Routingfehler sichtbar. Eine erfolgreiche Veröffentlichung bedeutet deshalb mehr als eine neu hochgeladene Datei – der tatsächliche Weg des Anwenders muss funktionieren.