MCPs, Agenten und Skills: Wann braucht man was?
Wer sich mit moderner KI-Architektur beschäftigt, begegnet immer wieder denselben Begriffen: Agenten, Skills und MCPs. Oft werden sie in einem Atemzug genannt, als wären sie austauschbar. Wer diese Begriffe nicht sauber voneinander trennt, baut Lösungen, die unnötig komplex werden. Hier zeigt sich, warum selbst ein noch so gut formulierter Prompt das eigentliche Problem nicht löst.
Letztlich geht es um eine einfache Frage: Wann brauche ich was und warum?
Das Fundament von allem: die klassische API
Bevor KI ins Spiel kommt, gibt es bereits die klassische Schnittstelle. Anwendungscode ruft eine bekannte API auf, beispielsweise GET/stock oder POST/invoice, und erhält eine definierte Antwort zurück.
Dafür braucht es:
- kein Modell,
- keine Tool-Auswahl,
- keine Tokens.
Das Ganze passiert in Millisekunden und ist (exakt) reproduzierbar.
Diese Ebene verschwindet nicht, nur weil KI hinzukommt. Im Gegenteil: Sie bleibt das Fundament der gesamten Architektur. Jeder Agent, der auf echte Daten oder Geschäftsprozesse zugreifen muss, landet am Ende wieder bei einer gewöhnlichen API. Dafür gibt's eine einfache Faustregel: Erst das Problem benennen, dann das Werkzeug wählen. Nie umgekehrt!
Zugang zu Systemen, Extrawissen, Interaktionen mit externen Systemen sind unterschiedliche Herausforderungen. MCP, Skills und Agenten lösen jeweils eine davon.
MCP: Das Problem des Zugangs
Das Model Context Protocol (MCP) beantwortet eine zentrale Frage: Wie erfährt ein Sprachmodell, welche Interaktion verfügbar ist und wie diese verwendet werden kann?
Ein MCP-Server wirkt auf den ersten Blick oft spektakulärer, als er tatsächlich ist. Im Kern besteht er aus:
- einem Werkzeugnamen,
- einer Beschreibung,
- Metadaten (Eingabeparameter etc.),
- und einer Kernlogik, die letztendlich wieder eine klassische API aufruft.
MCP ersetzt die API also nicht. Stattdessen versieht es sie mit einer standardisierten (textuellen) Beschreibung, die ein Sprachmodell verstehen kann. Anders gesagt: MCP hängt einer vorhandenen API "ein Schild" um, auf dem steht, wann und wie sie benutzt werden soll.
Am Ende klopft der Agent über MCP an dieselben „Türen“ wie zuvor. Der Unterschied: Er findet sie nun selbstständig.
Wann sich MCP lohnt
Der große Vorteil von MCP liegt in der Standardisierung.
Ohne einen gemeinsamen Standard müssen „N-Anwendungen“ mit „M-Werkzeugen“ einzeln verbunden werden. Daraus entstehen N × M-Integrationen*, die entwickelt und gepflegt werden müssen. Mit MCP reduziert sich dieser Aufwand erheblich, da Werkzeuge standardisiert beschrieben und angebunden werden können. Allerdings lohnt sich das nicht in jedem Projekt.
Als Faustregel gilt: Bei ein oder zwei KI-Integrationen verursacht MCP häufig mehr Aufwand als Nutzen. Ab drei Integrationen beginnt der Standardisierungsgewinn die zusätzliche Komplexität zu rechtfertigen.
Was zunächst wie eine kleine Abkürzung aussieht, kann bei wachsender Anzahl von Anwendungen schnell zum entscheidenden Architekturvorteil werden.
(* Rechenbeispiel: 2 Apps mit jeweils 3 Werkzeugen = 2 × 3 = 6 Integrationspunkte)
Der Haken daran
MCP ist nicht kostenlos. Jede Tool-Definition, die dem Modell angeboten wird, belegt Platz im Kontextfenster. Werden viele MCP-Server mit zahlreichen Tools eingebunden, wächst der Kontextbedarf schnell an, noch bevor der Benutzer überhaupt eine Anfrage gestellt hat.
MCP-Werkzeuge verursachen also laufende Kontextkosten, die bei Architekturentscheidungen häufig unterschätzt werden.
Daher muss man sich vorher fragen: Verändern sich die benötigten Daten zwischen zwei Aufrufen? Dann handelt es sich meist um einen Fall für MCP.
Skills: Das Problem des Verfahrens
Ein Skill löst ein völlig anderes Problem. Im Gegensatz zu MCP enthält ein Skill keinen Server, keine Zugangsdaten und keine Netzwerkanbindung. Ein Skill ist keine ausführbare Software, sondern im Wesentlichen eine strukturierte Arbeitsanweisung, lesbar für Menschen wie für Modelle.
Ein Skill beschreibt:
- welche Schritte auszuführen sind,
- in welcher Reihenfolge sie erfolgen etc.
Man kann sich einen Skill wie ein Kochrezept vorstellen. Wie bei einem echten Rezept lassen sich einzelne Schritte anpassen, austauschen oder ergänzen, ohne das gesamte Vorgehen neu entwerfen zu müssen.
Warum ein guter Prompt oft nicht ausreicht
An dieser Stelle kommt häufig der Einwand: „Das kann ich doch einfach in den Prompt schreiben". Natürlich kann man das und auf den ersten Blick liest sich das Ergebnis oft sogar recht gut. Der Unterschied besteht jedoch darin, dass Skills standardisierte und wiederverwendbare Verfahren definieren. Ein Prompt kann ähnliche Anweisungen enthalten, liefert jedoch häufig keine konsistente Struktur und keine dauerhaft reproduzierbare Vorgehensweise.
Progressive Disclosure: Warum Skills so effizient sind
Ein wesentlicher Vorteil von Skills liegt im sogenannten Progressive Disclosure. Solange ein Skill nicht benötigt wird, kennt der Agent lediglich den Namen und die Beschreibung. Das verursacht nur sehr geringe Kontextkosten, gerade mal 100 Tokens für einen kompletten Fachprozess.
Erst wenn eine Aufgabe tatsächlich zum Skill passt, wird die vollständige Arbeitsanweisung nachgeladen. Dadurch wird nur für den konkreten Anwendungsfall zusätzlicher Kontext verbraucht. Das Progressive Disclosure ist der entscheidende Unterschied gegenüber einem MCP-Tool, das seinen Platz dauerhaft blockiert.
Merksatz dazu: Liegt die Herausforderung nicht in der Beschaffung der Daten, sondern im korrekten Vorgehen? Dann ist es ein Skill.
Agenten: Das Problem der Entscheidung
Ein Agent ist der Begriff, um den aktuell der größte Hype gemacht wird. Ein Agent ist kein Server und keine Datei. Er ist die Laufzeit, in der ein Sprachmodell selbständig entscheidet: Welches Werkzeug (über MCP) verwendet wird, welches Verfahren (über Skills) angewendet wird. Dieser Vorgang wiederholt sich so lange, bis die Aufgabe abgeschlossen ist.
Der entscheidende Punkt dabei: Ein Agent verhält sich nicht wie ein fehlerfreies Programm, sondern eher wie ein Staubsaugerroboter. Denn ein Agent orientiert sich in ähnlicher Weise an einem Ziel, reagiert auf neue Informationen und passt seinen Weg dynamisch an. Ein klassisches Programm folgt einem fest definierten Ablauf (auch Algorithmus genannt).
Das macht ihn flexibel, aber eben auch weniger deterministisch.
Wenn Agenten miteinander kommunizieren: A2A
Sobald ein Agent Aufgaben an einen anderen Agenten delegiert, häufig sogar organisationsübergreifend, reicht ein einfacher Funktionsaufruf nicht mehr aus. Genau hier setzt Agent2Agent (A2A) an. Das Protokoll standardisiert die Kommunikation zwischen Agenten, auch dann, wenn diese auf unterschiedlichen Frameworks basieren.
Typischerweise läuft der Prozess so ab:
1. Ein Agent übergibt einen Auftrag.
2. Der Auftrag wird verarbeitet.
3. Der Status kann zwischendurch abgefragt werden.
4. Nach Abschluss werden ein oder mehrere Antworten zurückgeliefert. Diese Ergebnisse treffen nicht zwingend gleichzeitig ein.
Merksatz: A2A wird relevant, sobald Arbeit eine Eigentumsgrenze überschreitet und lange genug dauert, dass ein Statusabgleich erforderlich wird.
Die Landkarte der KI-Architektur
Fazit
Wer MCP, Skills und Agenten sauber voneinander trennt, erkennt schnell, dass sie keine konkurrierenden Technologien sind. Jede adressiert eine andere Fragestellung:
- - APIs bleiben das Fundament und sind KERN aller Prozesse
- - MCP sorgt für Zugänge und Skills beschreiben Verfahren. Meist braucht man beides.
- - Agenten treffen (automatisch) Entscheidungen.
- - A2A ermöglicht eine Delegation.
Die wichtigste Erkenntnis lautet jedoch: Wähle immer den einfachsten Mechanismus, der das Problem löst.
Komplexität ist kein Qualitätsmerkmal. Gute KI-Architekturen entstehen nicht dadurch, möglichst viele Konzepte einzusetzen, sondern indem jede Ebene genau dort verwendet wird, wo sie einen konkreten Mehrwert liefert!
Quellen und Belege
MCP – Spezifikation und Architektur:
Architektur, Primitive, Discovery, Statelessness: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
Einstieg in die Spec-Version 2026-07-28: https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro
MCP wird an die Agentic AI Foundation gespendet (09.12.2025): https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
Skills – offener Standard:
Agent Skills, vollständige Formatspezifikation: https://agentskills.io/specification
Was Skills sind und wie sie sich zu MCP verhalten: https://support.claude.com/en/articles/12512176-what-are-skills
Skills aus der Praxis (`mattpocock/skills`): https://github.com/mattpocock/skills
Agent-zu-Agent:
A2A v1.0, signierte Agent Cards, 150+ Organisationen: https://a2a-protocol.org
ACP geht in A2A auf (29.08.2025, LF AI & Data): https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/
IBM: ACP-Erklärung mit Migrationshinweis: https://www.ibm.com/think/topics/agent-communication-protocol
Was ein KI-Agent ist: https://www.ibm.com/de-de/think/topics/ai-agents
Kontextkosten:
MCP-Issue 2808: ~1.000 Tokens pro Tool, gemessen: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2808
550–1.400 Tokens je Tool-Definition: https://www.apideck.com/blog/mcp-server-eating-context-window-cli-alternative
Sicherheit:
MCPTox: 45 echte Server, 353 Tools, Erfolgsquoten 36,5 % / 72,8 %: https://arxiv.org/abs/2508.14925
Cloud Security Alliance zu Tool Poisoning: https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-tool-poisoning-auto-execution-20260701/
- mcp-issue: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2808
- apidec: https://www.apideck.com/blog/mcp-server-eating-context-window-cli-alternative
- a2: https://a2a-protocol.org
- acp-l: https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/
- ibm-acp: https://www.ibm.com/think/topics/agent-communication-protocol
