Eine MCP-Tool-Beschreibung ist ein Satz zu einer einzelnen aufrufbaren Funktion:
was sie tut, was sie entgegennimmt, ob sie etwas verändert. Sie reist mit jeder
Anfrage mit, die der Client an das Modell schickt, zusammen mit den
Beschreibungen aller anderen Tools. Ein Skill ist ein Ordner mit einer Datei
SKILL.md darin, in der eine Prozedur steht — mach dies, prüf dann jenes, frag
vor dieser einen Sache nach — und sein Rumpf wird erst geladen, sobald das
Modell entscheidet, dass Ihre Anfrage dazu passt.
Das ist der ganze Unterschied, und es ist ein Unterschied darüber, wann der Text im Kontext steht, nicht darüber, was er sagt. Beschreibungen sind der Eintrittspreis: Sie zahlen für alle, in jeder Runde, für immer. Die Anweisungen eines Skills sind kostenlos, solange sie nicht relevant sind. Deshalb ist ein Absatz, der in einer Tool-Beschreibung nicht zu rechtfertigen wäre — dreihundert Wörter darüber, wie man einen Stapel liegengebliebener Meeting-Aufnahmen abarbeitet — in einem Skill völlig angemessen.
In diesem Artikel geht es darum, zu entscheiden, welche Ihrer Anweisungen wohin gehört. Falls Ihnen das Protokoll selbst neu ist: was ein MCP-Server ist klärt zuerst das Vokabular, und MCP im Vergleich zu Plugins und Integrationen zeigt, wo MCP im Verhältnis zu den älteren Wegen steht, Dinge miteinander zu verbinden.
In der MCP-Spezifikation ist eine Tool-Definition eine kleine, feste Form. Sie
trägt einen name, einen optionalen menschenlesbaren title, eine
description, ein inputSchema, das die Argumente beschreibt, ein optionales
outputSchema und annotations — optionale Eigenschaften, die das Verhalten des
Tools beschreiben, etwa ob es nur liest. Der Client holt die gesamte Liste mit
einem tools/list-Aufruf ab und legt sie dem Modell vor; genau das macht
MCP-Tools modellgesteuert: Das Modell wählt eines anhand des Gesprächs aus.
Diese Form ist in genau einer Sache gut: einem Modell zu sagen, was ein einzelner Aufruf tut, damit es den richtigen wählt. In drei anderen Dingen ist sie strukturell schlecht.
Sie kann keine Reihenfolge beschreiben. Nichts in einer Tool-Definition kann
sagen: „Rufe list_channels vor share_to_channel auf, weil der Kanal
existieren muss und der Nutzer ihn auswählen muss.“ Jede Beschreibung ist eine
Insel.
Sie kann nicht viel fassen. Jede Beschreibung steht bei jeder Anfrage in jedem Gespräch im Kontext, auch in all den Gesprächen, die dieses Tool nie berühren werden. Ein Server mit fünfzehn Tools und einem Absatz je Tool hat einen spürbaren Teil des Kontextfensters ausgegeben, bevor der Nutzer überhaupt etwas getippt hat.
Sie kann Ihr Urteilsvermögen nicht abbilden. „Versieh die Aufnahme mit einem Tag, statt sie zu teilen, wenn du dir nicht sicher bist, wer sie sehen sollte“ ist eine Richtlinie und keine Beschreibung einer Funktion. Zwei verschiedene Teams wollen aus demselben Tool zwei verschiedene Richtlinien.
Ein Ventil gibt es im Protokoll: Ein Server darf beim Verbindungsaufbau eine
instructions-Zeichenkette zurückgeben, die der Client dem System-Prompt
hinzufügen darf — noch vor der Tool-Liste. Das ist der richtige Ort für eine
kurze Orientierung: was dieser Server ist, woran er hängt, womit man vorsichtig
sein sollte. Zwei Einschränkungen. Es ist weiterhin Text pro Sitzung, bleibt also
kurz. Und die Spezifikation sagt, dass Clients ihn verwenden dürfen, nicht dass
sie es müssen — wie weit er dem Modell tatsächlich gezeigt wird, unterscheidet
sich daher von Client zu Client.
Ein Skill ist ein Verzeichnis mit einer Datei SKILL.md: YAML-Frontmatter mit
einem name und einer description, danach Anweisungen in Markdown. Daneben
kann Weiteres liegen — scripts/ für ausführbaren Code, references/ für
ausführliche Dokumentation, assets/ für Vorlagen — und der Agent zieht das nur
heran, wenn die Anweisungen ihn dorthin schicken.
Das Lademodell heißt progressive disclosure, schrittweise Offenlegung, und die Spezifikation beschreibt es in drei Stufen:
name und description jedes
verfügbaren Skills — veranschlagt sind dafür rund 100 Tokens pro Skill. Genug,
um zu wissen, wann er relevant sein könnte, und nicht mehr.SKILL.md in den Kontext. Empfohlen wird, dabei unter
etwa 5.000 Tokens zu bleiben und die Hauptdatei unter 500 Zeilen zu halten.Zwanzig installierte Skills kosten also zwanzig kurze Beschreibungen. Zwanzig lange Tool-Beschreibungen kosten zwanzig lange Tool-Beschreibungen, in jeder Runde. Diese Asymmetrie ist der Grund, warum es diese Schicht gibt.
Das Format ist nicht an einen Client gebunden. Agent Skills wurde von Anthropic
entwickelt und als offener Standard veröffentlicht, publiziert auf
agentskills.io; die Client-Übersicht dort listet Dutzende Produkte, die
denselben Ordner lesen, darunter Claude Code, Claude, ChatGPT und Codex, Cursor,
VS Code, GitHub Copilot, Gemini CLI, Goose, Roo Code, Kiro, Junie, Amp, Factory,
Tabnine, Snowflake Cortex Code und Databricks Genie Code. Geprüft am 14. August
2026.
Das erforderliche Frontmatter ist bewusst dünn. name umfasst bis zu 64 Zeichen,
Kleinbuchstaben, Ziffern und Bindestriche, und muss dem Namen des übergeordneten
Verzeichnisses entsprechen. description umfasst bis zu 1.024 Zeichen und sollte
sowohl sagen, was der Skill tut, als auch wann er zu verwenden ist — denn diese
Zeichenkette ist die gesamte Grundlage, auf der ein Agent entscheidet, ob er die
Datei öffnet. Optionale Felder sind license, compatibility, metadata und
das experimentelle allowed-tools.
Dieses Beschreibungsfeld verdient mehr Sorgfalt, als ihm gemeinhin zuteilwird. „Hilft bei Meeting-Notizen“ wird nie zuverlässig passen; „sichtet und ordnet neue Aufnahmen — vergibt Tags, benennt die Sprecher, teilt jene, die in einen Team-Kanal gehören; zu verwenden, wenn der Nutzer aufräumen, sortieren oder aufholen möchte“ schon.
Zwischen den Beschreibungen pro Aufruf und den bedarfsweise geladenen Skills sitzt eine Schicht, die keines von beidem ist: Dateien, die ein Agent zu Beginn einer Sitzung liest, unabhängig davon, wonach Sie gefragt haben.
AGENTS.md ist die schlichteste Variante — Standard-Markdown, keine Pflichtfelder, gelesen aus der nächstgelegenen Datei im Verzeichnisbaum aufwärts. Die eigene Website meldet Verwendung in über 60.000 Open-Source-Projekten und listet Unterstützung in OpenAI Codex, Google Jules und Gemini CLI, Claude-Agenten, dem Coding-Agenten von GitHub Copilot, Aider, VS Code, Cursor, Zed, Warp, Factory, goose, Roo Code, Devin und Junie. Geprüft am 14. August 2026.
Cursor-Regeln sind dieselbe Idee mit einem Schalter daran. Sie liegen in
.cursor/rules als .mdc-Dateien, und drei Frontmatter-Felder entscheiden, wann
eine davon einbezogen wird: alwaysApply: true bringt sie in jede Chat-Sitzung;
eine description lässt den Agenten die Relevanz beurteilen; globs hängen sie
an, wenn eine passende Datei geöffnet ist; und ist nichts davon gesetzt, kommt
die Regel nur, wenn Sie sie mit @ erwähnen. Cursor unterstützt außerdem
AGENTS.md und inzwischen auch Agent Skills direkt — Skills liegen in
.cursor/skills/ oder .agents/skills/ — samt einem Migrationswerkzeug, das
geeignete dynamische Regeln und Slash-Befehle in Skills umwandelt. Geprüft am
14. August 2026.
Lesen Sie diese beiden Absätze noch einmal, und das Muster ist klar: die
Formate sind zusammengewachsen, die Lademodelle nicht. Alle lesen inzwischen
SKILL.md. Aber eine alwaysApply-Regel und ein Block in AGENTS.md gelten für
die Sitzung, ein Skill gilt für die Aufgabe, und keine noch so große
Formatkompatibilität ändert daran etwas.
Die praktische Folge ist eine Faustregel, die mehr wert ist als die Formatdetails:
| Wohin es gehört | Was dort hingehört | Was es kostet |
|---|---|---|
Tool-description |
Ein Satz: was dieser Aufruf tut, was er verändert | Jede Anfrage, für immer |
Server-instructions |
Eine kurze Orientierung zum ganzen Server | Jede Sitzung an diesem Server |
AGENTS.md, immer geltende Regeln |
Fakten, die für jede Aufgabe in diesem Repository gelten | Jede Sitzung in diesem Projekt |
SKILL.md |
Prozeduren, Richtlinien, ausgearbeitete Beispiele, Urteilsvermögen | Nur wenn die Aufgabe passt |
Alles Lange, alles Bedingte, alles, was nur manchmal zutrifft: Skill. Der Fehler,
in den Leute laufen, ist, hundertfünfzig Zeilen produktspezifischer Prozedur in
eine globale AGENTS.md zu schreiben, wo sie im Kontext liegen, während man den
ganzen Nachmittag an einem völlig anderen Backend arbeitet.
Speak-Y liefert einen MCP-Server mit, und der ist ein brauchbares Beispiel, weil beide Schichten sichtbar verschiedene Aufgaben erfüllen.
Die Tool-Beschreibungen decken die Aufrufe ab: Aufnahmen durchsuchen, ein
Transkript, eine Zusammenfassung oder die Action Items lesen, Kanäle und Tags
auflisten — und, bei laufender App, eine Aufnahme taggen, einen Sprecher
umbenennen, ihr einen neuen Titel geben, sie neu transkribieren oder sie in einen
Team-Kanal einsortieren. Jede trägt eine Annotation, die sagt, ob sie liest oder
verändert; das erlaubt einem Client, vor den verändernden nachzufragen, und macht
--read-only zu einem einzigen Schalter statt zu einer Liste von Tool-Namen, die
man sich merken muss. Gelesen wird lokal aus der Bibliothek auf Ihrem Rechner;
die verändernden Befehle laufen über die laufende App und werden dort
protokolliert, wie was Schreibzugriff sicher macht
genauer beschreibt.
Der Skill deckt die Arbeit ab. Wenn Sie die Integration unter
Einstellungen → Integrationen installieren, legt Speak-Y neben der
Server-Konfiguration einen Organizer-Skill ab: wo man anfängt, wenn ein Stapel
Aufnahmen zu sichten ist, wann ein Tag die richtige Antwort ist und wann ein
Kanal, welche Aktionen vor dem Ausführen zu bestätigen sind. Beschreibungen
könnten das nicht fassen, und die instructions-Zeichenkette des Servers sollte
es gar nicht erst versuchen.
Er ist außerdem so geschrieben, wie das Lademodell es belohnt. Eine ausführliche
Datei liegt an einer Stelle, und jeder Client bekommt einen kurzen Verweis darauf
in dem Format, das er liest — eine SKILL.md für Claude Code, eine
.mdc-Regel für Cursor, einen markierten Block in AGENTS.md für Codex, einen
markierten Block in GEMINI.md für Gemini CLI. Die sitzungsweit ladenden Clients
bekommen genau deshalb nur einen Verweis: Hundertfünfzig Zeilen über
Meeting-Notizen sollten nicht im Kontext liegen, während Sie das Backend eines
anderen debuggen. Die Blöcke stehen zwischen Markern, sodass eine Neuinstallation
nur diesen Abschnitt ersetzt und den Rest der Datei unangetastet lässt.
Der MCP-Server selbst ist in jedem Tarif kostenlos, auch in Free. Die Installation mit einem Klick und die manuelle Konfiguration für jeden Client sind unter KI-Assistenten (MCP) dokumentiert.
Drei Fragen, in dieser Reihenfolge.
Beschreibt die Anweisung einen einzelnen Aufruf? Dann ist sie eine Tool-Beschreibung und sollte aus ein bis zwei Sätzen bestehen. Wenn Sie einen dritten schreiben, haben Sie einen Skill gefunden.
Gilt sie für jede Sitzung, unabhängig von der Aufgabe? Dann kann sie in
AGENTS.md oder in eine immer geltende Regel — aber prüfen Sie den Teil
„unabhängig von der Aufgabe“ ehrlich. „Dieses Repository verwendet pnpm“ erfüllt
das. „Hier ist unser Prozess zum Sichten von Meetings“ nicht.
Beschreibt sie eine Prozedur mit Schritten, Entscheidungen oder Ausnahmen?
Skill. Nehmen Sie name und description ernsthaft unter die Lupe, denn diese
beiden Zeichenketten erledigen das gesamte Routing, und schreiben Sie alles
Längere in eine Datei in references/ neben der SKILL.md statt in sie hinein.
Machen Sie es in die billige Richtung falsch, hat Ihr Agent einen aufgeblähten Kontext und trifft bei jeder unbeteiligten Frage schlechter. Machen Sie es in die teure Richtung falsch — Prozedur in Tool-Beschreibungen gequetscht —, dann liest das Modell Ihre Richtlinie in jeder Runde und befolgt sie womöglich trotzdem nicht, weil eine Beschreibung als Dokumentation einer Funktion gelesen wird und nicht als Anweisung, der zu folgen ist.
Wenn Sie den Unterschied konkret sehen wollen, ist der schnellste Test, einen Skill für eine Aufgabe zu schreiben, die Sie tatsächlich wiederholen, und ihn mit den Prompts zu vergleichen, die Sie vorher hineinkopiert haben. 20 Prompts für den KI-Assistenten zu Ihren Meetings ist eine brauchbare Quelle für Kandidaten: Was Sie mehr als zweimal ausführen, gehört in eine Datei.
Eine Tool-Beschreibung ist ein Satz zu einer einzelnen aufrufbaren Funktion, geschrieben vom Autor des Servers und als Teil der Tool-Liste bei jeder Anfrage an das Modell mitgeschickt. Ein Skill ist ein Ordner mit einer Datei SKILL.md, in der eine Prozedur steht — mehrere Schritte, mehrere Tools, Ermessensentscheidungen — und bis das Modell entscheidet, dass die Aufgabe dazu passt, stehen nur sein Name und seine Beschreibung im Kontext. Beschreibungen beantworten „was tut dieser Aufruf“; Skills beantworten „wie erledige ich diese Arbeit“.
Für Aufgaben mit einem einzigen Aufruf nicht. Sie brauchen einen, wenn eine Arbeit mehrere Tools in einer bestimmten Reihenfolge verlangt, wenn die richtige Wahl zwischen zwei Tools von Kontext abhängt, den die Beschreibungen nicht tragen können, oder wenn dieselbe Prozedur über Sitzungen hinweg identisch wiederholt werden soll. Gute Beschreibungen machen jeden einzelnen Aufruf richtig; ein Skill macht eine Folge von Aufrufen einheitlich.
Nein. Agent Skills wurde von Anthropic entwickelt und als offener Standard auf agentskills.io veröffentlicht, und die Client-Übersicht dort listet Dutzende Anwender — darunter Claude Code, ChatGPT und Codex, Cursor, VS Code, GitHub Copilot, Gemini CLI, Goose, Roo Code, Kiro, Junie und Factory. Geprüft am 14. August 2026.
AGENTS.md ist einfaches Markdown ohne Pflichtfelder, das ein Agent aus dem nächstgelegenen Verzeichnis im Baum liest, und es wird für die gesamte Sitzung geladen, unabhängig davon, wonach Sie gefragt haben. Der Rumpf eines Skills wird erst geladen, nachdem der Agent Ihre Anfrage mit dessen Beschreibung abgeglichen hat. Beides ist nützlich, aber alles Längere gehört in einen Skill, denn der Inhalt von AGENTS.md belegt Kontext in jeder Sitzung, auch in denen, die nichts damit zu tun haben.
Die Spezifikation von Agent Skills empfiehlt, die eigentliche SKILL.md unter 500 Zeilen und unter etwa 5.000 Tokens zu halten und ausführliches Referenzmaterial in eigene Dateien auszulagern, die der Agent nur bei Bedarf lädt. Für Name und Beschreibung sind rund 100 Tokens veranschlagt, denn dafür zahlt jede Sitzung.