Modellkontextprotokoll (MCP) und Anmerkungen zur Implementierung eines MCP-Servers in Go

Langartikel über MCP-Spezifikationen und Implementierung in Go

Inhaltsverzeichnis

Hier haben wir eine Beschreibung des Model Context Protocol (MCP), kurze Notizen zur Implementierung eines MCP-Servers in Go, einschließlich der Nachrichtenstruktur und Protokollspezifikationen.

Roboter und MCP

Model Context Protocol (MCP) – Überblick

Model Context Protocol (MCP) ist ein offener, standardisierter Rahmen (introduziert von Anthropic Ende 2024) zum Verbinden von KI-Sprachmodellen mit externen Datenquellen, Tools und Systemen. Sein Ziel ist es, das „N×M-Integrationsproblem“ zu lösen, indem eine universelle Schnittstelle für Aufgaben wie das Lesen von Dateien, das Ausführen von Funktionen (Tools) und die Verwendung von kontextbezogenen Aufforderungen in verschiedenen Anwendungen bereitgestellt wird. MCP ist kein proprietäres oder internes Protokoll; es ist ein offener Standard mit einer offiziellen Spezifikation und einer Open-Source-Referenzimplementierung. Tatsächlich kündigten große KI-Anbieter (einschließlich OpenAI und Google DeepMind) nach der Einführung Unterstützung für MCP an, was unterstreicht, dass es als allgemein akzeptierter Standard und nicht als lösungspezifische Lösung gedacht ist.

MCP-Zweck und Architektur

MCP zielt darauf ab, die Art und Weise zu standardisieren, wie Anwendungen Kontext an LLMs bereitstellen – die oft verwendete Analogie ist „ein USB-C-Anschluss für KI-Anwendungen“. Durch die Definition eines gemeinsamen Protokolls ermöglicht MCP KI-Assistenten und Tools, nahtlos mit Datenbanken, Dateisystemen, APIs und anderen Ressourcen zu interagieren, ohne dass benutzerdefinierte Einmalintegrationen erforderlich sind. Dies hilft Sprachmodellen, relevantere und aktuellere Antworten zu generieren, indem ihnen sicherer Zugriff auf die benötigten Daten gewährt wird.

Architektur: MCP folgt einem Client-Server-Modell mit klarer Rollentrennung:

  • MCP-Host: Die übergeordnete Anwendung (z. B. ein Chat-Client oder eine IDE), die Verbindungen verwaltet. Sie enthält einen oder mehrere MCP-Clients (Verbinder).
  • MCP-Client: Eine Verbinderinstanz (innerhalb des Hosts), die eine 1:1-Sitzung mit einem MCP-Server herstellt. Der Client verwaltet den Sitzungslebenszyklus, leitet Nachrichten weiter und setzt Benutzerberechtigungen oder Sicherheitsrichtlinien durch.
  • MCP-Server: Ein leichtgewichtiger Dienst, der bestimmte Fähigkeiten (Zugriff auf bestimmte Daten oder Funktionen) über das MCP-Protokoll bereitstellt. Jeder Server kann eine Datenquelle (Dateien, DB, API usw.) oder ein Tool umschließen. Mehrere Server können parallel laufen und jeweils unterschiedliche Integrationen bereitstellen.
  • Datenquellen/Dienste: Die tatsächlichen Ressourcen, mit denen Server interagieren – dies kann lokale Dateien und Datenbanken oder Remote-Dienste (Web-APIs, SaaS-Anwendungen usw.) umfassen. Der MCP-Server wirkt als Adapter für diese Ressourcen und stellt sicher, dass das LLM nur über das standardisierte Protokoll auf Daten zugreift.

Dieses Design ist von dem Language Server Protocol (LSP) aus der IDE-Welt inspiriert. Genau wie LSP es jeder Editor ermöglicht, jede Programmiersprache über ein gemeinsames Protokoll zu unterstützen, ermöglicht MCP es jeder KI-Anwendung, jede Daten-/Tool-Integration zu verbinden, die MCP spricht. Diese Entkopplung bedeutet, dass KI-Tool-Entwickler einen MCP-Server einmal schreiben können und ihn mit vielen KI-Clients verwenden können, und KI-Anwendungsentwickler neue Integrationen einfach hinzufügen können, indem sie einen MCP-Server einstecken, ohne benutzerdefinierten Integrationscode zu vermeiden.

