MCP-Server erstellen: Der Einstieg

Einen MCP-Server erstellst du mit einem offiziellen SDK — etwa dem Python- oder TypeScript-SDK des MCP-Projekts. Du definierst Tools als Funktionen, startest den Server lokal über stdio und registrierst ihn in deinem Agent, zum Beispiel mit claude mcp add in Claude Code. Ein minimaler Server ist überschaubar; komplex wird erst der Betrieb im Netz.

Was baue ich da eigentlich?

Ein MCP-Server ist ein Programm, das einem KI-Agenten Fähigkeiten anbietet — meist in Form von Tools, also aufrufbaren Funktionen. Das Model Context Protocol (MCP) regelt, wie Agent und Server miteinander sprechen; die Grundlagen erklärt Was ist ein MCP-Server? Dein Job als Entwickler ist angenehm klein: Du schreibst die Funktionen, das SDK übernimmt das Protokoll.

Ehrliche Vorbemerkung: Bevor du baust, schau in die MCP-Server-Liste und das offizielle Verzeichnis — für viele Dienste existiert schon ein guter Server. Selbst bauen lohnt sich vor allem für interne Systeme, die sonst niemand anbindet.

Welches SDK nehme ich?

Das MCP-Projekt pflegt offizielle SDKs in mehreren Sprachen, darunter Python und TypeScript — die vollständige Liste steht auf modelcontextprotocol.io. Für den Einstieg hat sich das Python-SDK bewährt: Sein FastMCP-Interface macht aus einer dekorierten Funktion automatisch ein vollständiges Tool samt Beschreibung für den Agent.

So sieht ein minimaler Server in Python aus (sinngemäß, die aktuelle Syntax steht in der offiziellen Doku):

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("rechner")

@mcp.tool()
def addiere(a: int, b: int) -> int:
    """Addiert zwei Zahlen."""
    return a + b

if __name__ == "__main__":
    mcp.run()

Die Docstrings sind keine Deko: Der Agent liest sie, um zu entscheiden, wann er das Tool aufruft — dieselbe Logik wie bei der description eines Skills.

Wie teste ich den Server lokal?

Der übliche Weg in drei Schritten:

1. Inspector starten: Der MCP Inspector aus dem offiziellen Projekt startet deinen Server und zeigt dir interaktiv, welche Tools er anbietet und was sie zurückgeben — ohne dass ein Agent beteiligt ist.
2. Im Agent registrieren: In Claude Code genügt ein Terminal-Befehl wie claude mcp add rechner -- python server.py. Andere Clients wie Claude Desktop oder Cursor nutzen eine Konfigurationsdatei.
3. Auslösen: Stelle dem Agent eine Aufgabe, die zum Tool passt („addiere 17 und 25 mit dem rechner-Tool") und prüfe, ob er es aufruft.

Läuft das, hast du das Grundgerüst — alles Weitere ist normales Software-Handwerk: Fehlerbehandlung, saubere Rückgaben, Tests.

Ein Hinweis aus der Praxis: Teste nicht nur, ob der Agent das Tool aufruft, sondern auch wann. Formuliere mehrere Aufgaben, die zum Tool passen sollten, und ein paar, die es nicht tun — löst der Agent falsch aus, ist meist die Tool-Beschreibung zu vage oder zu breit. Dieses Nachschärfen kostet oft mehr Zeit als der Code selbst.

Wo wird es anspruchsvoll?

Drei Themen trennen den Wochenend-Server vom Produktiv-Einsatz:

• Rechte und Sicherheit: Dein Server führt aus, was der Agent anfragt. Begrenze, was Tools dürfen — Whitelists statt freier Pfade, Lesezugriff statt Schreibzugriff, wo es reicht.
• Entfernter Betrieb: Sobald der Server nicht mehr lokal läuft, brauchst du HTTP-Transport und Authentifizierung. Das MCP-Projekt spezifiziert dafür OAuth-basierte Verfahren — deutlich mehr Aufwand als stdio.
• Tool-Design: Wenige, klar beschriebene Tools schlagen viele generische. Jedes Tool belegt Kontext im Agent; ein Server mit dreißig halbgaren Tools macht den Agent schlechter, nicht besser.

Die maßgebliche Quelle für alle Details ist die offizielle Dokumentation unter modelcontextprotocol.io — sie enthält Tutorials für Server, Clients und die Spezifikation selbst.

Muss es überhaupt ein Server sein?

Wenn dein Ziel ist, dem Agent eine Arbeitsweise beizubringen statt einen Zugang zu verschaffen, bist du mit einem Agent Skill schneller am Ziel — einer Markdown-Datei ohne laufenden Prozess. Die Abgrenzung erklärt Skills vs. Plugins vs. MCP.