Model Context Protocol (MCP) für Unternehmen erklärt: Was es ist, wofür es taugt, worauf zu achten ist

Was MCP ist — und welches Problem es löst

Ein Sprachmodell kann Texte erzeugen, aber nichts tun. Sobald es etwas tun soll — eine Datenbank abfragen, ein Dokument ablegen, einen Auftrag anlegen —, braucht es eine Verbindung zu einem Werkzeug. Bis 2024 war jede solche Verbindung Einzelarbeit: Jedes Modell, jede Anwendung und jedes System sprachen ihre eigene Sprache, und wer drei Systeme an zwei Modelle anbinden wollte, baute sechs Anbindungen.

Anthropic veröffentlichte das Model Context Protocol am 25. November 2024 als offenen Standard für Verbindungen zwischen KI-Systemen und den Datenquellen und Werkzeugen, die sie benutzen sollen. Die Idee ist unspektakulär und genau deshalb wirksam: Ein Server beschreibt maschinenlesbar, welche Werkzeuge er anbietet und welche Rechte sie brauchen; jedes Modell, das den Standard spricht, kann sie benutzen. Aus sechs Anbindungen werden fünf Bausteine.

Die Zustimmungsregel — der für Unternehmen wichtigste Satz

Die Spezifikation in der Fassung 2025-06-18 verlangt, dass Hosts vor jedem Werkzeugaufruf die ausdrückliche Zustimmung des Nutzers einholen. Das klingt nach einer Bedienfrage und ist in Wahrheit die entscheidende architektonische Aussage des Standards: Die Kontrolle sitzt in der Umgebung, nicht im Modell.

Warum das zählt, zeigt der Vergleich mit der Alternative. Eine Regel, die im Prompt steht — „frag nach, bevor du schreibst“ —, konkurriert mit jedem weiteren Satz im Kontext und kann verlieren. Eine Regel, die im Protokoll sitzt, ist keine Bitte mehr: Ohne Zustimmung kommt der Aufruf nicht durch. Für ein Unternehmen ist das der Ansatzpunkt, an dem sich überhaupt festlegen lässt, was ein Agent anfassen darf.

Die Zustimmungsregel ist eine Anforderung an den Host, nicht an das Modell. Wer MCP einsetzt, sollte deshalb prüfen, wie der konkrete Host sie umsetzt — und ob sie sich für Bequemlichkeit abschalten lässt.

Wofür MCP im Unternehmen taugt

Weil das Protokoll offen ist, lässt sich eine Anbindung prüfen statt glauben. Welche Werkzeuge ein Server anbietet und welche Rechte sie brauchen, ist auslesbar — man kann also eine Liste führen, was ein Agent überhaupt anfassen darf. Genau das ist der praktische Kern von KI-Governance.

• Bestandsaufnahme: Welche Server sind angebunden, welche Werkzeuge bieten sie an, welche Rechte verlangen sie?
• Rechtevergabe je Werkzeug statt pauschal je Agent — Lesen und Schreiben sind zwei verschiedene Entscheidungen.
• Zustimmung an den Stellen, an denen ein Aufruf Wirkung nach außen hat: Bestellung, Zahlung, Versand, Löschung.
• Protokoll je Aufruf, damit später nachlesbar ist, welcher Schritt mit welchen Daten ausgeführt wurde.

Was MCP nicht leistet, gehört dazugesagt: Es prüft keine Inhalte. Der Standard regelt, wie eine Verbindung aussieht und wer zustimmt — nicht, ob das Ergebnis eines Werkzeugaufrufs richtig ist. Ein Agent, der über MCP sauber angebunden ist, kann trotzdem Unsinn ausführen, wenn niemand das Ergebnis kontrolliert.

Wie MCP Baldux das Protokoll benutzt

Der Name ist Programm: Bei MCP Baldux ist der Ablauf, der jede Entwicklungsarbeit steuert, selbst ein MCP-Server. Der Unterschied zu einer üblichen Anbindung liegt darin, was der Server durchsetzt — nicht nur, welche Werkzeuge er anbietet. Ohne durchlaufene Prüfung gibt es kein Prüfsiegel und keine Veröffentlichung, und ein Übergabeschlüssel trägt den Zustand über Modellwechsel, damit ein Schritt im regulären Ablauf nicht ausgelassen wird.

Für Unternehmen mit eigenen KI-Agenten steht dieselbe Technik als Engine zur Verfügung: Der vorgesehene Ablauf wird pro Agent erzwungen, jeder Schritt schreibt seinen Nachweis in eine Belegkette, und die Ausführung läuft in einer abgeschotteten Umgebung. Angebunden wird per MCP oder API; der Zugang läuft über einen Vertriebstermin, weil Volumen, Setup und Kontingent vorher geklärt werden.

Abgerechnet wird pro Prüfung, gestaffelt nach Monatsvolumen: 0,80 € bis 0,30 €, ab 50.000 Prüfungen verhandelt. Ein AV-Vertrag nach Art. 28 DSGVO ist, soweit erforderlich, Vertragsbestandteil — ohne Aufpreis.

Worauf zu achten ist, bevor Sie MCP einsetzen

1. Rechte je Werkzeug festlegen, nicht je Agent. Ein Agent, der lesen darf, muss nicht schreiben dürfen.
2. Prüfen, wie der Host die Zustimmungsregel umsetzt und ob sie sich abschalten lässt.
3. Klären, welche Daten ein Server tatsächlich sieht — ein Werkzeug, das „Kundendaten“ heißt, kann sehr Verschiedenes bedeuten.
4. Ein Protokoll je Aufruf einplanen, bevor der erste Agent produktiv geht. Nachweise lassen sich schlecht nachträglich einbauen.
5. Einen Menschen benennen, der bei Aufrufen mit Außenwirkung freigibt — und festlegen, was passiert, wenn er nicht entscheidet.

Diese fünf Punkte sind keine Besonderheit von MCP. Sie sind das, was ohnehin gilt, sobald ein Programm im eigenen Namen handelt — der Standard macht nur sichtbar, wo man sie festlegen kann.