11. Oktober 2026 · 10 Min.

Tools reichen nicht: Skills machen Agenten arbeitsfähig

Cloudflare liefert seit dem 10. Oktober Arbeitsanweisungen zusammen mit seinem MCP-Server aus. Was Skills over MCP für zuverlässige Agenten, Sicherheit und messbare Automatisierung bedeutet.

Tools reichen nicht: Skills machen Agenten arbeitsfähig

Ein Werkzeugkasten ist noch kein Arbeitsprozess

Viele Agentenprojekte beginnen mit derselben Demo: Das Modell sieht zehn Tools, wählt eines davon und erzeugt ein beeindruckendes Ergebnis. Im Alltag folgt dann die Ernüchterung. Der Agent kennt zwar die API, aber nicht die Reihenfolge der Schritte, die Ausnahmen des Teams, die notwendige Prüfung oder den Punkt, an dem ein Mensch übernehmen muss.

Am 10. Oktober 2026 hat Cloudflare seinem API-MCP-Server deshalb eine interessante zweite Ebene hinzugefügt. Unterstützte Clients können jetzt über skills/list passende Skills entdecken und deren Dateien als skill://-Ressourcen lesen. Neben der technischen Fähigkeit — etwa einen Worker zu deployen oder eine Zone zu konfigurieren — reist damit auch eine strukturierte Arbeitsanweisung.

Das klingt nach einem kleinen Protokoll-Detail. Für produktive Automatisierung ist es ein wichtiger Architekturwechsel: Ein Tool beschreibt, was ein System ausführen kann. Ein Skill erklärt, wie ein konkretes Ziel mit diesen Fähigkeiten sicher und wiederholbar erreicht wird.

Tool, Ressource und Skill haben verschiedene Aufgaben

Die Begriffe sollten nicht vermischt werden:

Tools sind ausführbare Aktionen mit klaren Ein- und Ausgaben.
Resources liefern Daten oder Dokumente, ohne selbst einen Arbeitsablauf festzulegen.
Skills enthalten Workflow-Wissen: Voraussetzungen, Reihenfolge, Grenzen, Prüfungen und Recovery.

Ein gutes Tool für ein Deployment nimmt zum Beispiel Projekt, Artefakt und Umgebung entgegen. Der dazugehörige Skill beschreibt zusätzlich, wie das Artefakt gebaut wird, welche Smoke-Tests vor der Veröffentlichung laufen, wann ein Preview statt Produktion gewählt wird und wie bei einem Fehler zurückgerollt wird.

Diese Trennung hält die API klein. Statt zwanzig leicht verschiedene „Deploy mit unserer Methode“-Tools zu bauen, bleibt die Aktion stabil und die Arbeitsweise wird als versionierbare Anleitung gepflegt.

Was die neue Erweiterung tatsächlich standardisiert

Die stabile Skills-over-MCP-Erweiterung heißt io.modelcontextprotocol/skills. Ein Server kündigt sie bei der Capability-Negotiation an. Danach stehen zwei verpflichtende Methoden und eine optionale zur Verfügung:

skills/list liefert die angebotenen Skills, gegebenenfalls paginiert.
skills/get holt den aktuellen Eintrag eines einzelnen Skills über dessen URI.
resources/directory/read kann Verzeichnisse auflisten, wenn der Server directoryRead unterstützt.

Ein Skill besitzt mindestens eine SKILL.md mit Name und Beschreibung. Weitere Referenzen, Skripte, Beispiele oder Assets können danebenliegen. Die Dateien werden nicht als undurchsichtiges Archiv übertragen, sondern einzeln über die bestehende resources/read-Mechanik gelesen.

Der Listeneintrag enthält außerdem ein Manifest aus URI, Dateigröße und SHA-256-Digest. Pro Skill sind maximal 512 Ressourcen und insgesamt 16 MiB vorgesehen. Das begrenzt den Umfang und ermöglicht es dem Host, gelesene Dateien gegen den zuvor gesehenen Stand zu prüfen.

Progressive Disclosure hält den Kontext klein

Ein Agent muss nicht bei jeder Aufgabe sämtliche Runbooks, Beispiele und Templates laden. Zuerst reichen Name und Beschreibung, um einen passenden Skill auszuwählen. Die SKILL.md wird erst beim Aktivieren gelesen; unterstützende Dateien folgen nur bei Bedarf.

