KI-Agenten, MCP Server und Tools erklärt (2026)

Für Entwickler, CTOs und Tech Leads · Basierend auf einer echten Diskussion in meiner Entwickler-Community.

TL;DR: KI-Agenten, MCP Server, Tools, Skills — vier Begriffe, die in jeder KI-Diskussion fallen und die niemand einheitlich definiert. In meiner Entwickler-Community hat jemand genau die Frage gestellt, die ich in jeder Runde höre: „Was ist eigentlich der Unterschied?” Die Antworten waren so klar, dass ich sie hier aufschreibe. Kurzversion: KI-Agenten handeln eigenständig. MCP ist der Standard, über den sie mit der Außenwelt sprechen. Tools sind die einzelnen Aktionen. Und Skills sind Wissens-Dateien, die dem Agenten beibringen, wie er vorgehen soll.

---

Die Frage, die jeder stellt

In einer Entwickler-Runde letzte Woche hat jemand die Hand gehoben und gefragt: „Ich habe den Überblick verloren. Wie unterscheiden wir jetzt genau zwischen MCP Server, Skill und Tools?”

Stille. Dann zwei Erklärungen gleichzeitig. Beide richtig, aber unterschiedlich.

Das Problem: Diese Begriffe tauchen überall auf — in Docs, in Blogposts, in Verkaufspräsentationen — aber selten sauber voneinander getrennt. Ich habe die Diskussion mitverfolgt und dabei mehr gelernt als aus den meisten Artikeln zum Thema.

Was sind KI-Agenten?

Ein KI-Agent ist ein Sprachmodell, das nicht nur Text generiert, sondern handelt. Der entscheidende Unterschied zu einem Chatbot: Ein Agent entscheidet selbst, was er als Nächstes tut.

Wenn ich Claude Code sage: „Implementiere einen Dark Mode für die Settings-Seite”, dann passiert Folgendes. Das Modell liest die Codebase. Es findet die relevanten Dateien. Es entscheidet, welche Änderungen nötig sind. Es schreibt den Code. Es führt die Tests aus. Wenn ein Test fehlschlägt, liest es die Fehlermeldung und korrigiert. All das ohne dass ich zwischendurch eingreife.

Das ist Agentic AI. Ein Modell, das nicht nur redet, sondern macht.

Jemand in der Runde hat es gut auf den Punkt gebracht: „Das LLM generiert eine Antwort: ‚Ich möchte Tool X mit Argumenten x, y, z aufrufen.’ Ein Framework interpretiert diese Antwort, führt das Tool aus und gibt das Ergebnis zurück an das LLM.” Keine Magie also. Eine Schleife: Denken, Handeln, Ergebnis auswerten, weiterdenken.

KI-Agenten Beispiele aus dem Alltag: Claude Code liest und editiert Dateien in einer Codebase. ChatGPTs Agentenmodus recherchiert und führt Code aus. GitHub Copilot Agent schreibt Pull Requests aus Issue-Beschreibungen. Gemeinsam ist ihnen, dass sie Tools nutzen, um über reines Textgenerieren hinauszukommen.

Was ist ein MCP Server?

MCP steht für Model Context Protocol — ein offener Standard, den Anthropic Ende 2024 veröffentlicht hat. Kurz erklärt: MCP ist eine einheitliche Schnittstelle zwischen KI-Agenten und externen Systemen.

Stell dir MCP wie ein USB-C-Kabel vor. Bevor es USB-C gab, brauchte jedes Gerät einen eigenen Stecker. MCP ist der universelle Anschluss für KI-Agenten. Statt für jedes Tool eine eigene Integration zu bauen, gibt es einen Standard.

Die Architektur ist einfach: Ein MCP Host (die KI-Anwendung, z.B. Claude Code) verbindet sich über einen MCP Client mit einem oder mehreren MCP Servern. Jeder Server stellt Funktionen bereit — Datenbankzugriff, GitHub-Operationen, Jira-Tickets lesen, Figma-Designs exportieren.

Was das in der Praxis bedeutet: Ich habe in meinem Claude Code Setup MCP Server für GitHub, die Chrome DevTools und DataForSEO konfiguriert. Wenn ich sage „Recherchiere Keywords für diesen Blogpost”, nutzt der Agent den DataForSEO-MCP-Server, um Suchvolumen und Keyword-Schwierigkeit abzufragen — ohne dass ich eine eigene API-Integration schreiben musste.

Ein anderer Teilnehmer brachte es auf eine Zeile: „MCP ist ein Standard für Toolaufrufe und Datenaustausch zwischen LLM und dem Framework um das LLM.” Fertig. Mehr ist es nicht.

