MCP-Server gelten als Infrastruktur für große Häuser: Anbindungen an Datenbanken, Ticketsysteme, Firmen-Wikis, alles hinter einer Firewall. Ein Erfahrungsbericht aus der Indie-Web-Szene zeigt, dass es auch kleiner geht: Dort reicht ein einzelner Server im Go-Backend einer privaten Website, um ein abfotografiertes Kinoticket in einen Filmtagebuch-Eintrag zu verwandeln. Henrique Dias beschreibt, wie er diese Anbindung für seine Website Eagle umgesetzt hat: Foto vom Ticket machen, Bewertung dazutippen, den Rest erledigt der AI-Agent. Spannend ist dabei nicht der Aufwand, sondern die Frage, die der Bericht nebenbei beantwortet: Was muss ein Dienst bereitstellen, damit ein Agent ihn zuverlässig bedienen kann?
Man kann sich einen MCP-Server wie einen Schalter mit Formularen vorstellen. Der Agent ist der Bote, der mit einem Foto in der Hand ankommt und ein Formular ausgefüllt haben möchte; der Server ist die Person hinter dem Schalter, die Angaben entgegennimmt und in die Akte überträgt. Das Formular selbst ist das JSON Schema, und die kleinen Randnotizen darauf — in welchem Format etwa ein Ort anzugeben ist — sind die Feldbeschreibungen. Ist das Formular schwammig, rät der Bote; nimmt der Schalter alles an, landet Unsinn in der Akte. Es geht also um drei Ebenen: Zutritt, Formular, Aktenlage.
Was der MCP-Server im Go-Backend leistet
Eagle ist das Go-Backend der persönlichen Website des Autors. Dort liegen unter anderem die Logs: Filme, Serien, besuchte Live-Auftritte und gelesene Bücher, gespeichert als Array in einer JSON-Datei. Gepflegt wurden diese Einträge bisher über einen Web-Editor, der im Kern aus einem <textarea> ohne Syntaxhervorhebung besteht. Für schnelle Korrekturen unterwegs reichte das, zu Hause wurde lokal editiert und anschließend gepusht. Der Reiz der neuen Variante lag in dieser Lücke: Das Bearbeiten einer Datendatei auf dem Handy ist mühsam, ein Foto und ein Satz Bewertung sind es nicht.
Der Antrieb war Neugier. Der Entwickler wollte ausprobieren, wie MCP-Server funktionieren und wie AI-Agenten mit APIs interagieren, und suchte dafür ein Problem, das ihm selbst nützt. Lernen mit einem echten Ergebnis bleibt besser haften als eine Spielwiese ohne Zweck. Deshalb blieb der Umfang bewusst klein: Einträge lesen, hinzufügen und bearbeiten. Reisen und die Kaffee-Seite der Website wurden ausgespart, weil sie anders funktionieren und mit anderen Diensten synchronisieren. Wer Website-Logs per KI verwalten will, braucht also nicht die komplette Website als Schnittstelle, sondern einen klar abgegrenzten Ausschnitt.
Vom ersten Testendpunkt zur OAuth-2.1-Autorisierung
Für die Umsetzung griff der Autor zum offiziellen Go MCP SDK, nachdem er sich kurz durch die Dokumentation gelesen hatte. Der Einstieg war ein einzelner Suchendpunkt, noch ohne Authentifizierung, ausprobiert mit dem MCP Inspector. Das Werkzeug half, ein Gefühl dafür zu entwickeln, wie das JSON Schema mit der Oberfläche zusammenspielt und welche Rückmeldungen der Client erwartet. Erst danach ging es an den Zutritt.
Die MCP-Autorisierung ist OAuth 2.1 mit PKCE, was für dieses Projekt günstig war: Eagle implementiert bereits IndieAuth, das auf OAuth 2.0 mit PKCE basiert, sodass die meisten Bausteine schon standen. Nachzuholen waren die Feinheiten von OAuth 2.1 sowie ein eigener Scope, damit sich nachvollziehen lässt, welche Tokens ausgegeben wurden und was sie dürfen. Dazu kam die Discovery: Eagle lieferte bis dahin keine Metadaten für geschützte Ressourcen aus. Das bedeutete lediglich ein JSON mit drei Feldern, das das SDK bereits generiert. In der Analogie des Schalters ist das der Ausweis am Eingang — er regelt, wer überhaupt bis zum Formular durchkommt und was auf dem Stempel steht.
Warum CIMD statt Dynamic Client Registration den Ausschlag gab
Beim Login war zunächst unklar, welcher Mechanismus der richtige ist. Der MCP Inspector schlägt standardmäßig Dynamic Client Registration vor, die Eagle nicht unterstützte. Der Autor baute sogar eine zustandslose DCR-Variante, bis er las, dass seit der letzten Revision der MCP-Spezifikation Client ID Metadata Documents, kurz CIMD, der empfohlene Weg sind — und verwarf die DCR-Änderungen wieder. CIMD bedeutet: Die Client-ID ist eine URL, die ihre eigenen Metadaten hostet. Das deckt sich mit IndieAuth, und der Entwickler nennt es einen Full-Circle-Moment.
Ganz rund lief es trotzdem nicht. Claude erkannte CIMD weiterhin nicht, bis der Autor nach etwas Konfigurationsarbeit darauf stieß, dass der Metadatensatz den Wert token_endpoint_auth_methods_supported auf none setzen muss. Fehlt der Eintrag, geht der Server implizit davon aus, dass nur client_secret_basic unterstützt wird. Der größte Brocken war ohnehin die eigene IndieAuth-Bibliothek, in der die vollständige Redirect-URI-Discovery fehlte — ein seit Langem offener TODO-Kommentar, für den sich bisher kein Anwendungsfall ergeben hatte. Mit dieser Arbeit ist indielib@0.6.0 erschienen. Dass es in Claude erst einige Minuten später funktionierte, erklärt sich der Autor mit zwischengespeicherten Metadaten des Autorisierungsservers.
Strikte Tools und die Tücken von Go-Slices im JSON Schema
Bei den Werkzeugen entschied sich der Entwickler für eine strenge Variante. Wenn das Modell ein Ticketfoto liest, soll es scheitern, sobald etwas unklar ist oder eine Information fehlt — lieber eine Rückfrage als ein halb gefüllter Eintrag. Der MCP Inspector meldete daraufhin einige Probleme mit dem JSON Schema der Ein- und Ausgaben, obwohl das Schema für sich genommen gültig war. Die Ursache lag bei den Arrays: Ein Slice in Go kann nil sein, und in JSON wird daraus null, sofern leere Werte nicht explizit weggelassen werden. Das erzeugte Schema erlaubte damit null oder Array, was manche Clients nicht mögen.
Die Lösung bestand darin, die generierten Schemas im Code nachzubearbeiten, statt sich allein auf Struct-Tags zu verlassen. Das Entfernen des null-Falls steht noch auf der Liste, erwies sich aber als nützlicher Hebel, weil sich so zusätzliche Einschränkungen unterbringen ließen — etwa eine Bewertung als ganze Zahl zwischen 1 und 10. Wo sich ein Format nicht sauber in JSON Schema ausdrücken lässt, helfen die Feldbeschreibungen, zum Beispiel die Vorgabe Venue, City, CC für den Ort einer Aufführung. Das sind die Randnotizen auf dem Formular, ohne die der Bote raten müsste.
Wo das Konzept an seine Grenzen stößt: Identität, Kosten, Bearbeiten
Das Bearbeiten bestehender Einträge ist nicht der Hauptanwendungsfall, sollte aber verfügbar sein — und zeigte eine Schwäche. Die Logs liegen als Array in einer JSON-Datei, es gibt keine eindeutige Kennung pro Eintrag. Der Autor identifiziert einen Eintrag deshalb vorläufig über seine aktuellen Werte: bei Filmen Name und Datum, bei Serien zusätzlich die Staffel. Der Index im Array schied aus, weil parallele Änderungen die Reihenfolge verschieben könnten. IDs einzuführen hätte eine simple Datei mit Ballast überzogen. Zufrieden ist der Entwickler mit dieser Lösung nicht, hält die Alternativen aber für schlechter — und akzeptiert, dass ältere Einträge ohne Datumsangabe nicht mehr editierbar sind.
Auch die Lese-Werkzeuge haben eine offene Flanke: Sie geben immer alles zurück. Damit lassen sich bei unvorsichtiger Nutzung viele Tokens verbrauchen, was im Alltag mit einem Agenten ins Geld gehen kann. Datumsfilter wären eine naheliegende Verbesserung, verschieben aber Rechenlast auf die Eagle-Seite und sparen sie beim Modell. Für den Moment verzichtet der Autor darauf, weil er diese Abfragen selten erwartet. Das Muster dahinter ist typisch für kleine Projekte: Man baut die Funktion, die man braucht, und notiert den Rest.
Was das für den Alltag mit AI-Agenten bedeutet
Der MCP-Server ist im Kern eine API mit etwas Beiwerk. Authentifizierung nach OAuth, JSON Schemas, HTTP — alles Standard, keine Überraschungen. Der Lernertrag liegt bei der Frage, wie präzise ein Schema und seine Feldbeschreibungen sein müssen, damit ein Modell die richtigen Entscheidungen trifft. Ein Agent ist kein Hellseher; er arbeitet mit dem Formular, das du ihm hinlegst, und mit den Notizen, die darauf stehen. Wer dort schlampig arbeitet, bekommt schlampige Einträge.
CIMD, der seit der letzten Spezifikationsrevision empfohlene Weg für MCP-Clients, deckt sich weitgehend mit dem, was IndieAuth seit Jahren macht: eine URL als Identität, die ihre Metadaten selbst mitbringt. Wer bereits IndieAuth betreibt, hat für einen MCP-Server auf der eigenen Website einen erheblichen Vorsprung — nicht, weil es einfach wäre, sondern weil die Konzepte schon sitzen. OAuth 2.1 mit PKCE war für diesen Autor also kein Neuland, sondern eine Verlängerung bekannter Pfade.
Für dich als Leser heißt das: Einen MCP-Server in Go zu implementieren ist kein Großprojekt, wenn der Anwendungsfall klein genug gewählt ist und die Authentifizierung bereits existiert. Der Nutzen entsteht nicht durch die Technologie, sondern durch die Reibung, die sie entfernt: ein Ticket abzufotografieren, statt eine JSON-Datei auf dem Handy zu tippen. Wer den Schalter am Eingang, das Formular und die Aktenführung einmal sauber aufgesetzt hat, kann diesen Ausschnitt der Website per KI verwalten lassen — und merkt dabei sehr direkt, wie gut oder schlecht die eigene Schnittstelle beschrieben ist.
Quelle: hacdias.com