Protokoll und Nachrichtenstruktur

Kommunikation: Die MCP-Kommunikation basiert auf persistenten, zustandsbehafteten Sitzungen mit JSON-RPC 2.0-Nachrichten. Alle Anfragen und Antworten entsprechen dem JSON-RPC-Format (mit einem Feld "jsonrpc": "2.0", Methodenamen, Parametern und korrelierenden IDs). Jede Seite – Client oder Server – kann Anfragen oder Benachrichtigungen senden und ermöglicht eine bidirektionale Interaktion. Eine MCP-Sitzung beginnt typischerweise mit einem Handshake:

  • Der Client initiiert mit einer initialize-Anfrage, schlägt eine Protokollversion vor und gibt seine Fähigkeiten an (welche Funktionen er unterstützt). Zum Beispiel könnte der Client angeben, dass er servergetriebene „Sampling“-Anfragen verarbeiten oder bestimmte Wurzeln für den Dateizugriff bereitstellen kann. Der Server antwortet mit seiner eigenen unterstützten Protokollversion und Fähigkeiten und legt fest, welche Funktionen für diese Sitzung aktiviert sind (MCP verwendet ein Fähigkeitsverhandlungssystem ähnlich wie optionale Funktionen in LSP). Wenn kritische Fähigkeiten oder Versionen unvereinbar sind, wird die Verbindung sanft abgebrochen.
  • Nach der Vereinbarung sendet der Client eine initialized-Benachrichtigung, um die Bereitschaft zu markieren. Danach können normale Operationen fortgesetzt werden. Die Sitzung bleibt für einen kontinuierlichen Austausch von JSON-RPC-Nachrichten geöffnet, bis eine Seite einen Shutdown auslöst.

Transporte: MCP schreibt keinen einzigen Transport vor – es funktioniert über jeden Kanal, der JSON-Text übertragen kann. Häufig wird ein MCP-Server als Unterprozess ausgeführt und kommuniziert über STDIO (stdin/stdout-Pipes) für lokale Integrationen. Dies ist analog dazu, wie Sprachserver betrieben werden, und ist praktisch für lokale Tools (der Host kann den Serverprozess starten und Nachrichten weiterleiten). Alternativ können MCP-Server als unabhängige Dienste ausgeführt werden, die über HTTP zugänglich sind. Die MCP-Spezifikation definiert einen Streaming-HTTP-Transport, bei dem der Server ein einzelnes HTTP-Endpoint für JSON-RPC-Aufrufe bereitstellt (Clients senden POST-Anfragen, und der Server kann antworten oder Ergebnisse über Server-Sent Events für lang laufende Operationen streamen). In jedem Fall sind die Nachrichten UTF-8-JSON-Zeilen, und das Protokoll unterstützt Streaming-Antworten und serverinitiierte Nachrichten (der HTTP+SSE-Ansatz ermöglicht es dem Server, Benachrichtigungen oder teilweise Ergebnisse asynchron zu senden). Sicherheitsrichtlinien empfehlen, dass lokale Server an localhost gebunden werden und Origin-Header validieren, um unerwünschten Remote-Zugriff zu verhindern, und dass eine ordnungsgemäße Authentifizierung (z. B. Tokens oder OAuth-Flows) für Remote-Server verwendet wird.

Nachrichtenformat: MCP nutzt die drei Nachrichtentypen von JSON-RPC: Anfragen, Antworten und Benachrichtigungen. Eine Anfrage enthält eine id, eine method-Zeichenfolge und (optional) params (in der Regel ein JSON-Objekt mit Argumenten). Der Empfänger muss mit einer entsprechenden Antwort (mit übereinstimmender id) antworten, die entweder ein result oder ein error-Objekt enthält. Benachrichtigungen sind wie Einweg-Nachrichten mit einer method und Parametern, aber ohne id (daher erhalten sie keine Antwort). MCP legt einige Regeln über das Basis-JSON-RPC fest (z. B. muss id nicht null sein und während einer Sitzung nicht wiederverwendet werden), um Klarheit zu wahren.

