MCP ist endlich in Go angekommen: wie Sie einen produktionsreifen Agenten-Server bauen, ohne in selbstgeschriebenem Glue-Code zu versinken

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres für B2B-Kunden im DACH-Raum. Der kritischste Moment entsteht in solchen Projekten meist nicht bei der Modellauswahl, sondern dann, wenn nach wenigen Wochen fünf Werkzeuge, mehrere Authentifizierungsmuster und uneinheitliche Fehlermeldungen mehr selbstgeschriebenen Glue-Code erzeugen als eigentliche Fachlogik.

Dass MCP nun auch in Go angekommen ist, ist deshalb praktisch relevant. Nicht, weil dadurch jede Agenten-Architektur automatisch einfacher wird, sondern weil ein standardisierter Server-Rand die Zahl privater Adapter und Sonderwege reduziert. Wenn Sie MCP als kontrollierte Schnittstelle zwischen Modell und Infrastruktur behandeln, erhalten Sie eine sauberere Grundlage für Bereitstellung, Sicherheitsprüfung und Nachvollziehbarkeit im Produktivbetrieb.

Warum Integrationen von Agenten meist vor dem Modell scheitern

Viele Teams konzentrieren sich zuerst auf Prompting, Auswertung und Orchestrierung. In produktiven Systemen liegen die Ausfälle jedoch häufig im Integrationsbereich: Werkzeuge liefern uneinheitliche Datenstrukturen zurück, Wiederholungsversuche erzeugen doppelte Seiteneffekte, Datenbankrechte sind zu weit gefasst, und Protokolle reichen für eine Ursachenanalyse nicht aus. Sobald ein Agent SQL, interne APIs und Automatisierungsabläufe ansprechen darf, betreiben Sie kein einfaches Chat-System mehr, sondern eine verteilte Anwendung mit klaren Anforderungen an Berechtigungen und Überwachung.

Das typische Fehlmuster

In der Praxis sehe ich oft denselben Ablauf: Zuerst entstehen zwei oder drei Hilfsfunktionen, dann ein eigenes JSON-Format, danach manuelle Parameterprüfung und schließlich eine weitere Hülle, damit dasselbe Werkzeug sowohl für Claude als auch für einen internen Ausführungsdienst verwendbar bleibt. Das Ergebnis funktioniert zunächst, aber das Team besitzt nun ein privates Protokoll, das bei jedem weiteren Werkzeug mitgepflegt werden muss.

MCP hilft an dieser Stelle, weil es eine feste Schnittstelle für Werkzeuge und Ressourcen vorgibt. Anthropic beschreibt den Model Context Protocol in der eigenen Dokumentation als standardisierten Weg, Modelle mit Werkzeugen und Datenquellen zu verbinden: https://docs.anthropic.com/. Für den Produktivbetrieb bedeutet das vor allem weniger Protokollvielfalt im eigenen System.

Was ein produktionsreifer MCP-Server aus meiner Sicht braucht

Ein Server, der auf list_tools antwortet, ist noch kein tragfähiger Produktionsbaustein. Ein erprobter MCP-Dienst muss testbar, beobachtbar, klar begrenzt und einfach zu betreiben sein. Ich achte mindestens auf die folgenden Schichten:

Fehlen zwei oder drei dieser Punkte, sprechen Sie noch nicht über eine belastbare Agenten-Plattform. Dann handelt es sich eher um eine frühe Integrationsschicht, und genau so sollte sie auch bewertet werden.

Warum Go hier sachlich gut passt

Go ist in diesem Zusammenhang aus nüchternen Betriebsgründen sinnvoll: kleines Binärformat, überschaubares Abhängigkeitsverhalten und ein gutes Modell für parallele Verarbeitung. Wenn auf Kundenseite bereits n8n, Postgres, interne APIs und selbst betriebene Dienste vorhanden sind, ist ein kompakter Go-Server oft leichter bereitzustellen als eine weitere umfangreiche Laufzeitumgebung nur für einige wenige Werkzeuge.

Ein minimales Grundgerüst ohne unnötige Magie

Mein Grundsatz lautet: ein Werkzeug, ein klarer Handler, validierte Eingaben und ein eng begrenzter Seiteneffekt. Selbst wenn Sie in der Entwicklung mit Claude Code oder dem Anthropic SDK arbeiten, sollte die Server-Schnittstelle selbst langweilig und vorhersehbar bleiben.

export DATABASE_URL="postgres://app:***@db.internal:5432/app"
export MCP_ALLOWED_TABLES="customers,orders"
export TOOL_TIMEOUT_SECONDS="8"

gitleaks detect --source . --no-banner
semgrep --config p/owasp-top-ten .
bandit -r scripts/

go test ./...
go build -o mcp-server ./cmd/server
./mcp-server

Ich führe gitleaks und semgrep nicht nur wegen des eigentlichen Servers aus. Risiken entstehen oft in Shell-Skripten, CI-Konfigurationen, Hilfsprogrammen für Migrationen oder kleinen Automatisierungen rund um den Dienst. Wenn im Repository zusätzlich Python-Hilfsskripte liegen, ist bandit ebenfalls sinnvoll.

