Skills vs. MCP vs. CLI: Agenten-Tools richtig auswählen

Unterstützt vonAnzeige

Skills beschreiben, wie eine Aufgabe erledigt werden soll. MCP verbindet einen Agenten mit Tools und Daten. Eine CLI führt Befehle aus. Computer Use bedient eine Oberfläche. Das sind unterschiedliche Aufgaben, und ein Agent kann diese Bausteine kombinieren.

Wenn du Skills, MCP und CLI vergleichst, ist genau diese Trennung der richtige Einstieg. Du musst nicht eine Technologie für die komplette Anwendung auswählen. Wähle pro Fähigkeit die einfachste zuverlässige Schnittstelle und setze Berechtigungen außerhalb des Modells durch.

Ich ordne hier die wichtigsten Agenten-Tools ein, erkläre Function Calling und mache die Entscheidungen an einem Intune-Supportablauf konkret. Aktualisiert am 28. September 2026: Die Anbieterübersicht berücksichtigt jetzt Codex Skills und Googles Agent Development Kit. Die ursprüngliche Grafik bleibt am Ende als historische Übersicht erhalten.

Die AI-Tooling-Landschaft einfach erklärt#

Baustein	Wofür er da ist	Was er allein nicht liefert
Function Calling	Das Modell fordert eine typisierte Operation an	Die Berechtigung, diese Operation auszuführen
MCP	Standardisierte Kommunikation zwischen Host und Tool-Server	Identischen Funktionsumfang in jedem Host
CLI	Aufruf eines installierten Kommandozeilenprogramms	Eine sichere Identität oder eingeschränkte Laufzeit
Computer Use	Bedienung der sichtbaren Anwendungsoberfläche	Einen stabilen API-Vertrag
Gehostete Tools	Eine vom Anbieter betriebene Fähigkeit wie Suche	Gleiche Funktionen, Kosten oder Aufbewahrung bei jedem Anbieter
Sub-Agenten	Delegation eines Teils der Arbeit	Kostenlose Parallelität oder automatisch bessere Ergebnisse
Skills	Wiederverwendbare Anleitungen und Hilfsmittel	Zugriff auf Systeme, für die bisher keine Berechtigung besteht

1. Function Calling#

Die Anwendung beschreibt eine Operation und ihre Argumente. Das Modell fordert sie an. Dein Code validiert die Anfrage, prüft den Zugriff und führt sie aus. Ein Schema kann die Form der Argumente begrenzen. Es entscheidet nicht, ob dieser Benutzer dieses Gerät neu starten darf.

Für eine kleine Anwendung mit wenigen internen Operationen würde ich hier beginnen. Eine Funktion wie get_device_compliance(device_id) kann beispielsweise eine begrenzte, lesende Antwort liefern, ohne dem Agenten eine breite Verwaltungs-API zur Verfügung zu stellen.

2. MCP — Model Context Protocol#

MCP ist interessant, wenn mehrere kompatible Agenten-Hosts dieselbe Fähigkeit nutzen sollen. Der Client wird vom Server getrennt, der Tools, Ressourcen oder Prompts anbietet. Diese Wiederverwendung kann einen eigenen Dienst rechtfertigen. Drei private Hilfsfunktionen brauchen nicht automatisch einen MCP-Server.

Bei entfernten HTTP-Servern musst du Authentifizierung konfigurieren und prüfen. MCP erteilt keine Berechtigungen. Die Spezifikation beschreibt ein OAuth-basiertes Verfahren, verlangt aber nicht für jede Implementierung eine Autorisierung. Prüfe den unterstützten Anmeldeablauf, die Token-Audience, Scopes und die Zugriffsprüfungen des Servers. MCP-Autorisierung.

Meine Architekturfrage lautet: Wer ist für diese Operation verantwortlich, und wer darf sie aufrufen? Eine erfolgreiche Verbindung beweist weder korrekte Mandantentrennung noch angemessene Schreibrechte.

3. CLI-Tools#

Ein Agent im Terminal hat häufig bereits Zugriff auf az, gh oder PowerShell. Befehle mit nachvollziehbaren Exitcodes und strukturierten Ausgaben können eine praktische Integration sein. Darum geht es auch in meinem Vergleich von CLI-Tools und MCP.