Sitzung und Zustand: Die Verbindung gilt als zustandsbehaftet – der Client und der Server halten Kontext über die Fähigkeiten des anderen und möglicherweise einige Sitzungszustände (wie Abonnements für Änderungen, laufende Operationen usw.) bereit. Es gibt auch definierte Verfahren für einen sanften Shutdown (z. B. kann ein Client eine Shutdown-Anfrage senden oder einfach den Transport schließen; Server sollten die Bereinigung durchführen, und beide Seiten implementieren Timeouts für hängende Operationen). Die Fehlerbehandlung folgt den JSON-RPC-Konventionen (Fehlerantworten haben einen Code und eine Nachricht), und die Spezifikation definiert Standard-Fehlercodes für bestimmte Bedingungen (z. B. Zugriff verweigert, Tool nicht gefunden usw.). MCP bietet auch Dienstprogramme für übergreifende Anliegen: Zum Beispiel gibt es eingebaute Benachrichtigungen für Fortschrittsaktualisierungen, die Absage einer lang laufenden Anfrage (CancelledNotification), Protokollierungs-/Debug-Nachrichten und Konfigurationsänderungen. Diese helfen bei der Verwaltung langer oder komplexer Interaktionen (der Client kann einen laufenden Tool-Aufruf absagen, oder der Server kann Warnungen an den Client protokollieren usw.).

MCP-Funktionen und -Operationen

