Derzeit integriert fast jeder Model Context Protocol (MCP)-Server in seine Systeme. Und das aus gutem Grund: MCP ist elegant und standardisiert. Sie entwickeln einen Server, geben bestimmte Tools frei und schon kann Ihr LLM eigenständig Log-Plattformen abfragen, Dashboards laden oder Alarme auslösen. Es fühlt sich genau nach der richtigen Abstraktionsebene an.
Aber ich habe schon erlebt, wie Teams in großen Unternehmen wochenlang MCP-Integrationen für Arbeitsabläufe entwickelten, die eigentlich Fähigkeiten hätten sein sollen, und Fähigkeiten für Dinge entwickelten, die tatsächlich MCP erforderten. Die Verwirrung kostet die Menschen wertvolle Zeit.
So betrachte ich das:
MCP liefert die Leitungen. Fähigkeiten liefern die Expertise.
Ein MCP-Server beantwortet die Frage: Was kann der Agent tun?
Es gibt dem Modell Zugriff auf Tools. Es weist es an: Frag diese API ab. Lies diesen Datensatz. Schreib in dieses System. MCP ist die Verbindungsschicht zwischen einem LLM und der realen Welt – quasi eine Berechtigungserteilung.
Eine Fähigkeit beantwortet eine andere Frage: Wie sollte der Agent über diese Art von Problem nachdenken?
Eine Fähigkeit ist verpacktes Urteilsvermögen. Es ist die Abfolge von Schritten, die Domänenheuristiken, die „Wenn du X siehst, tue Y, bevor du Z tust“-Logik, die ein Experte anwenden würde. Fähigkeiten kodieren Arbeitsabläufe. MCP kodiert den Zugriff.
Sie brauchen beides. Sie sind jedoch nicht austauschbar, und die Verwendung des einen, wo man das andere benötigt, führt zu schlechten Ergebnissen.
Wo dieser Ansatz an seine Grenzen stößt
Nehmen wir ein SecOps-Team, das mit einer Log-Analytics-Plattform arbeitet. Sie wollen KI nutzen, um die Untersuchung von Alarmen zu unterstützen. Der erste Instinkt ist meist: Wir bauen einen MCP-Server. Wir stellen ein Tool für die Log-Suche bereit. Ein Tool zur Abfrage von Threat Intelligence. Ein Tool, um den Asset-Kontext abzurufen. Und schon kann das LLM einen Alarm „untersuchen“.
Der Haken an der Sache: Es kann es eben nicht. Zumindest nicht wirklich.
Was Sie dem Agenten gegeben haben, ist lediglich Zugriff. Sie haben ihm nicht den eigentlichen Workflow für die Untersuchung beigebracht. Sie haben nirgendwo verankert, dass man bei einem CSPM-Alarm für einen S3-Bucket zuerst in CloudTrail nachsieht, dann die IAM-Aktivitäten der letzten 24 Stunden abgleicht und schließlich prüft, ob der Bucket als „sensibel“ eingestuft ist, bevor man eskaliert. Das ist kein MCP-Problem. Das ist ein Skill-Problem.
Ein Agent mit MCP-Tools, aber ohne Skills, ist wie ein Junior-Analyst an seinem ersten Arbeitstag: Er hat zwar Zugriff auf jedes System im Unternehmen, hat aber noch nie im Leben einen Vorfall untersucht. Er kann alles abfragen. Aber er weiß nicht, was er abfragen soll, in welcher Reihenfolge oder mit welcher Hypothese im Hinterkopf.
Die Fähigkeit ist das Training. MCP ist nur der Zugangsausweis.
Wann Sie MCP wirklich brauchen
Sie benötigen einen MCP-Server, wenn der Agent Echtzeitzugriff auf Live-Daten oder Systeme benötigt, die er sonst nicht erreichen könnte.
- Abfragen Ihrer Protokollplattform nach Ereignissen in einem Zeitfenster
- Abrufen des aktuellen Alarmstatus aus Ihrem SIEM
- Programmgesteuertes Erstellen oder Aktualisieren eines Monitors
- Abgleich des Asset-Bestands mit einer Live-CMDB
Das sind klassische Tool-Aufrufe. Sie sind zustandslos, sie liefern Daten zurück, sie führen eine Aktion aus. Hier ist MCP genau die richtige Abstraktionsebene.
Sie brauchen MCP auch dann, wenn mehrere Agenten oder verschiedene Benutzeroberflächen gemeinsamen Zugriff auf dieselben Funktionen haben sollen. Ein MCP-Server für Ihre Log-Plattform – und jeder Agent, jede Integration und jedes IDE-Plugin kommuniziert mit genau diesem Server. Das ist der perfekte Einsatzbereich für dieses Protokoll.
Wann Sie eine Fähigkeit brauchen
Man benötigt eine Fähigkeit, wenn man einen wiederholbaren Workflow mit integriertem Urteilsvermögen kodiert, wie in den folgenden Beispielen.
- Untersuchen Sie diesen Alert-Typ (hier ist die richtige Sequenz, hier sind die zu testenden Hypothesen, hier ist die Strukturierung der Ausgabe).
- Parsen Sie dieses Logformat (hier sind die Randfälle, hier ist, was der Anbieter falsch macht, hier ist die korrekte Feldextraktion).
- Erstellen Sie eine Erkennungsregel für dieses Bedrohungsmuster (hier ist die Methodik, hier ist, was eine Regel verrauscht vs. präzise macht).
- Führen Sie eine Incident-Retrospektive durch (hier steht, was Sie heranziehen, wie Sie die Zeitleiste strukturieren und welche Fragen Sie beantworten sollten).
Das sind keine Tool-Aufrufe. Es sind Workflows. Der Agent muss wissen, was er mit den ihm zur Verfügung stehenden Tools anfangen soll – nicht nur, dass die Tools existieren.
Eine Fähigkeit kann MCP-Tools aufrufen. Das ist das Muster, das tatsächlich funktioniert: Die Fähigkeit liefert den Denkrahmen, MCP den Datenzugriff. Die Fähigkeit orchestriert. MCP führt aus.
Mein Test für die Praxis
Wenn mich jemand fragt: “Sollte das eine Fähigkeit oder ein MCP-Server sein?”, stelle ich ihm eine Gegenfrage:
Wenn ein erfahrener Experte in Ihrem Team dies manuell durchführen würde, bestünde die Schwierigkeit dann darin, Zugriff auf die Daten zu erhalten? Oder zu wissen, was man mit den Daten anstellt, sobald man sie hat?
Wenn die Hürde beim Zugriff liegt, brauchen Sie MCP. Wenn die Hürde beim Urteilsvermögen liegt, brauchen Sie eine Fähigkeit.
Hand aufs Herz: Meistens ist das Urteilsvermögen der schwierige Teil. Genau deshalb funktionieren reine MCP-Server nie so ganz, wie die Leute es erwarten. Sie haben dem Agenten zwar die Schlüssel gegeben. Aber Sie haben ihm nicht das Autofahren beigebracht.
Die pragmatische Konsequenz
Hören Sie auf, MCP-Server für Probleme zu bauen, die eigentlich Workflow-Probleme sind. Betrachten Sie Skills stattdessen als eigenständige Kernkomponenten – Dinge, die Sie konzipieren, testen, versionieren und kontinuierlich verbessern, genau wie ein Runbook.
Ihr MCP-Server ist die Infrastruktur. Ihre Fähigkeiten sind das gebündelte Fachwissen Ihres Teams. Beides ist wichtig. Sie sind nur die Antworten auf zwei völlig verschiedene Fragen.
Wie sieht die Verteilung bei Ihnen aktuell aus – setzen Sie noch zu sehr auf MCP oder nehmen Sie das Thema Fähigkeiten bereits ernst?
Noch wichtiger ist: Wie steuern Sie die Autonomie und den Tool-Zugriff auf der Ausführungsebene?