Ein guter Prompt reicht trotzdem nicht. Ich würde Konto, Tenant, Subscription, Arbeitsverzeichnis und Tool-Version prüfen. Für Untersuchungen zunächst nur Lesezugriff verwenden. Eine CLI übernimmt nicht automatisch die Berechtigungsgrenzen, die du für den Agenten im Kopf hast.

Ein engerer Dienst oder Wrapper kann weiterhin sinnvoll sein: etwa für einheitliche Ausgaben, zentrale Richtlinien oder wenige klar definierte Funktionen. Wiederverwendung und uneingeschränkter Shell-Zugriff sind zwei verschiedene Entscheidungen.

4. Computer Use#

Computer Use arbeitet über die Oberfläche einer Anwendung, beispielsweise mit Screenshots oder anderen unterstützten UI-Informationen. Das hilft bei Abläufen, die nur dort verfügbar sind. Es passt auch, wenn ausdrücklich die Bedienung eines Portals gezeigt werden soll.

Dafür hängt der Ablauf von Layouts, Ladezuständen und Dialogen ab. Ich würde den konkreten Prozess testen, statt jede UI-Aufgabe pauschal als zu langsam oder unzuverlässig einzuordnen. Bei folgenreichen Aktionen gehören Freigaben und eine Prüfung des gespeicherten Ergebnisses dazu. Ein Klick ist noch kein Nachweis, dass die Änderung wirksam wurde.

Text auf einer Webseite ist Eingabe, keine neue Anweisung, die den Benutzerauftrag überschreiben darf. Auch Aufzeichnungen brauchen Aufmerksamkeit: Ein hilfreicher Screenshot kann Kundendaten enthalten.

5. Gehostete Tools#

Vom Anbieter betriebene Tools können dir den eigenen Betrieb einer Suche oder Ausführungsumgebung ersparen. Prüfe die einzelne Fähigkeit: Dateitypen, Quellenangaben, Grenzen, Aufbewahrung und Zusatzkosten unterscheiden sich.

Ein Datei-Upload ist nicht dasselbe wie eine Suche über diese Datei. Eine Files API kann Dateien verwalten, ohne daraus einen indexierten Suchdienst zu machen. Google dokumentiert beispielsweise File Search als eigene verwaltete Retrieval-Funktion. Gemini File Search.

Ich würde eine gehostete Lösung zuerst an den Anforderungen messen. Eigenentwicklung ist sinnvoll, wenn notwendige Kontrolle fehlt – nicht allein deshalb, weil das Projekt wichtig ist.

6. Sub-Agenten#

Delegation kann bei unabhängigen Teilaufgaben, getrenntem Kontext oder engeren Tool-Berechtigungen helfen. Ein Handoff, der die Steuerung übergibt, ist nicht zwingend dasselbe wie ein Agentenaufruf, der ein Ergebnis zurückliefert.

Mein Ausgangspunkt wäre trotzdem ein Agent mit einer klaren Aufgabe. Aufteilen würde ich für einen konkreten Nutzen: eine separate Prüfung, begrenzte Recherche oder parallele Arbeit mit unabhängigen Ergebnissen. Miss zusätzlichen Verbrauch, Laufzeit und Abstimmungsfehler. Die Anzahl der Agenten ist kein Qualitätsmaß.

7. Skills richtig einordnen#

Dateibasierte Agent Skills sind Pakete mit SKILL.md und optionalen Skripten, Referenzen oder Assets. Die Beschreibung hilft einem kompatiblen Agenten, passende Anleitungen zu erkennen. Das Paket beschreibt eine wiederholbare Arbeitsweise; es ist kein Netzwerk-Endpunkt. Agent-Skills-Spezifikation.

Auch Codex unterstützt dieses Muster. Skills können Anweisungen, Skripte und Referenzen kombinieren und gemeinsam mit MCP-Tools arbeiten. Skills als reine Claude-Funktion darzustellen wäre falsch. Codex-Anpassungen und Skills.

Andere Produktkonzepte müssen davon getrennt bleiben. Ein deklarativer Microsoft-365-Agent, ein Custom Engine Agent, ein Semantic-Kernel-Plugin und ein Skill-Paket sind keine austauschbaren Typen. Kläre, was verpackt wird: Anleitungen, ausführbare Operationen, ein Agent oder eine vollständige Benutzererfahrung.