version: "3.9"
services:
  mcp-server:
    image: ghcr.io/example/mcp-server:latest
    environment:
      DATABASE_URL: ${DATABASE_URL}
      MCP_ALLOWED_TABLES: customers,orders
      TOOL_TIMEOUT_SECONDS: "8"
    read_only: true
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "/app/mcp-server", "healthcheck"]
      interval: 30s
      timeout: 3s
      retries: 3

Entscheidend ist die Rechtevergabe. Ein MCP-Server sollte keine uneingeschränkten Datenbankrechte erhalten. Wenn ein Werkzeug lediglich Kunden- und Auftragsdaten lesen muss, reicht eine lesende Datenbankrolle. Genau diese Art technischer Begrenzung ist auch aus Sicht von DSGVO, ISO 27001 und BSI Grundschutz sinnvoll, weil sie Datenzugriffe nachvollziehbar und aufgabengerecht hält. In mehreren Agenten-Projekten, die ich geprüft habe, waren überzogene Datenbankrechte der häufigste Risikofaktor vor der Freigabe.

Wo Teams beim Werkzeug-Layer typischerweise falsch abbiegen

1. Ein universeller Werkzeug-Ausführer

Die Idee eines einzigen Ausführers für alles wirkt effizient, führt aber meist zu unscharfen Verträgen. Sechs schmale Werkzeuge mit klaren Schemata sind besser prüfbar als ein einziges Großwerkzeug mit vielen Betriebsarten.

2. Orchestrierung und Richtlinien werden vermischt

n8n eignet sich gut für Orchestrierung und Integrationsabläufe. Richtlinien wie erlaubte Tabellen, zulässige Zielsysteme oder Zeitlimits gehören jedoch in den MCP-Server und seine Konfiguration. Sonst verlieren Sie einen klaren Kontrollpunkt.

3. Zu wenig Protokollierung

Es reicht nicht zu wissen, dass ein Werkzeug aufgerufen wurde. Sie benötigen Aufruferidentität, validierte Eingaben, Ergebnisdaten, Dauer, Fehlercode und eine Ablaufkennung, um den Aufruf in den Gesamtprozess einordnen zu können.

4. Nur der Idealfall wird getestet

Prüfen Sie Zeitüberschreitungen, Abbrüche, fehlerhafte Argumente, leere Ergebnismengen und doppelte Aufrufe nach Teilfehlern. Diese Fälle entscheiden über die Stabilität im Betrieb, nicht die gelungene Vorführung in der Entwicklungsumgebung.

Externe Orientierung, die sich in der Praxis lohnt

OWASP Top 10 2021 nennt Broken Access Control und Insecure Design als zentrale Anwendungsrisiken: https://owasp.org/www-project-top-ten/. Genau dort sitzt der MCP-Server architektonisch. Er ist der Punkt, an dem Berechtigungen, Validierung und Fehlervalidität entweder diszipliniert umgesetzt oder unnötig offen gelassen werden.

Auch der OpenAI Cookbook zeigt wiederholt, wie wertvoll schema-definierte Werkzeugaufrufe für verlässliche Programmlogik sind: https://cookbook.openai.com/. Selbst wenn Sie primär mit Claude arbeiten, bleibt die Schlussfolgerung dieselbe: Standardisierte Werkzeugverträge reduzieren den Betriebsaufwand und erleichtern spätere Modellwechsel.

FAQ

Ist MCP nur mit Claude sinnvoll?

Nein. Der Hauptnutzen liegt im standardisierten Vertrag zwischen Modell und Werkzeugen. Auch in Umgebungen mit mehreren Modellen reduziert das die Zahl individueller Adapter.

Sollten Sie alle internen Funktionen als MCP-Werkzeuge bereitstellen?

Nein. Beginnen Sie mit wenigen, fachlich wertvollen Werkzeugen und engen Rechten. Ein zu breiter Werkzeugkatalog vergrößert die Fehlerfläche und erschwert die Steuerung.

Lässt sich Supabase hinter einem MCP-Server betreiben?

Ja, sofern Sie Dienstrollen klar von agentenseitigen Zugriffsrechten trennen und Lese- sowie Schreibgrenzen sauber definieren. MCP ersetzt keine Daten-Governance, verbessert aber die Ausführungsgrenze.

Wo sollten Geheimnisse abgelegt werden?

Nicht in Prompts und nicht fest im Werkzeugcode. Ich lagere sie in der Regel in Doppler oder einem vergleichbaren Geheimnis-Manager und injiziere nur die jeweils benötigten Umgebungswerte.

Wann ist MCP zu viel Aufwand?

Wenn Sie nur ein lokales Skript und eine externe API anbinden, kann ein eigener MCP-Server überdimensioniert sein. Sobald mehrere Werkzeuge, unterschiedliche Rechte und Prüfanforderungen dazukommen, steigt der Nutzen deutlich.

An welcher Stelle verlieren Sie in Ihrer aktuellen LLM-Architektur am meisten Zeit: bei Werkzeugverträgen, Berechtigungen, Nachvollziehbarkeit oder der Fehleranalyse nach der Freigabe? Genau diese Engstelle entscheidet meist darüber, ob aus einem Agenten-System ein tragfähiges Produkt wird.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.