MCP Verwandelte Meine KI Vom Chatbot Zum Echten Agenten
Ich starrte eine volle halbe Minute auf meinen Bildschirm und war aufrichtig verwirrt.
Claude hatte gerade eine Notiz in meinem Obsidian-Vault erstellt — nicht weil ich Text kopiert und eingefügt hatte, nicht weil ich eine Zapier-Integration benutzte — sondern weil ich es darum bat. Auf normalem Deutsch. "Erstelle eine Notiz über French-Press-Kaffee." Und da war sie, in meinem Vault, als hätte ich sie selbst geschrieben.
Das war vor drei Wochen. Seitdem habe ich Claude mit meinem Aufgabenmanager, meinem Kalender, einem Web-Scraper, YouTube-Transkripten und — ich übertreibe nicht — Kali Linux verbunden. Meine KI kann jetzt für mich hacken. Na ja, irgendwie. Aber der Punkt steht: etwas Fundamentales hat sich verändert, und die meisten Entwickler, mit denen ich spreche, haben es noch nicht mitbekommen.
Die Veränderung hat einen Namen. Sie heißt MCP — das Model Context Protocol. Und sobald du verstehst, was es tut, wirst du erkennen, dass die Lücke zwischen "KI-Chatbot" und "KI-Agent" kein weit entferntes Forschungsproblem ist. Es ist eine Konfigurationsdatei.
Was ich nicht erwartet hatte: Das Schwierigste war nicht die Technologie. Das Schwierigste war, zu verlernen, wie ich über KI gedacht hatte.
Das Problem, Über Das Niemand Spricht
Ich habe mir kürzlich NetworkChucks Erklärung von MCP angesehen — ein 38-minütiges Deep-Dive, das bereits 1,2 Millionen Aufrufe überschritten hat — und etwas, das er früh im Video sagte, klickte bei mir auf eine Weise, die monatelange Dokumentationslektüre nicht geschafft hatte.
Er verglich LLMs mit Menschen. Bleib kurz dabei.
Wenn du oder ich ein Tool verwenden wollen — sagen wir ClickUp für das Aufgabenmanagement — interagieren wir über eine grafische Benutzeroberfläche. Schaltflächen, Menüs, Drag-and-Drop. Die GUI abstrahiert all die zugrunde liegende Komplexität weg. Wir müssen das Datenbankschema oder die API-Endpunkte nicht kennen. Wir klicken einfach.
LLMs hassen GUIs. Sie können technisch damit interagieren (Screenshot-basierte Agents existieren), aber es ist langsam, unzuverlässig und fühlt sich an, als würde man jemandem das Autofahren beibringen, indem man ihnen Fotos von Lenkrädern zeigt.
Also gib ihnen stattdessen APIs? Dafür sind APIs da — damit ein Programm programmatisch mit einem anderen sprechen kann. Und ja, das funktioniert. Aber hier ist der Haken, den Chuck perfekt auf den Punkt brachte: Jede API hat Hunderte von Endpunkten mit einzigartigen Authentifizierungsschemata, Parameterformaten und Antwortstrukturen. Die API von ClickUp allein ist riesig. Die von Obsidian auch. Genau wie GitHub. Genau wie jedes andere Tool, das du deiner KI geben möchtest.
Um ein LLM über rohe APIs mit nur fünf Tools zu verbinden, müsstest du für jedes benutzerdefinierte Integrationscode schreiben, für jedes Authentifizierung handhaben, für jedes Antworten parsen und dem LLM dann irgendwie beibringen, welche Endpunkte wann aufzurufen sind.
Ich habe das gemacht. Für ein Kundenprojekt letztes Jahr verbrachte ich zwei Wochen damit, eine benutzerdefinierte Tool-Calling-Schicht für GPT-4 zu bauen, die sich mit drei internen APIs verband. Zwei Wochen. Drei Tools.
MCP verändert diese Gleichung vollständig.
Was MCP Wirklich Ist (Ohne Den Hype)
Das Model Context Protocol ist im Kern eine standardisierte Schnittstelle zwischen LLMs und externen Tools. Anthropic hat es erstellt, aber es ist zu einem Industriestandard geworden, der von OpenAI, Google und praktisch jedem KI-Tooling-Unternehmen übernommen wurde.
Stell es dir wie USB-C für KI-Tools vor. Vor USB-C hatte jedes Gerät seinen eigenen proprietären Anschluss. Man brauchte eine Schublade voller Kabel. USB-C sagte: "Hier ist ein Standard. Alle verwenden das." MCP tut dasselbe für die LLM-zu-Tool-Kommunikation.
Hier ist die Architektur in einfachen Worten:
LLM (Claude, GPT, Llama)
↕ spricht MCP-Protokoll
MCP Server (läuft lokal oder remote)
↕ kümmert sich um all die unordentlichen API-Dinge
Externes Tool (Obsidian, ClickUp, GitHub, etc.)
Der MCP-Server sitzt zwischen deiner KI und den Tools, die sie benötigt. Er verwaltet Authentifizierung, API-Aufrufe, das Parsen von Antworten — alles. Das LLM muss nichts über REST-Endpunkte oder OAuth-Token wissen. Es sieht nur eine Liste verfügbarer "Tools", die in normaler Sprache beschrieben sind:
create_note— Erstelle eine neue Notiz im Vaultsearch_vault— Suche nach Inhalten in allen Notizenappend_content— Füge Inhalte zu einer bestehenden Notiz hinzu
Das LLM wählt das richtige Tool, übergibt die Parameter und erhält strukturierte Ergebnisse zurück. Das war's. Kein benutzerdefinierter Code. Kein API-Gerangel.
Aber hier ist der Teil, der mich aufhorchen ließ — und das verbindet sich mit etwas viel Größerem.
Vom Chatbot Zum Agenten: Die Drei Ebenen
Während ich MCP-Server einrichtete, stieß ich auf Jeff Sus Erklärung von KI-Agenten — ein Video, das fast 4 Millionen Aufrufe erreicht hat — und es kristallisierte etwas, das ich gefühlt, aber nicht artikulieren konnte.
Jeff teilt KI in drei Ebenen auf, und sobald du sie siehst, kannst du sie nicht mehr rückgängig machen:
Ebene 1: Basis-LLM. Du gibst Input, du bekommst Output. ChatGPT bitten, eine E-Mail zu verfassen? Super. Es fragen, wann dein nächstes Meeting ist? Es scheitert. Es weiß es nicht. Es hat keinen Zugriff. Es generiert nur Text basierend auf Trainingsdaten.
Ebene 2: KI-Workflow. Du fügst vordefinierte Pfade hinzu. "Wenn der Benutzer nach Kalenderereignissen fragt, frage zuerst Google Calendar ab, dann antworte." Das funktioniert — bis der Benutzer etwas fragt, das du nicht erwartet hast. "Wie ist das Wetter am Tag meines Meetings?" Dein Workflow kennt nur Google Calendar, keine Wetter-APIs. Jede neue Fähigkeit erfordert, dass ein Mensch manuell einen weiteren Pfad hinzufügt.
Hier ist die Kernaussage aus Jeffs Analyse: Egal wie viele Schritte du hinzufügst — Hunderte, Tausende — wenn ein Mensch der Entscheidungsträger ist, welchem Pfad zu folgen ist, ist es immer noch nur ein Workflow. Kein Agent.
Ebene 3: KI-Agent. Das LLM selbst entscheidet, was zu tun ist. Es schlussfolgert ("Ich brauche Kalender- UND Wetterdaten"), wählt Tools aus ("Ich benutze zuerst die Google-Kalender-API, dann einen Wetterdienst"), führt aus, bewertet das Ergebnis und iteriert wenn nötig.
Das Framework dahinter heißt ReAct — Reason and Act. Der Agent denkt darüber nach, was er braucht, ergreift Maßnahmen mit Tools, beobachtet das Ergebnis und entscheidet, ob er weiter macht oder eine endgültige Antwort zurückgibt.
Und hier wird MCP das fehlende Stück. Denn ein KI-Agent braucht Tools, um zu handeln. Ohne Tools denkt er nur laut. MCP gibt ihm Hände.
MCP Mit Docker Einrichten (Der Praktische Teil)
Ich habe das auf die harte Tour gelernt: Versuche nicht, MCP-Server beim ersten Versuch manuell zu installieren. Verwende Docker. Es kümmert sich automatisch um Isolation, Abhängigkeiten und Aufräumen.
Hier ist mein genauer Einrichtungsprozess:
Schritt 1: Docker Desktop Installieren
Hol es von der offiziellen Seite für dein Betriebssystem. Auf Mac:
# Docker Desktop von docker.com/desktop herunterladen und installieren
# Oder via Homebrew:
brew install --cask docker
# Installation verifizieren
docker --version
# Docker version 28.x.x
# MCP Toolkit in Docker Desktop aktivieren:
# Settings → Beta Features → Docker MCP Toolkit → Enable
Auf Windows brauchst du zuerst WSL 2 oder Hyper-V als Backend. Linux ist unkompliziert — installiere einfach Docker Engine und Desktop.
Schritt 2: Den MCP-Katalog Durchsuchen
Docker Desktop kommt jetzt mit einem MCP-Katalog — einer kuratierten Liste offizieller MCP-Server. Öffne Docker Desktop, geh in den MCP-Toolkit-Bereich und durchsuche den Katalog. Ich war wirklich überrascht, was verfügbar ist:
- Obsidian — Vollständiger Vault-Zugriff (lesen, schreiben, suchen)
- Brave Search — Websuche mit Datenschutz
- Fetch — Inhalte beliebiger URLs abrufen
- YouTube Transcripts — Transkript beliebiger Videos abrufen
- DuckDuckGo — Suchen ohne API-Schlüssel
- Airbnb — Unterkünfte suchen (ja, wirklich)
Einen Server hinzuzufügen ist ein Klick. Einige benötigen API-Schlüssel (Brave zum Beispiel), viele funktionieren aber sofort ohne Konfiguration.
Schritt 3: Deinen LLM-Client Verbinden
Docker MCP Toolkit unterstützt mehrere Clients:
- Claude Desktop (kostenlose Stufe funktioniert)
- Cursor (für codeorientierte Arbeit)
- LM Studio (für lokale Modelle wie Llama)
Klicke neben deinem Client auf "Connect". Docker aktualisiert automatisch die MCP-Konfigurationsdatei, die dein Client liest. Für Claude Desktop befindet sich diese unter ~/Library/Application Support/Claude/claude_desktop_config.json auf dem Mac.
So sieht die Konfiguration hinter den Kulissen aus:
{
"mcpServers": {
"obsidian": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "OBSIDIAN_API_KEY=your-key-here",
"mcp/obsidian"
]
},
"fetch": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/fetch"]
},
"youtube-transcript": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/youtube-transcript"]
}
}
}
Jeder Server läuft als isolierter Docker-Container. Wenn Claude ein Tool verwenden muss, startet es den Container, führt den Aufruf durch, und der Container wird heruntergefahren. Sauber. Isoliert. Keine Abhängigkeitskonflikte.
Schritt 4: Testen
Starte Claude Desktop neu. Klicke auf das Einstellungssymbol — du solltest "MCP Docker" aufgelistet sehen. Klicke darauf, um zu überprüfen, ob deine Tools geladen sind.
Frage dann einfach: "Suche in meinem Obsidian-Vault nach Notizen über Projektplanung."
Claude wird erkennen, dass es das search_vault-Tool hat, um Erlaubnis bitten, es zu verwenden (nur beim ersten Mal, wenn du es so wählst), und Ergebnisse aus deinem tatsächlichen Vault zurückgeben.
Als ich das zum ersten Mal funktionieren sah, sagte ich buchstäblich "Das kann nicht wahr sein!" laut. In einem leeren Raum. Um 2 Uhr nachts.
Einen Benutzerdefinierten MCP-Server Bauen
Der Katalog ist gut für gängige Tools. Aber die echte Stärke entfaltet sich, wenn du benutzerdefinierte Server für deine spezifischen Bedürfnisse baust.
NetworkChucks Video zeigte etwas Verrücktes: Er baute einen MCP-Server, der Kali-Linux-Tools verpackt. Seine KI konnte nmap-Scans durchführen, Metasploit verwenden und Ziele aufzählen — alles über natürliche Sprache.
Ich baute etwas weniger Dramatisches, aber Praktischeres für meine tägliche Arbeit: einen MCP-Server, der die CMS-API meines Blogs verpackt. Hier ist das Grundgerüst:
#!/usr/bin/env python3
"""Custom MCP Server for mejba.me blog CMS."""
import json
import httpx
from mcp.server import Server
from mcp.types import Tool, TextContent
app = Server("blog-cms")
BASE_URL = "https://mejba.me/api"
API_TOKEN = "your-api-token"
@app.list_tools()
async def list_tools():
return [
Tool(
name="create_draft",
description="Create a new blog post draft with title, content, and tags",
inputSchema={
"type": "object",
"properties": {
"title": {"type": "string", "description": "Post title"},
"content": {"type": "string", "description": "Markdown content"},
"tags": {"type": "array", "items": {"type": "string"}}
},
"required": ["title", "content"]
}
),
Tool(
name="list_recent_posts",
description="List the most recent blog posts with their status",
inputSchema={
"type": "object",
"properties": {
"limit": {"type": "integer", "default": 10}
}
}
),
Tool(
name="get_post_analytics",
description="Get view count and engagement metrics for a post",
inputSchema={
"type": "object",
"properties": {
"slug": {"type": "string", "description": "Post slug"}
},
"required": ["slug"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
headers = {"Authorization": f"Bearer {API_TOKEN}"}
if name == "create_draft":
response = httpx.post(
f"{BASE_URL}/posts",
headers=headers,
json={
"title": arguments["title"],
"content": arguments["content"],
"tags": arguments.get("tags", []),
"status": "draft"
}
)
data = response.json()
return [TextContent(
type="text",
text=f"Draft created: {data['slug']} (ID: {data['id']})"
)]
elif name == "list_recent_posts":
limit = arguments.get("limit", 10)
response = httpx.get(
f"{BASE_URL}/posts?limit={limit}", headers=headers
)
posts = response.json()
result = "\n".join(
f"- [{p['title']}] ({p['status']}) - {p['views']} views"
for p in posts
)
return [TextContent(type="text", text=result)]
elif name == "get_post_analytics":
response = httpx.get(
f"{BASE_URL}/posts/{arguments['slug']}/analytics",
headers=headers
)
data = response.json()
return [TextContent(
type="text",
text=json.dumps(data, indent=2)
)]
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(app))
Verpacke das in ein Dockerfile, und jeder MCP-kompatible Client kann dein Blog-CMS über natürliche Sprache nutzen. "Hey Claude, erstelle einen Entwurf über MCP mit diesen Tags." Fertig.
Das Muster funktioniert für alles mit einer API: interne Dashboards, Datenbanken, IoT-Geräte, CI/CD-Pipelines. Wenn es eine API hat, kannst du es in unter einer Stunde in einen MCP-Server verpacken.
Die Ehrlichen Fehler, Die Ich Gemacht Habe
Ich möchte transparent darüber sein, was mich stolpern ließ, denn ich glaube, das sind Fehler, die die meisten Menschen machen werden.
Fehler 1: MCP-Agenten wie traditionelle Automatisierung behandeln. Mein erster Instinkt war, starre Workflows zu bauen — "Wenn ich X sage, tue Y." Aber der ganze Sinn des Agenten-Paradigmas ist, dass das LLM selbst entscheidet, welche Tools wann zu verwenden sind. Ich schränkte es ständig zu sehr ein. Die besten Ergebnisse kamen, wenn ich Claude ein Ziel gab und es die Tool-Sequenz selbst herausfinden ließ.
Fehler 2: Das Berechtigungsmodell ignorieren. MCP-Server können auf deine Dateien, deine APIs, dein Netzwerk zugreifen. Claude Desktop fragt vor jeder Tool-Verwendung um Erlaubnis (sofern du es nicht dauerhaft erlaubst). Ich deaktivierte die Bestätigungsaufforderungen aus Bequemlichkeit und vergaß dann, dass ich einen MCP-Server mit meiner E-Mail verbunden hatte. Claude "organisierte" hilfsbereit meinen Posteingang basierend auf einem beiläufigen Kommentar, den ich gemacht hatte. Lektion gelernt: Halte Berechtigungen eng, bis du dem Workflow vertraust.
Fehler 3: Perfektion von lokalen Modellen erwarten. Ich versuchte, MCP-verbundene Agenten über LM Studio mit Llama 3.1 auszuführen. Die Tool-Auswahl war merklich schlechter als bei Claude. Lokale Modelle funktionieren, brauchen aber expliziteres Prompting darüber, wann und wie Tools zu verwenden sind. Claude und GPT-4 sind bei der autonomen Tool-Auswahl deutlich besser — vorerst.
Hier ist eine kontroverse Einschätzung: Ich glaube, dass die meisten "KI-Agenten"-Produkte, die gerade verkauft werden, eigentlich Level-2-Workflows in einem Agenten-Kostüm sind. Sie folgen vordefinierten Pfaden mit etwas LLM-Entscheidungsfindung. Echte Level-3-Agenten — wo das LLM wirklich über Tool-Auswahl, Ausführungsreihenfolge nachdenkt und autonom iteriert — sind außerhalb von Forschungsdemos und einer Handvoll echter Implementierungen selten.
Allerdings ist MCP die Infrastrukturschicht, die echte Agenten möglich macht. Das Protokoll existiert. Die Tools existieren. Was aufholt, ist die Reasoning-Fähigkeit der Modelle selbst.
Wie Das In Der Praxis Aussieht
Nach drei Wochen des Aufbaus von MCP-basierten Workflows, hier ist mein konkretes Vorher/Nachher:
Blog-Recherche — Vorher: 2-3 Stunden manuelles Ansehen von YouTube-Videos, Notizen machen, Dokumentation quervergleichen. Nachher: 25 Minuten. Claude holt YouTube-Transkripte über MCP, durchsucht meinen Obsidian-Recherche-Vault nach verwandten Notizen und entwirft eine strukturierte Gliederung. Ich bearbeite von dort aus.
Kunden-Projekteinrichtung — Vorher: 45 Minuten für das Erstellen von Repos, CI/CD einrichten, zum Projekt-Tracker hinzufügen. Nachher: 8 Minuten. Claude erstellt das GitHub-Repo, initialisiert die Projektstruktur, fügt es zu ClickUp mit Meilensteinen hinzu und sendet eine Slack-Benachrichtigung an das Team. Alles über MCP-verbundene Tools.
Tägliche Standup-Vorbereitung — Vorher: 15 Minuten ClickUp, GitHub-PRs und Slack-Kanäle prüfen. Nachher: 2 Minuten. "Woran habe ich gestern gearbeitet und was steht für heute noch aus?" Claude prüft alle drei und gibt mir eine Zusammenfassung.
Die Zeitersparnisse sind real. Nicht theoretisch. Nicht "bis zu X%." Das sind meine tatsächlichen Zahlen aus den vergangenen drei Wochen.
Aber — und das ist wichtig — die anfängliche Einrichtung kostete mich ein volles Wochenende. Docker installieren, Server konfigurieren, Verbindungen testen, debuggen, wenn Dinge nicht funktionierten. Sobald es läuft, ist es magisch. Dorthin zu kommen erfordert Geduld.
Wohin Das Als Nächstes Führt
NetworkChuck erwähnte am Ende seines Videos etwas, das die meisten Zuschauer meiner Meinung nach übersehen haben: das Docker MCP Gateway. Das macht deine lokalen MCP-Server remote zugänglich — was bedeutet, dass Tools wie n8n, Make.com oder jede externe Automatisierungsplattform sich über das Netzwerk mit deinen MCP-Servern verbinden kann.
Denk darüber nach, was das bedeutet. Dein KI-Agent ist nicht mehr auf deine lokale Maschine beschränkt. Du könntest einen n8n-Workflow haben, der einen Claude-Agenten auslöst, der deine benutzerdefinierten MCP-Server verwendet, die auf einem VPS laufen. Der Agent schlussfolgert, was zu tun ist, verwendet Tools über MCP und gibt Ergebnisse zurück — alles ohne menschliches Eingreifen.
Wir sind noch nicht dort für die meisten Produktionsanwendungen. Aber die Lücke zwischen "Demo" und "Produktion" schließt sich schneller als ich erwartet hatte.
Wenn du eine Sache aus diesem Beitrag mitnimmst: Warte nicht darauf, dass KI-Agenten "bereit" sind. Die Infrastruktur — MCP, Docker-Container, Tool-Calling-LLMs — ist jetzt da. Die Entwickler, die diesen Stack heute lernen, werden einen massiven Vorteil haben, wenn die Reasoning-Fähigkeiten aufholen.
Ich setze meinen Workflow darauf. Und ehrlich gesagt? Drei Wochen rein zahlt es sich schon aus.
Lass Uns Zusammenarbeiten
Möchtest du KI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.
- Fiverr (Custom Builds & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
