Die MCP-Werkzeuge von btlabs Core verbinden ein Sprachmodell kontrolliert mit Inhalten und begrenzten Systemfunktionen: Das Sprachmodell kann einen Werkzeugaufruf vorschlagen, der MCP-Client steuert Berechtigung und Freigabe, und der MCP-Server führt den autorisierten Aufruf aus. Entscheidend ist nicht allein die technische Verfügbarkeit, sondern welches Werkzeug für welchen Mandanten, welche Rolle und welchen Zweck freigegeben wurde.
Das Model Context Protocol (MCP) standardisiert die Verbindung zwischen Anwendungen mit Sprachmodellen und externen Daten oder Funktionen. In btlabs Core sollen MCP-Werkzeuge wiederkehrende Arbeit reduzieren, ohne Veröffentlichungen, Rechteänderungen oder andere folgenreiche Entscheidungen unkontrolliert auszulösen.
Ein Eintrag im Toolkatalog ist ein technisches Angebot. Erst eine passende Rechteklasse, ein zulässiger Zweck und ein dokumentierter Freigabestatus machen den konkreten Aufruf betrieblich erlaubt.
MCP-Werkzeuge in btlabs Core: Rollen und Ablauf
Die MCP-Architektur unterscheidet Host, Client und Server. Im herangezogenen Spezifikationsstand vom 28. Juli 2026 koordiniert der Host die Clients und Sicherheitsregeln. Jeder MCP-Client kommuniziert mit einem bestimmten MCP-Server, während der Server Werkzeuge und andere Funktionen bereitstellt.
- Sprachmodell: Das Modell interpretiert die Aufgabe und kann ein geeignetes Werkzeug vorschlagen. Das Sprachmodell stellt das Werkzeug nicht bereit und erteilt keine Berechtigung.
- Host: Die Anwendung koordiniert Sprachmodell, MCP-Clients, Benutzerinteraktion und Sicherheitsregeln.
- MCP-Client: Der Client verbindet den Host mit einem MCP-Server, verarbeitet den sichtbaren Toolkatalog und übermittelt zulässige Aufrufe.
- MCP-Server: Der Server stellt definierte MCP Tools bereit und führt Aufrufe innerhalb der erteilten Berechtigungen aus.
- Verantwortliche Person: Der Mensch prüft sensible oder folgenreiche Aktionen und bestätigt oder verweigert die Ausführung.
Ein kontrollierter Aufruf läuft in sieben Schritten ab:
- Ein Nutzer oder das Sprachmodell schlägt eine Aufgabe vor.
- Der MCP-Client fragt mit tools/list die für den aktuellen Kontext sichtbaren Werkzeuge ab.
- Der Client prüft Mandant, Rolle, Rechteklasse, Zweck und Freigabestatus.
- Bei einer zustimmungspflichtigen Aktion fordert der Host eine menschliche Freigabe an.
- Der MCP-Client sendet den bestätigten Aufruf mit tools/call an den MCP-Server.
- Der MCP-Server führt das Werkzeug aus und gibt ein Ergebnis oder einen Fehler zurück.
- Aufruf, Ergebnis, Versionsstand und Freigabeentscheidung werden im Audit-Log dokumentiert.
Der betriebliche Zusammenhang muss über eindeutige Identitäten, Rollen, Mandanteninformationen, Parameter und Freigaben hergestellt werden. Eine frühere Erlaubnis darf nicht automatisch als Freigabe für einen späteren Aufruf gelten.
Referenzstatus des btlabs MCP Toolkatalogs
Ein belastbarer MCP Toolkatalog von btlabs Core muss direkt aus der eingesetzten Implementierung erzeugt werden. Die Firmendaten weisen zwar einen technischen Endpunkt für Werkzeuge aus, enthalten aber keinen geprüften Export mit Werkzeugnamen, Rechten und Versionsangaben. Deshalb nennt dieser Beitrag weder eine feste Gesamtzahl noch nicht belegte Namen vermeintlich implementierter btlabs MCP Tools.
- Produkt: btlabs Core
- Produktversion: in der vorliegenden Datengrundlage nicht ausgewiesen
- Toolkatalog-Version: in der vorliegenden Datengrundlage nicht ausgewiesen
- Stichtag des technischen Exports: nicht ausgewiesen
- Verantwortliche technische Prüfung: nicht ausgewiesen
- Einzeln validierte MCP-Werkzeugnamen: ohne geprüften Serverexport nicht dokumentierbar
Bis ein solcher Export vorliegt, beschreibt der Artikel ein Governance- und Dokumentationsmodell. Die genannten Funktionsbereiche sind keine Zusage einzelner MCP-Endpunkte.
Pflichtangaben für jedes reale Werkzeug
Jeder Eintrag im MCP Toolkatalog sollte mindestens folgende Angaben enthalten:
- Technischer Name: eindeutiger Name für tools/call
- Betriebliche Aufgabe: verständliche Beschreibung des konkreten Zwecks
- Datenumfang: zugängliche Inhalte, Felder oder Systemzustände
- Rechteklasse: Lesen, Schreiben, Ausführen oder Verwalten
- Freigabestatus: automatisch zulässig, zustimmungspflichtig, eingeschränkt oder deaktiviert
- Außenwirkung: mögliche Veröffentlichung, Kommunikation, Datenweitergabe oder Systemänderung
- Mandantenbezug: eindeutig abgegrenzter Daten- und Berechtigungsraum
- Versionsstand: Produktversion und Version der Werkzeugdefinition
- Stichtag: Zeitpunkt der letzten technischen Prüfung
Den technischen Aufbau der zentralen Inhalts- und Datenbasis erläutere ich im Beitrag über die Architektur von btlabs Core. Die gemeinsame Datenbasis soll verhindern, dass Website, Sprachversionen und maschinenlesbare Ausgaben unterschiedliche Unternehmensinformationen verwenden.
Interne Funktionen sind nicht automatisch MCP-Werkzeuge
Eine interne Systemfunktion, eine Bedienoberfläche und ein über MCP aufrufbares Werkzeug sind drei unterschiedliche Dinge. Eine Funktion darf deshalb erst dann als verfügbares MCP-Werkzeug bezeichnet werden, wenn der aktuelle Serverkatalog den technischen Namen, die Parameter und den Freigabestatus ausweist.
Nur nach technischem Nachweis als MCP-Werkzeug ausweisen
- Lesen eines bestimmten Inhaltsdatensatzes über einen benannten MCP-Aufruf
- Anlegen oder Aktualisieren eines nicht öffentlichen Entwurfs
- Prüfen zusammengehöriger Sprachversionen
- Ausführen einer SEO-, GEO- oder Vollständigkeitsprüfung
- Abfragen eines Freigabestatus oder Audit-Logs
- Auslösen eines Veröffentlichungs- oder Verwaltungsprozesses
Vorbereitete Ausbaustufen sind keine aktuelle Produktzusage
- buchende KI-Agenten
- Shop- und Bestandsfunktionen
- geschützte Kundenbereiche
- Live-Preisrechner und Terminanzeigen
- Apps oder weitere Standorte auf derselben Datenbasis
Eine technisch vorbereitete Funktion ist weder automatisch aktiviert noch freigegeben. Maßgeblich bleiben das konkrete Projekt, die Implementierung und der aktuelle Toolkatalog.
tools/list zeigt Werkzeuge, erteilt aber keine Freigabe
tools/list fragt die vom MCP-Server angebotenen Werkzeuge ab. Die MCP-Werkzeugspezifikation erlaubt, dass der sichtbare Umfang von der vorgelegten Autorisierung und den gewährten Berechtigungen abhängt.
Für btlabs Core sollte tools/list nur jene MCP-Werkzeuge zurückgeben, die der aktuelle Mandant und die aktuelle Rolle sehen dürfen. Ob eine konkrete Installation bereits entsprechend filtert, muss ein technischer Test zum dokumentierten Stichtag bestätigen.
tools/list beantwortet die Frage: „Welche Werkzeuge werden mir angeboten?“ Die Antwort erteilt nicht automatisch die Freigabe für jede mögliche Wirkung dieser Werkzeuge.
tools/call übermittelt den Werkzeugnamen und die erforderlichen Argumente an den MCP-Server. Vor der Ausführung müssen Identität, Mandant, Rechteklasse und Freigabestatus zum geplanten Aufruf passen.
Vier MCP-Rechteklassen für btlabs Core
Die vier MCP-Rechteklassen sind ein betriebliches Governance-Modell für btlabs Core. Die MCP-Spezifikation definiert diese Klassen nicht als normative Berechtigungsstufen.
- Lesen: Inhalte suchen, ansehen, vergleichen und prüfen, ohne Daten oder Zustände zu verändern.
- Schreiben: Entwürfe anlegen, Felder aktualisieren oder Zuordnungen verändern. Das Recht umfasst nicht automatisch Veröffentlichung oder Löschung.
- Ausführen: einen begrenzten Prozess wie eine Prüfung oder einen reversiblen Verarbeitungsschritt starten.
- Verwalten: Rollen, Rechte, Exporte, globale Einstellungen oder systemweite Zustände verändern.
Die Vergabe folgt dem Prinzip der geringsten Berechtigung: Ein Nutzer, Dienst oder Agent erhält nur die Rechte, die für eine klar beschriebene Aufgabe erforderlich sind. Die Berechtigung gilt für einen bestimmten Mandanten, definierte Datenbereiche und möglichst einen begrenzten Zeitraum.
In meiner Arbeit mit kleinen Unternehmen zeigt sich regelmäßig: Zu breite Standardrollen verursachen mehr Risiko als klar begrenzte Werkzeuge. Ein Redaktionsprozess wird nicht sicherer, wenn alle Beteiligten vorsorglich Verwaltungsrechte erhalten.
Mandantentrennung schützt Daten und Zuständigkeiten
Die Mandantentrennung verhindert, dass ein Werkzeug Daten verschiedener Unternehmen, Websites oder organisatorischer Einheiten vermischt. Ein MCP-Aufruf für Betrieb A darf weder Inhalte von Betrieb B sehen noch dessen Freigaben oder Protokolle verwenden.
- Jeder Aufruf benötigt eine eindeutige Mandantenidentität.
- Rollen und Rechte werden mandantenbezogen vergeben.
- Datenzugriffe und Protokolle bleiben getrennt.
- Frühere Freigaben dürfen nicht in einen anderen Mandantenkontext übernommen werden.
- Bei einem widersprüchlichen Mandanten- oder Rollenbezug wird der Aufruf abgebrochen.
Eine gemeinsame Bedienoberfläche darf die Sicherheitsgrenzen der einzelnen Betriebe nicht aufweichen.
Welche MCP-Werkzeuge eine menschliche Freigabe brauchen
Die herangezogene MCP-Werkzeugspezifikation schreibt kein bestimmtes Interaktionsmodell zwingend vor. Sie empfiehlt jedoch sichtbare Werkzeugaufrufe, Bestätigungsdialoge und einen Menschen mit Ablehnungsmöglichkeit. Für btlabs Core ergibt sich daraus ein strengeres betriebliches Modell für folgenreiche Aktionen.
Eine menschliche Freigabe bleibt erforderlich für:
- Veröffentlichungen: Inhalte werden öffentlich sichtbar.
- Endgültige Löschungen: Daten können verloren gehen und Verweise können brechen.
- Rechteänderungen: Der Sicherheitsrahmen für spätere Aufrufe verändert sich.
- Exporte: Daten können den vorgesehenen Verarbeitungsbereich verlassen.
- Externe Kommunikation: E-Mails, Angebote oder Buchungen können geschäftliche Folgen haben.
- Systemweite Eingriffe: Globale Änderungen können mehrere Inhalte, Sprachen oder Websites betreffen.
Die Freigabe muss zeigen, welches Werkzeug welche Daten mit welcher erwarteten Wirkung verarbeitet. Eine pauschale Erlaubnis ohne Zweck, Umfang und Gültigkeitsdauer genügt nicht.
Was ein Audit-Log dokumentieren sollte
Ein Audit-Log macht Werkzeugaufrufe, Fehler und Freigabeentscheidungen nachvollziehbar. Das Protokoll sollte nur jene Angaben erfassen, die für Sicherheit, Fehleranalyse und Verantwortlichkeit erforderlich sind.
- Identität: auslösender Nutzer, Dienst oder Agent
- Mandant: betroffener Daten- und Verantwortungsbereich
- Werkzeug: technischer Name und Werkzeugversion
- Zeitpunkt: Beginn, Ende und Dauer des Aufrufs
- Rechteklasse: verwendete Berechtigungsstufe
- Freigabestatus: zulässig, bestätigt, abgelehnt oder abgelaufen
- Parameter: erforderliche Eingabedaten in datensparsamer Form
- Ergebnis: Änderung, Rückgabe, Abbruch oder Fehler
- Freigabeentscheidung: verantwortliche Person und Zeitpunkt
- Versionsstand: Version von btlabs Core und Toolkatalog
Passwörter, Zugangstoken, Sicherheitsschlüssel und unnötige personenbezogene Inhalte gehören nicht in das Audit-Log. Nachvollziehbarkeit und Datensparsamkeit müssen gemeinsam geplant werden.
Praxisbeispiel: mehrsprachige Inhalte kontrolliert aktualisieren
Vorher: Änderungen mehrfach übertragen
Ein kleiner Tourismusbetrieb aktualisiert Öffnungszeiten und Leistungsbeschreibungen auf Deutsch und Italienisch. Eine Mitarbeiterin sucht die betroffenen Seiten, überträgt jede Änderung einzeln und kontrolliert Metadaten sowie Sprachverknüpfungen. Dabei kann eine veraltete Angabe in einer Sprachversion bestehen bleiben.
Nachher: prüfen, als Entwurf speichern und freigeben
- Die Mitarbeiterin wählt den Inhalt und den zulässigen Mandanten.
- Der MCP-Client ruft mit tools/list die für die Redaktionsrolle sichtbaren MCP-Werkzeuge ab.
- Ein validiertes Lesewerkzeug vergleicht die deutschen und italienischen Inhalte.
- Das Sprachmodell markiert mögliche Widersprüche und schlägt Änderungen vor.
- Ein Schreibwerkzeug erstellt ausschließlich nicht öffentliche Entwürfe.
- Ein Prüfwerkzeug kontrolliert Fakten, Sprachbeziehungen, Metadaten und Pflichtfelder.
- Die Mitarbeiterin erhält eine Änderungsliste mit Ausgangswert und vorgeschlagenem Wert.
- Erst nach der menschlichen Freigabe sendet der MCP-Client den zulässigen tools/call-Aufruf an den MCP-Server.
- Werkzeug, Änderung, Freigabe und Ergebnis werden im Audit-Log dokumentiert.
Fehlerfall und Rücksetzung
Liefert der MCP-Server einen Fehler oder erkennt die Mitarbeiterin eine falsche Änderung, wird die Veröffentlichung gestoppt. Der Entwurf bleibt vom letzten gültigen öffentlichen Versionsstand getrennt.
Die verantwortliche Redaktionsrolle korrigiert den Entwurf oder setzt ihn auf die vorherige Fassung zurück. Fehlerstatus und Rücksetzung werden protokolliert. Der Zeitgewinn entsteht durch vorbereitete Suche, Vergleiche und Entwürfe – nicht durch ungeprüfte Veröffentlichungen.
MCP-Werkzeuge mit minimalen Rechten einführen
Für kleine Unternehmen empfehle ich keinen sofortigen Vollzugriff. Ein begrenzter Pilot zeigt, ob Werkzeug, Datenqualität und Zuständigkeiten zusammenpassen.
- Aufgabe begrenzen: Wähle einen klaren Anwendungsfall, etwa den Vergleich zweier Sprachversionen.
- Mit Lesen beginnen: Erlaube zunächst nur Suche, Abruf und Vergleich ausgewählter Inhalte.
- Mandantenbereich festlegen: Begrenze den Test auf eine Website oder einen Inhaltsbereich.
- Ergebnisse prüfen: Vergleiche die Werkzeugausgabe mit den tatsächlichen Quelldaten.
- Schreibrecht gezielt ergänzen: Erlaube anschließend nur nicht öffentliche Entwürfe.
- Freigabe testen: Simuliere Veröffentlichung, Ablehnung, Fehler und Rücksetzung.
- Rechte überprüfen: Entferne nicht mehr benötigte Rollen und abgelaufene Zugänge.
Die Praxisanleitung für KI-Richtlinien in KMU hilft Dir, Zuständigkeiten und zulässige Daten über einzelne Werkzeugaufrufe hinaus zu regeln.
Statusangaben im MCP Toolkatalog
- Verfügbar: Das Werkzeug ist im dokumentierten Versionsstand implementiert, für den Mandanten aktiviert und mit der zugewiesenen Rolle nutzbar.
- Eingeschränkt verfügbar: Das Werkzeug benötigt eine zusätzliche Konfiguration, Rechteklasse oder menschliche Freigabe.
- Deaktiviert: Das Werkzeug wird dem betreffenden Mandanten oder MCP-Client nicht angeboten.
- Vorbereitete Ausbaustufe: Die Architektur kann eine spätere Funktion aufnehmen; aktuell ist die Funktion weder verfügbar noch zugesagt.
Ein Freigabestatus ohne Versionsstand ist unvollständig. Status, Werkzeugversion und Stichtag sollten immer gemeinsam dokumentiert werden.
Auswahlhilfe für MCP-Werkzeuge
Bevor Du ein Werkzeug aktivierst, solltest Du folgende Fragen beantworten:
- Zweck: Welchen konkreten betrieblichen Engpass löst das Werkzeug?
- Daten: Welche Inhalte oder personenbezogenen Daten kann das Werkzeug verarbeiten?
- Mandant: Für welchen abgegrenzten Datenraum gilt der Zugriff?
- Rechteklasse: Genügt Lesen oder sind weitergehende Rechte erforderlich?
- Außenwirkung: Kann der Aufruf veröffentlichen, kommunizieren, exportieren oder Rechte verändern?
- Rückholbarkeit: Kann eine fehlerhafte Aktion vollständig zurückgesetzt werden?
- Freigabe: Welche Person trägt die Verantwortung?
- Protokollierung: Welche Angaben erscheinen im Audit-Log?
- Versionsbezug: Für welche Produkt- und Werkzeugversion wurde der Ablauf geprüft?
Bleibt eine Frage offen, sollte das Werkzeug deaktiviert bleiben oder zunächst nur mit Lesezugriff in einer Testumgebung eingesetzt werden. Bei der Beratung zu KI und Digitalisierung prüfen wir deshalb neben der technischen Verbindung auch Zweck, Datenqualität, Zuständigkeit und Rücksetzung.
Fragen zum MCP Toolkatalog von btlabs Core
Was sind MCP-Werkzeuge?
MCP-Werkzeuge sind strukturierte Funktionen, die ein MCP-Server einem kompatiblen MCP-Client anbietet. Ein Werkzeug kann Daten lesen, einen Entwurf bearbeiten oder einen begrenzten Prozess ausführen, sofern Rolle und Freigabestatus den Aufruf erlauben.
Wer führt einen MCP-Aufruf technisch aus?
Das Sprachmodell kann die Verwendung eines Werkzeugs vorschlagen, führt die Systemaktion aber nicht selbst aus. Der MCP-Client übermittelt den zulässigen Aufruf; der MCP-Server führt das bereitgestellte Werkzeug aus.
Ist tools/list bereits eine Berechtigung?
Nein. tools/list zeigt die Werkzeuge, die der Server für den jeweiligen Kontext zurückgibt. Für einen konkreten tools/call-Aufruf können zusätzliche Rechte oder eine menschliche Freigabe erforderlich sein.
Sieht tools/list immer den vollständigen Serverkatalog?
Die MCP-Spezifikation erlaubt, den sichtbaren Umfang anhand der Autorisierung zu begrenzen. Ob eine konkrete btlabs-Core-Installation nach Mandant und Rolle filtert, muss ein technischer Test zum dokumentierten Stichtag bestätigen.
Welche Aktionen brauchen eine menschliche Freigabe?
Veröffentlichungen, endgültige Löschungen, Rechteänderungen, sensible Exporte, externe Kommunikation und systemweite Eingriffe bleiben zustimmungspflichtig. Die Entscheidung muss einer verantwortlichen Person zugeordnet und im Audit-Log dokumentiert werden.
Wie erkenne ich den aktuellen Versionsstand?
Ein belastbarer Eintrag nennt Produktversion, Toolkatalog-Version, Werkzeugversion, Freigabestatus und Stichtag. Fehlen diese Angaben, ist der Eintrag keine verlässliche aktuelle Produktreferenz.
Was passiert bei einem Fehler?
Der MCP-Server gibt einen Fehler zurück; abhängige Schreib- oder Veröffentlichungsschritte werden gestoppt. Reversible Änderungen werden durch die verantwortliche Rolle auf den letzten gültigen Stand zurückgesetzt und protokolliert.
Darf ein Agent seine Rechte selbst erweitern?
Nein. Ein Agent darf weder seine Rechteklasse ändern noch Freigabeschritte oder Mandantengrenzen umgehen. Rechteänderungen gehören zur Klasse Verwalten und benötigen eine getrennte menschliche Entscheidung.
Warum nennt der Artikel keine feste Anzahl an MCP Tools?
Eine verlässliche Anzahl muss aus dem real eingesetzten und versionsgebundenen Toolkatalog stammen. Ohne geprüften Serverexport würde eine statische Zahl verfügbare, deaktivierte und vorbereitete Funktionen vermischen.
Fazit: MCP-Werkzeuge brauchen geprüfte Rechte
Ein guter MCP Toolkatalog dokumentiert nicht nur technische Namen. Der Katalog zeigt, wer ein Werkzeug zu welchem Zweck, mit welchen Daten, in welcher Rechteklasse und unter welcher Freigaberegel verwenden darf.
Für kleine Unternehmen ist kontrollierte Automatisierung sinnvoller als uneingeschränkte Autonomie. btlabs Core soll Such-, Prüf- und Übertragungsarbeit reduzieren, während sensible Entscheidungen bei den zuständigen Menschen im Betrieb bleiben. Weitere Informationen findest Du auf der Seite zur KI-ready Website mit btlabs Core.