MCP vs. klassische API

Berechtigte Frage: Ist MCP nicht einfach eine API mit anderem Namen?

Nicht ganz. Bei einer REST-API hat man Endpunkte, Parameter, Authentifizierung. Ein Mensch muss die Doku lesen und den richtigen Call zusammenbauen. Ein MCP Server beschreibt seine Fähigkeiten so, dass der Agent selbst entscheiden kann, welches Tool er wann aufruft. Der Agent liest die Beschreibung und weiß, was er damit tun kann. Und weil MCP ein Standard ist, reicht ein Client für beliebig viele Server. Keine Custom-Integration pro Anbieter.

Wann du MCP brauchst: Wenn dein Agent live auf externe Daten zugreifen muss — Datenbanken, APIs, Projektmanagement-Tools, Code-Repositories. Wann du MCP nicht brauchst: Wenn die Information stabil ist und sich selten ändert. Dann reicht ein Skill.

Tools — Die Hände des Agenten

Tools sind die einzelnen Funktionen, die ein Agent aufrufen kann. Jedes Tool tut genau eine Sache: eine Datei lesen, eine Datei schreiben, einen Shell-Befehl ausführen, eine Websuche starten.

Der Ablauf sieht so aus:

1. Du gibst dem Agenten einen Auftrag
2. Das Modell überlegt, was es tun muss
3. Es generiert einen Tool-Aufruf-Wunsch als JSON: „Ich möchte read_file mit dem Pfad src/app.tsx aufrufen”
4. Das Agent-Framework führt den Aufruf aus
5. Das Ergebnis geht zurück an das Modell
6. Das Modell überlegt den nächsten Schritt — oder liefert die finale Antwort

Ein Kollege hat einen eigenen Open-Source-Coding-Agenten gebaut, um genau diesen Ablauf transparent zu machen. In seinem Code sieht ein Tool so aus: Ein Name (read_file), eine Beschreibung für das Modell, und eine Execute-Funktion. Das Modell sieht nur den Namen und die Beschreibung — und ist intelligent genug, den Rest selbst herauszufinden.

Das ist der Punkt, den viele unterschätzen: „Du gibst nur ‚Bitte implementiere einen Dark Mode’ ein. Das davor — die Tool-Beschreibungen, den System-Prompt, die Regeln — schreibt der Agent unsichtbar in den Prompt.” Der Nutzer sieht nur den Input und den Output. Dazwischen liegt die ganze Architektur.

Skills — Das Wissen, nicht die Verbindung

Skills sind der Teil, den die meisten Erklärungen weglassen. Schade eigentlich, denn ohne sie versteht man das Gesamtbild nicht.

Ein Skill ist eine Textdatei — meistens Markdown — die dem Agenten beibringt, wie er eine bestimmte Aufgabe angehen soll. Kein Code, keine API-Verbindung. Reines Wissen.

Aus der Diskussion: „Skills sind einfache Textfiles. Sie enthalten Anweisungen dazu, wie das LLM vorgehen soll, welche Tools es nutzen soll. Also im Prinzip eine Ergänzung zum System-Prompt.”

Beispiel: Ich habe einen Skill für Code-Reviews. Darin steht: Prüfe zuerst die Typsicherheit. Achte auf unbehandelte Edge Cases. Flagge Breaking Changes in öffentlichen APIs. Wenn ich den Skill aktiviere und sage „Review diesen Pull Request”, weiß der Agent nicht nur was er prüfen soll, sondern wie.

MCP vs Tools vs Skills

	Funktion	Was es ist	Wann nutzen
Skills	Wissen	Textdatei mit Anweisungen	Wenn sich das Wissen selten ändert
MCP	Verbindung	Standardprotokoll zu externen Systemen	Wenn du Live-Daten brauchst
Tools	Aktion	Einzelne ausführbare Funktion	Immer — Agenten brauchen Tools zum Handeln

Und dann kam der Satz, der bei mir hängen geblieben ist: „Alles drei landet im System-Prompt. Also alles drei wird zu Text, welcher bei jedem LLM-Aufruf mitgegeben wird.” Skills, Tool-Beschreibungen und MCP-Server-Definitionen — am Ende ist alles Text im Kontext des Modells.

Wie alles zusammenspielt

Jetzt das Gesamtbild. MCP, Tools und Skills sind keine Alternativen. Sie sind Schichten, die aufeinander aufbauen.

Oben: Skills definieren das Wissen und die Strategie. Wie soll der Agent vorgehen? Welchen Ton treffen? Welche Regeln beachten?

Mitte: Der Agent orchestriert. Er liest die Skills, entscheidet über den nächsten Schritt, ruft Tools auf, wertet Ergebnisse aus.

