Claude-Skills und MCP-Server-Entwicklung.

Ein guter Prompt ist eine einmalige Anweisung. Er lebt im Kopf oder in einer Textdatei der Person, die ihn geschrieben hat, und beim nächsten Mal ist er ein bisschen anders — mit einem entsprechend anderen Ergebnis.

Ein Skill ist dieselbe Sache, aber festgeschrieben, versioniert und für alle gleich. Euer Angebotsformat ist dann nicht mehr das, woran sich jemand erinnert, sondern das, was definiert ist. Das ist der Punkt, an dem aus einem netten Werkzeug ein verlässlicher Arbeitsschritt wird — mit demselben Ergebnis, egal wer ihn auslöst.

Ein Skill ist nur so nützlich wie das, worauf er zugreifen kann. Solange eine KI eure Kundendaten, eure Preisliste oder euren Dokumentenbestand nicht sieht, bleibt sie ein Textgenerator, dem man alles von Hand vorlegen muss.

Das Model Context Protocol ist die Schnittstelle dafür: ein MCP-Server macht ein internes System kontrolliert erreichbar — mit klar umrissenen Berechtigungen, statt einer KI pauschal Zugriff auf alles zu geben. Was gelesen werden darf, was geschrieben werden darf und was gar nicht sichtbar ist, wird an dieser Stelle entschieden und nicht dem Zufall überlassen.

• Claude Skills für eure wiederkehrenden Aufgaben und Formate
• MCP-Server: interne Systeme und Daten sicher für KI erreichbar machen
• Plugins und Bindings in eure bestehende Software
• Betrieb, Versionierung und Rechte — damit es nicht beim Prototyp bleibt

Ein beeindruckender Prototyp ist in diesem Feld schnell gebaut — das ist gerade das Verführerische daran. Was danach fehlt, ist das Unspektakuläre: Wer darf das benutzen? Was passiert, wenn sich das Format ändert? Wie merkt jemand, dass seit Dienstag etwas anderes herauskommt als vorher? Wer pflegt das, wenn der Enthusiast im Haus die Abteilung wechselt?

Genau diese Fragen entscheiden, ob so etwas nach einem halben Jahr noch benutzt wird. Deshalb gehören Versionierung, Rechte und ein nachvollziehbarer Betrieb bei mir zum Umfang und nicht in eine spätere Ausbaustufe.

Das Feld ist jung. Die Werkzeuge ändern sich schnell, und wer etwas anderes behauptet, verkauft euch Sicherheit, die es noch nicht gibt. Das ist ein Argument für kleine, abgegrenzte erste Schritte an einer Aufgabe, die wirklich weh tut — und gegen ein großes Programm, das eure halbe Organisation an eine Technologie bindet, die in achtzehn Monaten anders aussieht.

Es ist ausdrücklich kein Argument dagegen, jetzt anzufangen: Wer den ersten sauberen Schritt gemacht hat, kann den zweiten beurteilen. Wer wartet, muss später alles auf einmal lernen.