Begriffe der Anbieter im Vergleich#

Die Tabelle zeigt Beispiele, keine Funktionsgleichheit. Produktpläne, Modellunterstützung und verfügbare Tool-Typen musst du weiterhin prüfen.

Ökosystem	Beispiele, die getrennt werden sollten	Wichtige Korrektur
Anthropic	Claude-Code-Skills, Tool Use, Claude Agent SDK	Ein Skill ist nicht dasselbe wie ein API-Tool
OpenAI	Codex Skills, Function Calling, Agents SDK	Codex hat Skills; Custom GPTs sind ein anderes Produktkonzept
Microsoft	Foundry-Agenten, Copilot-Studio-Agenten, Microsoft-365-Agententypen	Nicht jeden Agenten oder jedes Plugin als Skill bezeichnen
Google	Gemini-Tools und Agent Development Kit	Google hat ein eigenes Agenten-SDK

Googles offizielles ADK-Repository beschreibt das codebasierte Agenten-Toolkit. Vergleiche die benötigte Funktion, nicht nur ähnliche Produktnamen.

Meine Entscheidungshilfe am Intune-Beispiel#

Ein Support-Agent soll beantworten: „Warum ist dieses Gerät noch nicht compliant?“

1. Begrenzte Geräteinformationen abrufen. Eine typisierte Operation mit Lesezugriff reicht als Einstieg. MCP passt, wenn mehrere Agenten-Clients denselben Dienst verwenden sollen.
2. Den Untersuchungsablauf anwenden. Ein Skill kann Reihenfolge, benötigte Nachweise und Abbruchbedingungen definieren. Er gewährt keine zusätzlichen Microsoft-Graph-Rechte.
3. Vorhandene Werkzeuge gezielt verwenden. In einem Entwicklerablauf kann ein kontrollierter PowerShell- oder CLI-Befehl reichen. Liefere die relevanten Nachweise zurück, nicht sämtliche Tenant-Objekte.
4. Das Portal nutzen, wenn die Oberfläche das Ziel ist. In einem Live-Walkthrough zeige ich die passende Geräteansicht. Für unbeaufsichtigte Abläufe würde ich eine stabile unterstützte Schnittstelle bevorzugen, sofern vorhanden.
5. Behebung getrennt behandeln. Ein vorgeschlagener Fix ist keine Erlaubnis zur Ausführung. Schreiboperationen brauchen passende Grenzen und gegebenenfalls eine Freigabe.

Das sind keine vier konkurrierenden Architekturen, sondern ein Ablauf mit getrennten Anleitungs-, Integrations- und Ausführungsebenen.

Fehler, die ich vermeiden würde#

• Ein Skill als Sicherheitsgrenze. Anleitungen steuern das Verhalten; Identitäten und serverseitige Prüfungen setzen Zugriff durch.
• Ein Protokoll als Kompatibilitätsgarantie. Teste Host, Transport, Anmeldung und tatsächliches Tool-Verhalten.
• Ein Upload als Suchlösung. Indexierung, Retrieval, Quellenangaben und Lebenszyklus separat prüfen.
• Zu viele Tools ohne klaren Nutzen. Mit wenigen passenden Funktionen starten und Auswahlfehler auswerten.
• Eine Aktion als fertiges Ergebnis. Zustand erneut lesen, Fehler erfassen und Nachweise prüfbar machen.

Für einen Repository-Workflow zeigt mein Claude Code GitHub Actions Guide Trigger, Anmeldung und einen begrenzten Einstieg. Die Plattformentscheidung erläutert der Vergleich von Copilot, Copilot Studio und eigenen Agenten.

Was ich daraus mitnehme#

Die Arbeitsweise als Anleitung verpacken, nur die benötigten Operationen bereitstellen und die passende Ausführungsschnittstelle wählen. Kombiniere diese Bausteine mit einem konkreten Grund. Teste außerdem, was bei einem Tool-Fehler oder fehlenden Rechten passiert.

Die ursprüngliche Übersicht aus Mai 2026 bleibt unten erhalten. Ihre Anbieterbezeichnungen sind historisch. Für aktuelle Entscheidungen gelten die korrigierten Unterscheidungen oben, nicht die Grafik als vermeintlich aktuelle Supportmatrix.

Stay healthy, Cheers Jannik