Unten: Tools und MCP führen aus. Tools sind die lokalen Aktionen (Dateien lesen, Code ausführen). MCP Server verbinden mit der Außenwelt (GitHub, Datenbanken, APIs).

Ein konkretes Beispiel aus meinem Arbeitsalltag: Ich sage Claude Code: „Review den Pull Request für das neue Auth-Modul.”

1. Ein Skill (code-review) gibt dem Agenten die Prüfkriterien vor — Typsicherheit, Security, Breaking Changes
2. Der Agent nutzt Tools (read_file, grep) um den Code zu lesen und Muster zu suchen
3. Ein MCP Server (GitHub) liefert den PR-Diff und die bestehenden Kommentare
4. Der Agent bringt alles zusammen

Kein einzelner Teil davon reicht allein. Aber zusammen ergibt sich Agentic AI in der Praxis: ein System, das tatsächlich funktioniert.

Warum KI-Agenten dieselben Probleme haben wie wir

Am Ende der Diskussion wurde es philosophisch. Ein Teilnehmer hatte einem KI-Agenten Konzepte aus der Metakognitionsforschung vorgelegt — Theorien darüber, wie Menschen über ihr eigenes Denken nachdenken. Was dann passierte, fand ich überraschend: Der Agent hat sich selbst Leitplanken erdacht. Und zwar solche, die wir alle kennen.

Zu viel Kontext. Zu wenig Vorsicht. Häufiger Kontextwechsel. Sich in Details verrennen und alles schlimmer machen, statt einen Schritt zurückzutreten.

Sein Fazit: „Alles Dinge, mit denen wir Menschen auch zu kämpfen haben, wenn Probleme zu groß werden. Die Methoden, dem zu begegnen, sind identisch.”

Wenn man drüber nachdenkt, ergibt das Sinn. KI-Agenten arbeiten mit begrenztem Kontext. Wenn der voll ist, verlieren sie den Überblick. Genau wie ein Entwickler mit 40 offenen Tabs. Und die Lösung ist auch dieselbe: Aufgaben kleiner schneiden. Scope begrenzen. Eins nach dem anderen.

Ein anderer Entwickler bestätigte das aus der Praxis: Er hatte den Standard-System-Prompt seines Coding-Agenten drastisch reduziert. Weniger Anweisungen, weniger Kontext, weniger Rauschen. Das Ergebnis: „Ich sehe keine Nachteile.”

Für Teams bedeutet das: Ein guter Agent braucht nicht den längsten Prompt. Er braucht den klarsten. Weniger ist bei KI-Agenten oft tatsächlich mehr — genau wie beim menschlichen Arbeiten. (Wie ich KI generell in meiner Arbeit als App-Entwickler einsetze, habe ich separat beschrieben.)

Was das für dein Team bedeutet

Wenn du KI-Agenten erstellen und in euren Workflow einbauen willst, hier die pragmatische Reihenfolge:

Schritt 1: Fang mit Skills an. Schreib auf, wie euer Team bestimmte Aufgaben erledigt. Code-Reviews, Deployment-Checklisten, Onboarding-Prozesse. Das sind eure ersten Skills — Textdateien, die ein Agent lesen und befolgen kann. Kein Setup nötig, keine Infrastruktur.

Schritt 2: Füge MCP hinzu, wenn du Live-Daten brauchst. Euer Agent soll Jira-Tickets lesen? GitHub-PRs kommentieren? Dann brauchst du MCP Server. Die meisten gängigen Tools haben bereits offizielle MCP Server. Das Ökosystem umfasst inzwischen tausende Server — Tendenz stark steigend.

Schritt 3: Baue eigene Tools nur wenn nötig. In den meisten Fällen reichen die vorhandenen Tools und MCP Server. Eigene Tools lohnen sich nur für unternehmensspezifische Systeme, die kein Standard-MCP-Server abdeckt.

Meine Beobachtung: Die meisten Teams über-engineeren ihr Setup, wenn sie einen KI-Agent bauen wollen. Sie starten mit eigenen MCP Servern, Custom Tools, komplexer Orchestrierung. Dabei reicht am Anfang ein guter Skill und die Standard-Tools. Den Rest kann man nachrüsten, wenn man weiß, wo es klemmt.

Wer sich für die Infrastruktur-Seite interessiert: In meinem Post über lokale KI für Entwickler beschreibe ich die Hardware- und Kosten-Entscheidungen dahinter.

(Wenn du überlegst, wie KI-Agenten in eurem konkreten Setup aussehen könnten — kostenloses Erstgespräch buchen, ich gebe dir eine Einschätzung.)