
Alle fügen im Moment überall Model Context Protocol (MCP)-Server hinzu. Und ich verstehe das. MCP ist sauber. Es ist standardisiert. Sie schreiben einen Server, stellen einige Tools bereit, und plötzlich kann Ihr LLM Ihre Protokollplattform abfragen, ein Dashboard abrufen und eine Warnung auslösen. Es fühlt sich wie die richtige Abstraktion 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 sehe ich das.
MCP ist Leitungsinfrastruktur. Fähigkeiten sind Expertise.
Ein MCP-Server beantwortet die Frage: Was kann der Agent tun?
Er ermöglicht dem Modell den Zugriff auf Werkzeuge. Er weist es an, diese API abzufragen. Lesen Sie diesen Datensatz. Schreiben Sie in dieses System. MCP ist die Verbindungsschicht zwischen einem LLM und der realen Welt. Es ist eine Zugriffsberechtigung.
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 ich sehe, dass das scheitert
Nehmen wir ein Security-Operations-Team, das auf einer Protokollanalyseplattform arbeitet. Sie wollen KI zur Unterstützung bei der Untersuchung von Alarmmeldungen einsetzen. Der erste Impuls ist, einen MCP-Server zu bauen. Ein Tool zum Durchsuchen von Protokollen bereitstellen. Ein Tool zur Abfrage von Bedrohungsdaten bereitstellen. Ein Tool zur Erfassung des Asset-Kontexts bereitstellen. Nun kann das LLM eine Warnung „untersuchen“.
Nur kann es das nicht. Nicht wirklich.
Was Sie dem Agenten gewährt haben, ist Zugriff. Sie haben den Untersuchungsablauf nicht angegeben. Sie haben nicht codiert, dass eine CSPM-Warnung für einen S3-Bucket bedeutet, dass Sie zuerst CloudTrail überprüfen, dann die IAM-Aktivitäten der letzten 24 Stunden abgleichen und anschließend prüfen, ob der Bucket als sensibel gekennzeichnet ist, bevor Sie eskalieren. Das ist kein Problem des MCP. Das ist ein Problem der Fähigkeiten.
Ein Agent, der zwar über MCP-Tools verfügt, aber keine praktischen Fähigkeiten besitzt, ist wie ein neuer Analyst, der Zugriff auf jedes System in Ihrer Umgebung hat, aber noch nie eine Untersuchung durchgeführt hat. Er kann alles abfragen. Aber sie wissen nicht, was sie abfragen sollen, in welcher Reihenfolge oder mit welcher Hypothese.
Die Fähigkeit steckt im Training. MCP ist der Zugangsausweis.
Wenn Sie MCP tatsächlich benötigen
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 Anlagenbestands mit einer Live-CMDB
Dies sind Tool-Aufrufe. Sie sind zustandslos, sie liefern Daten zurück, sie führen eine Aktion aus. MCP ist die richtige Abstraktion.
Sie benötigen MCP auch dann, wenn mehrere Agenten oder mehrere Oberflächen gemeinsam auf dieselben Funktionen zugreifen sollen. Ein MCP-Server für Ihre Protokollplattform. Jeder Agent, jede Integration, jedes IDE-Plugin – sie alle kommunizieren mit demselben Server. Das ist die korrekte Verwendung des Protokolls.
Wenn man tatsächlich eine Fähigkeit benötigt
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 Werkzeugen anfangen soll – nicht nur, dass die Werkzeuge 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.
Der Test, den ich verwende
Wenn mich jemand fragt: “Sollte das eine Fähigkeit oder ein MCP-Server sein?”, stelle ich ihm eine Frage:
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 sie damit tun sollten, sobald sie diese hatten?
Wenn der schwierige Teil der Zugriff ist, benötigen Sie MCP. Wenn der schwierige Teil das Urteilsvermögen ist, benötigen Sie eine Fähigkeit.
Ehrlich gesagt ist der schwierige Teil meistens die Beurteilung. Deshalb funktioniert der MCP-Server allein nie so, wie die Leute es erwarten. Sie haben dem Agenten die Schlüssel gegeben. Sie haben ihm nicht das Autofahren beigebracht.
Die praktische Version
Hören Sie auf, MCP-Server für Dinge zu bauen, die in Wirklichkeit Workflow-Probleme sind. Beginnen Sie damit, Fähigkeiten als erstklassige Artefakte zu behandeln – Dinge, die Sie entwerfen, testen, versionieren und im Laufe der Zeit verbessern, genau wie Sie ein Runbook pflegen würden.
Ihr MCP-Server ist Infrastruktur. Ihre Fähigkeiten sind das Fachwissen Ihres Teams – verpackt. Beides ist wichtig. Es sind lediglich Antworten auf unterschiedliche Fragen.
Wie sieht Ihre Aufteilung im Moment aus – sind Sie zu stark auf MCP fokussiert oder haben Sie begonnen, Fähigkeiten ernst zu nehmen?
Noch wichtiger ist die Frage, wie Sie die Autonomie und den Werkzeugzugriff auf Ausführungsebene steuern.



