Kapitel 2: Minimal MCP (Stdio)

Der einfachste Weg, einen MCP-Server zu betreiben, ist über Stdio (Standard Input/Output). In diesem Kapitel lernen wir, wie diese Kommunikation funktioniert und wie man einen minimalen Server startet.

Warum Stdio?

Man könnte denken, dass MCP immer über das Internet (HTTP/Websockets) laufen muss. Aber für lokale Anwendungen (z. B. eine IDE, die auf Dateien zugreift) ist Stdio viel effizienter:

Keine Ports: Man muss keine TCP-Ports verwalten oder Firewalls konfigurieren.
Sicherheit: Nur der Prozess, der den Server gestartet hat, kann mit ihm reden.
Lebenszyklus: Wenn die Client-App (z. B. der mcp-tester) beendet wird, stirbt auch der MCP-Server-Prozess automatisch.

SSE (Server-Sent Events): Der Web-Standard

Für Anwendungen, die über das Netzwerk kommunizieren (z. B. ein Server in der Cloud), nutzt MCP meist SSE. Hierbei wird ein HTTP-Server gestartet:

Remote-Zugriff: Der Server kann von überall erreichbar sein.
Persistenz: Läuft unabhängig vom Client-Lebenszyklus.
Komplexität: Erfordert Port-Management und Authentifizierung.

Das Prinzip: JSON-RPC über Pipes oder HTTP

Die Kommunikation findet über einen Datenstrom statt. Der Client sendet ein JSON-Objekt an stdin des Servers, und der Server antwortet über stdout.

Ein typischer Handshake sieht so aus:

Client -> Server (initialize): "Hallo, ich bin Client X und unterstütze Version Y."
Server -> Client: "Hallo! Ich bin Server Z und habe folgende Fähigkeiten (Tools, Resources)."
Client -> Server (initialized): "Okay, fangen wir an!"

Ein minimaler Server in Go

Hier ist das absolute Minimum, um einen MCP-Server zu starten:

package main

import (
    "github.com/modelcontextprotocol/go-sdk/mcp"
    "github.com/modelcontextprotocol/go-sdk/server"
)

func main() {
    // 1. Server-Instanz erstellen
    s := server.NewServer("mini-server", "1.0.0")

    // 2. Über Stdio bereitstellen
    if err := server.ServeStdio(s); err != nil {
        panic(err)
    }
}

Verbindung prüfen: Der Ping-Mechanismus (Neu 2025-11)

In produktiven Umgebungen, besonders über das Netzwerk (SSE), ist es wichtig zu wissen, ob der Partner (Server oder Client) noch erreichbar ist. Hierfür bietet MCP den Ping-Mechanismus.

Das Prinzip

Request: Der Client (oder Server) sendet einen ping Request.
Response: Der Empfänger antwortet sofort mit einem leeren Ergebnis {}.
Timeout: Erfolgt keine Antwort innerhalb einer definierten Zeit, gilt die Verbindung als "tot" (stale) und sollte neu aufgebaut werden.

Dies ist besonders bei SSE wichtig, um "Geisterverbindungen" zu vermeiden, bei denen der Client denkt, er sei noch verbunden, während der Server den Socket bereits geschlossen hat.

Den Server testen

Mit unserem mcp-tester können wir diesen Server sofort validieren:

# Falls die Binary 'mini-server' heißt:
./mcp-tester list --command "./mini-server"

Selbst wenn der Server noch keine Tools hat, wird der mcp-tester den Handshake erfolgreich durchführen und eine (leere) Liste zurückgeben. Damit hast du deinen ersten funktionierenden MCP-Kanal aufgebaut!

Jenseits von Stdio: Remote-Server (SSE)

Stdio ist perfekt für lokale Workflows, hat aber Grenzen. Wenn dein MCP-Server im Rechenzentrum laufen soll oder von vielen verschiedenen Clients gleichzeitig genutzt wird, kommt der SSE-Transport (Server-Sent Events) ins Spiel.

Warum ein externer Server?

Zentralisierung: Ein einziger MCP-Server kann die gesamte Belegschaft mit Tools versorgen (z. B. Zugriff auf das interne Wiki).
Ressourcen: Rechenintensive Tools (z. B. Video-Rendering oder große Datenbank-Abfragen) können auf starker Hardware laufen, während der Client (z. B. ein Laptop) schlank bleibt.
Cloud-Native: MCP-Server können als Container (Docker) in Kubernetes oder als Serverless-Funktionen betrieben werden.

Der mcp-tester ist bereits auf diese Welt vorbereitet. Statt eines Kommandos übergibst du einfach eine URL:

./mcp-tester list --url "https://mcp.meine-firma.de/sse"

← Inhaltsverzeichnis | Nächstes Kapitel: Tools →