Das ist mehr als Token-Sparen. Es verhindert, dass irrelevante Anweisungen miteinander konkurrieren. Ein Abrechnungs-Workflow braucht nicht gleichzeitig die Regeln für DNS-Migration, Log-Analyse und Bildoptimierung im Kontext.

Für Skill-Autoren folgt daraus eine klare Struktur:

Die Beschreibung muss präzise auslösen, wann der Skill passt — und wann nicht.
Die SKILL.md enthält den kürzesten vollständigen Hauptweg.
Detailwissen wandert in benannte Referenzen.
Skripte automatisieren deterministische Arbeit, statt sie vom Modell neu erfinden zu lassen.
Beispiele zeigen reale Ein- und Ausgaben, nicht nur einen glücklichen Demo-Fall.

Ein Skill braucht eine überprüfbare Definition von „fertig“

Schwache Skills sind lange Prompts mit freundlichen Formulierungen. Starke Skills bilden einen Ablauf ab, den ein erfahrener Kollege tatsächlich prüfen könnte.

Für jeden produktiven Skill sollten mindestens diese Fragen beantwortet sein:

Welche Eingaben müssen vorliegen?
Welche Systeme und Berechtigungen sind erlaubt?
Welche Schritte sind deterministisch, welche brauchen Modellurteil?
Welche Zwischenstände werden geprüft?
Welche Nebenwirkungen benötigen Bestätigung?
Was gilt als Erfolg?
Wie wird ein Teilfehler erkannt und behandelt?
Welche Informationen dürfen niemals in Logs oder Modellkontext landen?

Ein Content-Publishing-Skill endet beispielsweise nicht bei „Artikel hochladen“. Fertig bedeutet: beide Sprachen vorhanden, Links valide, Bildformat korrekt, Build erfolgreich, Preview geprüft, Veröffentlichung bestätigt und URL erreichbar. Diese Definition macht den Unterschied zwischen Textgenerierung und einem belastbaren Veröffentlichungsprozess.

Remote Skills sind nicht automatisch vertrauenswürdig

Die offizielle Spezifikation ist an diesem Punkt erfreulich deutlich: Skill-Inhalte sind untrusted input und eine Prompt-Injection-Fläche. Ein verbundener Server wird nicht dadurch zur Autorität, dass er neben Tools auch Anweisungen liefert.

Ein Host muss deshalb die Herkunft sichtbar halten und remote geladene Skills anders behandeln als lokale Teamregeln. Besonders wichtig sind vier Grenzen:

Ein Remote Skill darf nicht still einen gleichnamigen lokalen Skill überschreiben.
Er darf keine zusätzlichen Tool- oder Dateisystemrechte über allowed-tools erzwingen.
Host-seitige Codeausführung benötigt eine explizite Freigabe pro Skill.
Ressourcen eines Skills bleiben an seinen Ursprungsserver gebunden; ein Skill von Server A darf nicht unbemerkt bei Server B lesen.

Auch verschachtelte Skills erben keine Zustimmung. Wird innerhalb eines freigegebenen Skills ein weiterer Skill entdeckt, braucht dieser eine eigene Aktivierung. Das ist unbequem — und genau deshalb eine sinnvolle Sicherheitsgrenze.

Digests beweisen Konsistenz, nicht Vertrauen

Das Manifest erlaubt eine wichtige Prüfung: Stimmen Größe und SHA-256-Digest der gelesenen Datei nicht mit dem Listeneintrag überein, darf der Host den Inhalt nicht verwenden. Ändert sich der Ressourcensatz, muss eine daran gebundene Zustimmung widerrufen und erneut eingeholt werden.

Trotzdem ist ein passender Digest kein Gütesiegel. Manifest und Inhalt kommen vom selben Server. Ein bösartiger Server oder ein kompromittierter Vermittler kann beides gemeinsam verändern. Der Digest beweist, dass die gelesenen Bytes zum angekündigten Snapshot passen — nicht, dass die Anleitung sicher, sinnvoll oder vom behaupteten Autor stammt.

Für Teams bedeutet das: Herkunft, Review und Berechtigung bleiben organisatorische Aufgaben. Technische Integrität ersetzt keine Lieferketten-Entscheidung.

Wo Skill-Wissen leben sollte

Nicht jede Regel gehört auf denselben Server. Wir teilen Skill-Wissen in drei Schichten:

Anbieterwissen liegt beim MCP-Server: aktuelle API-Eigenheiten, erlaubte Parameter, sichere Reihenfolgen und produktspezifische Recovery-Schritte.
Teamwissen liegt in eigenen, reviewbaren Skills: Namenskonventionen, Qualitätsgates, Freigaben und Betriebsregeln.
Auftragskontext kommt zur Laufzeit: das konkrete Projekt, die Umgebung und das gewünschte Ergebnis.

Ein Cloudflare-Skill kann erklären, wie ein Worker korrekt mit Bindings und Streaming gebaut wird. Er sollte aber nicht entscheiden, welche Produktionszone das MÖWE-Team ohne Rückfrage verändern darf. Diese Grenze gehört in unsere eigene Policy und den menschlichen Approval-Schritt.

Wer alles in einen riesigen Universal-Skill schreibt, koppelt Anbieteränderungen, interne Governance und einzelne Aufgaben wieder zusammen. Kleine Skills mit klarer Zuständigkeit lassen sich leichter testen und ersetzen.

Skills brauchen Releases wie Code

Arbeitsanweisungen verändern Produktionsverhalten. Deshalb brauchen sie denselben Lebenszyklus wie Software:

eindeutige Owner;
Review vor Veröffentlichung;
nachvollziehbare Änderungen;
Testfälle für normale und gefährliche Pfade;
stufenweisen Rollout;
Rückkehr zu einem bekannten Stand.

Die MCP-Erweiterung bindet Zustimmung an URIs und Digests, aber sie definiert kein Produkt-Versionsschema für die Bedeutung eines Skills. Ein Team sollte deshalb selbst festlegen, wie Breaking Changes gekennzeichnet werden und wie lange alte Abläufe unterstützt bleiben.

Besonders riskant sind still geänderte Grenzwerte, neue Schreibaktionen und weitere erlaubte Systeme. Solche Änderungen dürfen nicht als Textkorrektur durchrutschen. Sie verändern den Blast Radius des Agenten.

Erfolg misst man am Ablauf, nicht am schönen Output

Ob ein Skill hilft, zeigt kein einzelner Screenshot. Ein kleines Eval-Set sollte wiederkehrende Aufgaben und problematische Randfälle enthalten. Sinnvolle Metriken sind:

Anteil vollständig erledigter Aufgaben;
Zahl unnötiger oder falscher Tool-Aufrufe;
Verstöße gegen Reihenfolge und Freigaben;
menschliche Korrekturen bis zum fertigen Ergebnis;
Recovery-Quote nach Teilfehlern;
Kontextverbrauch und Laufzeit;
Regressionen nach einer Skill-Änderung.

Verglichen werden mindestens drei Varianten: Tools ohne Skill, Tools mit aktuellem Skill und Tools mit der geplanten neuen Version. Erst wenn die neue Anleitung messbar besser oder sicherer arbeitet, gehört sie in den Standardpfad.

Ein pragmatischer Einstieg

Cloudflares Start zeigt, wohin sich MCP entwickelt, aber die Client-Unterstützung ist noch nicht überall vollständig. Die öffentliche Implementierungsmatrix führt einige Hosts bereits als v1 oder partial, während mehrere offizielle SDK-Integrationen noch in Arbeit sind. Vor dem Rollout muss daher geprüft werden, ob der eigene Host Extension-Negotiation, skills/list, skills/get, Digest-Verifikation und Approval wirklich umsetzt.

Für ein erstes Projekt empfehlen wir:

einen häufigen, klar begrenzten Workflow auswählen;
Tool-Aktionen und Prozesswissen sichtbar trennen;
eine kurze SKILL.md plus höchstens wenige gezielte Referenzen schreiben;
gefährliche Nebenwirkungen und menschliche Stopps explizit markieren;
zehn bis zwanzig reale Aufgaben als Eval-Set sammeln;
den Skill nur für ein Team oder eine Umgebung aktivieren;
Fehler, Freigaben und manuelle Korrekturen messen;
erst nach einem nachweisbaren Gewinn weitere Workflows übertragen.

Der entscheidende Fortschritt ist nicht, dass Agenten noch mehr Dokumentation lesen können. Er liegt darin, Fähigkeiten und Arbeitsweise getrennt auszuliefern, beide unabhängig zu prüfen und Änderungen kontrolliert in Betrieb zu nehmen. Ein Agent mit Tools kann handeln. Ein gut geführter Agent mit Skills kann Arbeit verlässlich zu Ende bringen.