Was ist ein MCP-Server? Model Context Protocol erklärt
Wie LLMs Werkzeuge bekommen – erklärt am eigenen MCP-Server für diesen Blog
Dieser Artikel ist Teil des KI-Agenten Guides – dem kuratierten Lernpfad zu KI-Agenten.
Ein großes Sprachmodell ist im Kern ein Textgenerator: Es sagt das nächste Wort voraus. Beeindruckend – aber es kann von sich aus nichts in der echten Welt anfassen. Es kennt deine Dateien nicht, kann keine Datenbank abfragen und nichts veröffentlichen. Genau hier setzt das Model Context Protocol (MCP) an.
Das Problem: das LLM ist eingesperrt
Solange ein LLM nur im Chatfenster sitzt, ist es ein kluger Gesprächspartner ohne Hände. Sobald es aber wirklich nützlich werden soll – Code in deinem Repo ändern, einen Server-Status abfragen, einen Blog-Artikel anlegen – braucht es eine Brücke zu echten Werkzeugen. Früher hat jeder Anbieter diese Brücke selbst und inkompatibel gebaut. MCP standardisiert sie.
MCP: der USB-Standard für KI-Werkzeuge
Die treffendste Analogie: MCP ist für KI-Tools das, was USB für Peripherie ist. Statt für jede Kombination aus LLM-Client und Werkzeug einen eigenen Adapter zu bauen, sprechen beide ein gemeinsames Protokoll. Ein MCP-Server stellt Fähigkeiten bereit; ein MCP-Client (z. B. Claude Desktop, Claude Code oder LibreChat) nutzt sie. Jeder Server funktioniert mit jedem Client.
Der Ablauf ist simpel: Der Client fragt den Server „welche Werkzeuge hast du?“, der Server antwortet mit einer Liste samt Beschreibung. Das LLM entscheidet dann selbst, wann es welches Werkzeug aufruft – und der Server führt es aus.
Die drei Bausteine: Tools, Resources, Prompts
- Tools sind Aktionen, die das LLM auslösen kann – Funktionen mit Parametern („lege einen Artikel an“, „frage die Klick-Statistik ab“). Das ist der wichtigste und häufigste Baustein.
- Resources sind Daten zum Lesen – Dateien, Datenbank-Einträge, API-Antworten, die das Modell als Kontext bekommt.
- Prompts sind vorgefertigte Vorlagen, die ein Client als fertige Befehle anbieten kann.
Konkret: mein MCP-Server für devmaker.net
Das ist keine Theorie – dieser Blog wird genau so betrieben. Ich habe einen MCP-Server gebaut, der die Wagtail/Django-Website hinter devmaker.net steuert. Seine Tools heißen z. B. write_article, set_streamfield_content, generate_ai_image oder publish_page. Als Client hängt ein LLM davor: Ich sage „leg den Artikel an und setz die Tags“, das Modell wählt die passenden Tools und ruft sie auf – der Server macht die eigentliche Arbeit in der Datenbank.
Ein minimaler Server mit FastMCP (Python) zeigt, wie wenig dazu nötig ist:
from fastmcp import FastMCP
mcp = FastMCP("mein-server")
@mcp.tool()
def serverzeit() -> str:
"""Gibt die aktuelle Serverzeit als ISO-String zurück."""
from datetime import datetime
return datetime.now().isoformat()
if __name__ == "__main__":
mcp.run()Der Docstring ist kein Beiwerk: Er ist die Beschreibung, anhand derer das LLM entscheidet, ob es das Tool aufruft. Gute Beschreibungen sind bei MCP die halbe Miete.
So ein Server braucht kaum Ressourcen – mein devmaker-MCP-Server läuft als schlanker Dienst auf demselben sparsamen Mini-PC, der auch den Rest meines Homelabs trägt:
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
Wann lohnt sich ein eigener MCP-Server?
Immer dann, wenn du ein LLM wiederkehrend mit deinem eigenen System arbeiten lassen willst: deine API, deine Datenbank, dein Homelab, dein Tooling. Geht es nur um eine einmalige Frage, ist ein MCP-Server overkill. Soll das Modell aber zuverlässig und wiederholbar konkrete Aktionen ausführen, ist ein sauber definierter MCP-Server der robustere Weg als jedes Copy-Paste in den Chat.
Was ich weggelassen habe
Für den Überblick bewusst ausgespart: das Transport-Thema (stdio vs. HTTP/SSE) und die Tücken beim Remote-Betrieb – dazu gibt es einen eigenen Artikel: MCP-Server überlebt keinen Deploy: SSE vs. Streamable-HTTP. Ebenso Authentifizierung und Fehlerbehandlung, die ein produktiver Server braucht.
Fazit & Ausblick
Ein MCP-Server ist die standardisierte Brücke, über die ein LLM von der reinen Textmaschine zum Akteur wird, der echte Werkzeuge bedient. Das Konzept ist überschaubar – Tools, Resources, Prompts – und mit FastMCP in wenigen Zeilen angefangen. Wenn du jetzt selbst einen bauen willst, geht es hier Schritt für Schritt weiter: MCP-Server in Python entwickeln: Vom leeren Repo zum ersten Tool.
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.