Sobald eine MCP-Sitzung initialisiert ist, ermöglicht sie den Austausch von Kontext und Befehlen auf strukturierte Weise. Die Kern-MCP-Serverseitigen Funktionen sind Prompts, Ressourcen und Tools (die der Server jeweils während der Initialisierung angibt, falls er sie unterstützt):

  • Prompts: Vordefinierte Prompt-Vorlagen oder Anweisungen, die der Server dem Client bereitstellen kann. Diese sind typischerweise benutzerausgelöste Hilfsmittel (der Benutzer wählt explizit einen Prompt aus, um ihn in das Gespräch einzufügen, z. B. über einen Slash-Befehl in der UI). MCP bietet Methoden, um verfügbare Prompts aufzulisten und den Inhalt eines Prompts abzurufen. Zum Beispiel kann ein Client prompts/list aufrufen, um eine Liste von Prompt-Vorlagen zu erhalten (jede mit einem Namen, einer Beschreibung und optionalen Parametern). Um einen Prompt abzurufen, verwendet der Client prompts/get mit dem Namen des Prompts und beliebigen Argumentwerten; der Server gibt dann den Prompt-Inhalt zurück (oft als eine oder mehrere Nachrichten, die der Client in den Kontext des LLM einfügt). Prompts ermöglichen die Wiederverwendung komplexer Anweisungen oder Arbeitsabläufe (z. B. „Code-Review-Vorlage“), die ein Benutzer bei Bedarf aufrufen kann. Server geben eine prompts-Fähigkeit an (mit optionalen Unterfunktionen wie listChanged, um den Client zu benachrichtigen, falls sich die Menge der Prompts dynamisch ändert).

  • Ressourcen: Strukturierte Daten oder Inhalte, die dem Modell Kontext bieten. Ressourcen sind typischerweise Dinge wie Dateien, Dokumente, Datenbankeinträge – Informationen, die ein KI-Assistent lesen oder referenzieren könnte. MCP standardisiert, wie Ressourcen identifiziert und übertragen werden: Jede Ressource hat einen URI-Identifikator (z. B. file:///path/to/file.txt oder ein benutzerdefiniertes Schema für Datenbanken). Clients können abfragen, welche Ressourcen verfügbar sind, über resources/list (der Server kann ein Verzeichnisbaum, eine Liste der letzten Dokumente usw. anzeigen). Die Antwort des Servers enthält Metadaten für jede Ressource (URI, Name, Typ, Beschreibung usw.). Dann kann der Client den Inhalt einer bestimmten Ressource mit resources/read anfordern, indem er den URI übergibt. Der Server antwortet mit dem Ressourceninhalt, der Text (für Dateien) oder strukturierte Daten sein kann (MCP unterstützt verschiedene Inhaltsarten wie Text, JSON, Binärdateien usw. mit MIME-Typen). Es gibt auch Unterstützung für Ressourcen-Vorlagen (parameterisierte Ressourcen, die durch Vorlagen-URIs identifiziert werden, die der Client ausfüllen kann, z. B. eine Datenbankabfrage, bei der der Benutzer einen Parameter angibt). Wenn aktiviert, können Server Benachrichtigungen senden, wenn sich Ressourcen ändern (z. B. notifications/resources/updated) oder Clients können sich für Änderungen an einer Ressource anmelden (resources/subscribe). In der MCP-Architektur sind Ressourcen anwendungsgesteuerte Kontexte: Die Host-Anwendung (Client) entscheidet typischerweise, welche Ressourceninhalte tatsächlich in den Prompt des Modells eingespeist werden (oft nach Benutzerbestätigung oder basierend auf dem UI-Kontext).

  • Tools: Ausführbare Funktionen oder Aktionen, die der Server für das Modell zum Aufruf bereitstellt. Tools stellen Operationen dar, die die KI durchführen kann – z. B. einen externen API aufrufen, eine Datenbankabfrage ausführen, eine E-Mail senden oder eine Datei ändern. Jedes Tool hat einen Namen und ein JSON-Schema für seine Eingabe- (und optional Ausgabe-) Parameter, sodass das KI-Modell (oder der Client) weiß, welche Argumente es erwartet. Tools sind typischerweise modellgesteuert: Die Idee ist, dass das Sprachmodell (Agent) entscheidet, ob und wann es ein Tool während eines Gesprächs verwenden soll, um die Anforderung des Benutzers zu erfüllen. Allerdings kann ein menschlicher Benutzer oder die Host-Anwendung die Tool-Nutzung vermitteln (z. B. eine Bestätigung durch Klick erfordern). Die Verwendung von Tools in MCP umfasst zwei Hauptoperationen: Auflisten und Aufrufen. Ein Client kann tools/list aufrufen, um die verfügbaren Tools und deren Schemas zu erhalten. Zum Beispiel könnte ein Server ein Tool get_weather mit einer Beschreibung und einem Eingabeschema auflisten, das einen „Orts“-String erfordert. Dann, wenn das Modell entscheidet, ein Tool zu verwenden (oder der Benutzer es aufruft), sendet der Client eine tools/call-Anfrage mit dem Namen des Tools und einem JSON-Objekt mit Argumenten. Der Server führt die Funktion aus und gibt das Ergebnis zurück, typischerweise als ein result.content-Feld, das Text oder strukturierte Daten enthalten kann (MCP unterstützt die Rückgabe mehrerer Inhaltsanteile, z. B. Text plus ein Bild usw., obwohl Text häufig ist). Ein einfaches Beispiel: Der Aufruf eines get_weather-Tools könnte einen Text-Payload wie „Aktuelles Wetter in New York: 72°F, teilweise bewölkt“ als Inhalt für den Assistenten zurückgeben, um ihn zu präsentieren. Tools können auch Fehler anzeigen (die Antwort enthält eine isError-Flagge oder ein Fehlerobjekt, falls etwas schiefgelaufen ist). Wie bei Prompts und Ressourcen kann die tools-Fähigkeit eine optionale listChanged-Flagge haben, um zu benachrichtigen, wenn sich die verfügbaren Tools zur Laufzeit ändern (z. B. ein dynamisches Plugin geladen/entladen wird).

Zusätzlich zu den oben genannten serverseitigen Funktionen definiert MCP auch clientseitige Funktionen (Fähigkeiten, die Server nutzen können, falls der Client sie unterstützt). Dazu gehören Sampling, Roots und Elicitation:

  • Sampling ermöglicht es einem Server, den Client (und dessen LLM) aufzufordern, eine Modellinferenz innerhalb der Sitzung durchzuführen. Zum Beispiel könnte ein Server einen LLM-Aufruf (vielleicht, um eine Kette von Gedanken fortzusetzen oder etwas zusammenzufassen) durch Senden einer Anfrage wie sampling/request initiieren – der Client würde dann das Modell abfragen und das Ergebnis zurückgeben. Dies ermöglicht agentische Verhaltensweisen, bei denen der Server die KI anweisen kann, bei seinen eigenen Unteraufgaben zu helfen. (Alle solchen Aktionen unterliegen der Benutzergenehmigung und Richtlinien – z. B. könnte ein Benutzer zustimmen müssen, damit ein Server das Modell für zusätzliche Abfragen auslöst.)

  • Roots ermöglicht es dem Server, nach bestimmten erlaubten Dateisystem- oder URI-Wurzeln zu fragen oder darin zu operieren. Der Client kann eine Liste von „Root“-Verzeichnissen/URIs bereitstellen, auf die der Server zugreifen darf, über roots/list. Dies ist ein Sicherheitsmerkmal, das sicherstellt, dass der Server die Grenzen kennt (z. B. welche Verzeichnisbäume er lesen kann).

  • Elicitation ermöglicht es dem Server, den Client aufzufordern, weitere Informationen vom Benutzer zu erhalten, falls erforderlich. Zum Beispiel, wenn ein Tool ein fehlendes Stück Information benötigt, das nicht bereitgestellt wurde, kann der Server eine Elicitation-Anfrage senden, die der Client (UI) in eine Benutzeraufforderung übersetzt („Die X-Integration benötigt Ihren API-Schlüssel, bitte geben Sie ihn ein“). Auf diese Weise kann der Server interaktiv Eingaben über den Client sammeln.

Diese Funktionen sind alle optional und werden im Voraus ausgehandelt. Ein zentrales Designmerkmal von MCP ist, dass die Fähigkeitsaushandlung während der Initialisierung erfolgt – der Client und der Server geben an, welche der oben genannten Funktionen sie unterstützen, sodass beide Seiten wissen, welche Operationen in der Sitzung verfügbar sind. Zum Beispiel, wenn ein Server die tools-Fähigkeit nicht angibt, wird der Client keine tools/list- oder tools/call-Operationen mit ihm versuchen. Diese Erweiterbarkeit bedeutet, dass MCP mit neuen Funktionen im Laufe der Zeit weiterentwickelt werden kann, während die Abwärtskompatibilität gewahrt bleibt (nicht unterstützte Methoden werden einfach nicht verwendet, wenn sie nicht ausgehandelt wurden).

Implementierungen, SDKs und der Aufbau eines MCP-Servers (insbesondere in Go)

Offizielle Spezifikation & Dokumentation: Die autoritative MCP-Spezifikation ist öffentlich verfügbar und umfasst ein formales Schema aller Nachrichtentypen. Sie wird auf der Model Context Protocol-Website und auf GitHub gepflegt. Die Spezifikation ist in einer TypeScript-Schema-Datei (mit einem entsprechenden JSON-Schema) definiert, die alle Anfragen, Antworten und Strukturen präzise dokumentiert. Die Dokumentationsseite (modelcontextprotocol.io) bietet Leitfäden, eine FAQ und detaillierte Aufschlüsselungen jeder Funktion und jedes Nachrichtentyps sowie ein „MCP Inspector“-Tool für interaktive Fehlersuche. Obwohl MCP (noch) kein IETF- oder ISO-Standard ist, wird es als offener Standard mit Community-Input entwickelt und verwendet vertraute RFC-2119-Terminologie für Anforderungen. Es ist ein sich entwickelndes Protokoll (Versionen sind datiert; z. B. ist 18.06.2025 eine aktuelle Überarbeitung), mit einer Versionierungsrichtlinie zur Verwaltung von Änderungen.

Referenzimplementierungen: Anthropic hat mehrere MCP-Server-Connectoren und SDKs bei der Einführung von MCP open-sourced. Es gibt eine GitHub-Organisation modelcontextprotocol, die die Spezifikation und mehrere Repositories hostet. Besonders hervorzuheben ist ein „servers“-Repository, das eine Sammlung von vorgefertigten MCP-Server-Implementierungen für häufige Dienste und Datenquellen enthält. Diese dienen als Referenzintegrationen und können oft sofort verwendet oder als Vorlagen für benutzerdefinierte Server genutzt werden. Beispielsweise enthält das offizielle Repository Server für Google Drive (Dateizugriff und -suche in Google Drive), Slack (Arbeitsplatznachrichten und Kanalinhalte), GitHub/Git (Code-Repository-Kontext), PostgreSQL (schreibgeschützte Datenbankabfragen mit Schema-Informationen), Google Maps (Standort- und Routen-API), Puppeteer (Web-Browsing und -Scraping) und viele mehr. Durch die Installation oder Ausführung dieser Server kann eine KI-Anwendung wie Claude oder Cursor sofort diese Integration nutzen. Es gibt auch einen communitygetriebenen MCP Registrierungsdienst (open-source in Go) zum Indexieren verfügbarer Server, und viele Drittanbieter-Beiträge erweitern MCP auf verschiedene Domänen (von CRMs bis zu Blockchain-Daten).

SDKs und Bibliotheken: Um den Aufbau eigener MCP-Server/Clients zu erleichtern, gibt es offizielle SDKs in mehreren Sprachen. Stand 2025 stellt das Projekt SDKs für TypeScript/Node, Python, Java (und Kotlin), C# (entwickelt mit Microsoft), Ruby (mit Shopify), Swift und andere bereit. Diese Bibliotheken übernehmen die Protokoll-„Plumbing“ – z. B. das Verwalten des JSON-RPC-Transports, das Implementieren des Spezifikationsschemas und das Bereitstellen von Hilfs-APIs zum Registrieren von Tools oder zum Bereitstellen von Ressourcen. Beispielsweise kann das TypeScript-SDK verwendet werden, um schnell einen Server in Node.js zu schreiben, und das Python-SDK ermöglicht die Integration von MCP in Python-Anwendungen. Der SDK-Ansatz bedeutet, dass Entwickler keine JSON-RPC-Nachrichten manuell konstruieren oder den gesamten Zustandsautomaten implementieren müssen; stattdessen rufen sie High-Level-Methoden auf, um Anfragen zu senden oder Fähigkeiten zu veröffentlichen.

Go-Implementierung: Go hat sich aufgrund seiner Leistungsfähigkeit und seiner Stärken in der Parallelverarbeitung (gut für die Verarbeitung mehrerer gleichzeitiger Anfragen) als beliebte Wahl für MCP-Server etabliert. Ein offizielles Go-SDK ist nun verfügbar und wird in Zusammenarbeit mit dem Go-Team bei Google gepflegt. (Dies wurde im April 2025 angekündigt, und die erste stabile Version ist für August 2025 geplant.) Das Go-SDK bietet ein Paket mcp zum Erstellen von Clients/Servern und einen jsonschema-Helper für Tool-Schemas. Mit dem Go-SDK können Entwickler einen MCP-Server mit nur wenigen Aufrufen erstellen. Beispielsweise können Sie einen neuen Server mit einem Namen und einer Version instanziieren und dann Tools über AddTool hinzufügen, indem Sie eine Tool-Definition (Name, Beschreibung, Eingabeschema) zusammen mit einer Go-Handler-Funktion bereitstellen, die ausgeführt wird, wenn dieses Tool aufgerufen wird. Das SDK kümmert sich darum, das Tool im Protokoll bereitzustellen (es in tools/list bekannt zu machen und tools/call-Anfragen zu verarbeiten). Ähnlich könnten Sie Ressourcen oder Prompts mit analogen APIs bereitstellen. Schließlich führen Sie den Server aus – beispielsweise wird server.Run(ctx, mcp.NewStdioTransport()) die Verarbeitung von JSON-RPC-Nachrichten über stdio starten, bis der Client sich abmeldet. Auf der Client-Seite kann das Go-SDK einen Unterprozess starten und sich über mcp.NewCommandTransport(exec.Command("myserver")) verbinden, und der Client kann dann session.CallTool(ctx, params) aufrufen, um ein Tool aufzurufen und das Ergebnis einfach im Go-Code zu erhalten.

Beispiel: Die offizielle Go-SDK-Dokumentation zeigt einen einfachen „Greeter“-Server. Der Server registriert ein Tool „greet“, das einen Namen entgegennimmt und eine Begrüßungszeichenfolge zurückgibt. Der Client ruft dann dieses Tool per Namen auf und druckt das Ergebnis aus. Dies veranschaulicht das Grundmuster: Tool definieren -> Client ruft Tool auf -> Ergebnis erhalten. Unter der Haube entspricht dies JSON-RPC-Nachrichten ("method": "tools/call", params: {"name": "greet", ...} und die Antwort enthält result.content mit Text) wie in der MCP-Spezifikation definiert.

Bevor das offizielle Go-SDK veröffentlicht wurde, erstellte die Community eigene Go-Bibliotheken. Besonders hervorzuheben ist das Projekt mcp-go von Ed Zynda (mark3labs/mcp-go), das weit verbreitet war und das Design des offiziellen SDKs beeinflusste. Eine weitere Bibliothek, mcp-golang von Metoro, bot eine Go-Implementierung und API (der Dev-Community-Blogbeitrag von Elton Minetto verwendet diese Bibliothek Anfang 2025). Diese Community-SDKs ermöglichten es Go-Entwicklern, frühzeitig mit MCP zu experimentieren – beispielsweise zeigt ein Tutorial, wie man einen MCP-Server erstellt, der brasilianische Postleitzahlen (CEP) durch Bereitstellen eines „zipcode“-Tools über die Metoro mcp-golang-Bibliothek sucht. In diesem Beispiel registriert der Go-Server eine Funktion, die eine externe API aufruft, um eine Adresse aus einer Postleitzahl zu finden, und gibt das Ergebnis als Text zurück – wodurch ein KI-Assistent die Adressinformationen bei Bedarf über MCP abrufen kann. Eine weitere Anleitung demonstriert das Einbetten einer benutzerdefinierten In-Memory-Datenbank (DiceDB) als MCP-Server unter Verwendung des mark3labs mcp-go-SDKs: Es definiert ein ping-Tool zum Überprüfen der DB-Konnektivität und andere Tools für Datenoperationen. Diese Beispiele zeigen, wie einfach es sein kann, eine MCP-Integration zu erstellen: Die meisten Codezeilen sind nur die Geschäftslogik (API-Aufrufe, DB-Abfragen usw.), während das SDK die JSON-RPC-Verkabelung übernimmt.

Aufbau eines MCP-Servers in Go (Tutorial-Highlights)

Um den Prozess zu umreißen, hier ein typischer Ablauf mit dem Go SDK oder einer ähnlichen Bibliothek:

  1. Server einrichten: Initialisieren Sie eine neue Serverinstanz mit grundlegenden Informationen (Name, Version und deklarieren Sie unterstützte Fähigkeiten). Beispielsweise in Go: server := mcp.NewServer("MyServer", "1.0.0", nil) erstellt einen Server, der (standardmäßig) Kernprotokollfunktionen unterstützt. Sie können bestimmte Fähigkeiten wie Prompts/Ressourcen/Tools über Optionen aktivieren oder einfach durch Registrieren dieser Funktionen (Hinzufügen eines Tools oder einer Ressource impliziert diese Fähigkeit).

  2. Funktionen registrieren: Fügen Sie die Funktionen hinzu, die Sie bereitstellen möchten:

    • Wenn Tools bereitgestellt werden, definieren Sie das Schema und den Handler für jedes Tool. Beispielsweise mit dem Go-SDKs AddTool: Geben Sie eine mcp.Tool{Name: "...", Description: "..."} und eine Handler-Funktion an, die die Aufrufanfrage entgegennimmt und ein Ergebnis zurückgibt (das Text oder andere Inhalte enthalten kann). Das SDK generiert automatisch ein JSON-Schema für Eingaben aus den Parametertypen Ihres Handlers (oder Sie können es angeben).
    • Wenn Ressourcen bereitgestellt werden, könnten Sie eine API zum Registrieren von Ressourcenlisten oder einen Callback zum Lesen von Inhalten verwenden. In der Python-SDK beispielsweise können Sie eine ResourceProvider-Unterklasse erstellen; in Go ist das SDK noch in Entwicklung, aber Sie würden wahrscheinlich Funktionen zum Auflisten und Lesen von Ressourcen bereitstellen. Jede Ressource sollte eine stabile URI haben.
    • Wenn Prompts bereitgestellt werden, definieren Sie Prompt-Vorlagen (können statische Dateien oder Zeichenfolgen sein) und registrieren Sie sie mit Namen und optional Parametern. Der Server wird sie bekannt machen, damit der Client sie abrufen und den Benutzern anzeigen kann.

  3. Transport implementieren: Entscheiden Sie, wie der Server ausgeführt werden soll. Der einfachste für den lokalen Gebrauch ist stdio – z. B. server.Run(ctx, mcp.NewStdioTransport()) in Go startet das Lesen von JSON-RPC von stdin. Wenn Ihr Server vernetzt sein soll, könnten Sie einen HTTP-Handler implementieren, der das Go-SDK verwendet, um JSON-RPC über HTTP zu akzeptieren (das offizielle Go-SDK könnte bald einen Helper für den HTTP/SSE-Transport enthalten).

  4. Client-Tests: Sie können den Server mit einem MCP-kompatiblen Client testen. Beispielsweise unterstützt Anthropics Claude 2 (Claude für Desktop) das Laden lokaler MCP-Server; Sie würden Claude so konfigurieren, dass er Ihr Server-Binary startet oder sich damit verbindet. Es gibt auch ein CLI-Tool namens mcp-cli und den MCP Inspector GUI zum Testen von Servern ohne einen vollständigen KI-Client – diese Tools senden MCP-Anfragen an Ihren Server und zeigen die Ergebnisse an, was die Fehlersuche erleichtert.

  5. Sicherheit & Berechtigungen: Beim Aufbau eines Servers sollten Sie Authentifizierung und Scoping berücksichtigen. Für lokale Server könnte der Host ihn mit bestimmten OS-Berechtigungen ausführen oder API-Schlüssel über Umgebungsvariablen bereitstellen. Für Remote-Server verwenden Sie Auth-Header oder OAuth-Flows. MCP enthält eine Autorisierungsspezifikation für HTTP-Transporte (der Server kann ein Token verlangen und der Client kann es senden). Stellen Sie immer sicher, dass der Server nur auf Daten zugreift, die der Benutzer erlaubt hat (z. B. die vom Client bereitgestellten Stammverzeichnisse respektieren und Daten nicht anderswo weitergeben) – die MCP-Richtlinien betonen Benutzerzustimmung, Datenschutz und Toolsicherheit als grundlegend.

Zusammenfassend ist MCP ein formelles, aber flexibles Protokoll zur Verbindung von LLMs mit der Außenwelt. Es ist keine interne API, die an ein Unternehmen gebunden ist, sondern ein offener Standard mit wachsender Akzeptanz und einem reichen Ökosystem von Integrationen. Das Protokoll definiert klare Nachrichtenstrukturen (basierend auf JSON-RPC) und einen Satz von Operationen (Methoden für Prompts, Tools, Ressourcen usw.), die jeder konforme Client/Server implementieren kann. Offizielle Dokumentation und Spezifikationen sind verfügbar, und zahlreiche SDKs, Bibliotheken und Beispielserver (einschließlich in Go) machen die Implementierung einfacher. Durch die Verwendung von MCP können Entwickler KI-gestützte Anwendungen erstellen, die vorhandene Daten und Dienste sicher nutzen, ohne die Integrationslogik für jedes neue Modell oder jede neue Datenbank neu zu erfinden.