Was ist MCP (Model Context Protocol)? Der Standard für KI und Werkzeuge

Was ist MCP und was bringt es KI Anwendungen?

MCP (Model Context Protocol) ist ein offenes Protokoll, das KI Anwendungen auf standardisierte Weise mit Dateien, Datenbanken, Diensten und Werkzeugen verbindet. Statt für jede Verbindung eigenen Code zu schreiben, nutzen Sie also eine gemeinsame Sprache. So erreicht ein KI Assistent über ein einziges Protokoll viele externe Systeme und kann darin handeln.

Was ist MCP also im Alltag? Denken Sie an einen USB C Anschluss. Sie stecken Handy, Kopfhörer und externe Festplatte in denselben Port, weil alle einem Standard folgen. Somit übernimmt MCP für KI Anwendungen dieselbe Rolle. Die offizielle MCP Einführung verwendet denselben Vergleich.

Ein Sprachmodell allein spricht nur über das, was es im Training gelernt hat. Es kann zum Beispiel Ihren Kalender nicht prüfen, Ihr Dokument nicht öffnen und Ihre Bestandstabelle nicht abfragen. MCP schließt diese Lücke, denn es gibt dem Modell eine standardisierte Tür zur Außenwelt.

In diesem Leitfaden erklären wir den Begriff auf Konzeptebene. Unser Ziel ist es, die Frage "Was ist MCP" so zu beantworten, dass sie Unternehmern und Entwicklern gleichermaßen hilft.

Zunächst sehen Sie die Architektur, danach die Bausteine. Anschließend vergleichen wir MCP mit Nachbarbegriffen wie Function Calling, RAG und WebMCP und behandeln Sicherheitsrisiken sowie eine praktische Checkliste. Modellnamen, Versionen und Preise nennen wir bewusst nicht, weil sie schnell veralten. Prüfen Sie aktuelle Werte in der offiziellen Dokumentation des Anbieters.

Welches Problem soll MCP lösen?

Mit der Zahl der KI Anwendungen entstand daher ein Verbindungsproblem. Jede Anwendung brauchte für jedes Werkzeug einen eigenen Connector. Kalender, E-Mail, Dokumentenablage und Kundendaten verlangten jeweils separaten Code.

Außerdem arbeitete jeder Connector ein wenig anders. Änderte sich ein Werkzeug, mussten Sie deshalb alle Connectors erneut anfassen. Folglich trieb das Kosten und Fehlerrisiko nach oben.

MCP teilt diese Last. Erstens schreibt ein Werkzeuganbieter seinen Server nur einmal. Zweitens schreibt eine KI Anwendung ihren Client ebenfalls nur einmal. Weil beide dasselbe Protokoll sprechen, passen sie zusammen.

Zum Beispiel nutzen Code Editoren eine ähnliche Idee für Sprachunterstützung. Laut Spezifikation hat sich MCP davon inspirieren lassen. Anders gesagt: MCP ist keine völlig neue Idee, sondern überträgt ein bewährtes Standardisierungsmuster auf KI.

Wie funktioniert MCP: Was sind Host, Client und Server?

MCP folgt einer Architektur aus Client und Server. Die offizielle Architekturübersicht unterscheidet drei Beteiligte: Host, Client und Server. Vor allem das Verwechseln dieser drei Begriffe ist der häufigste Fehler rund um MCP.

• Host: Die KI Anwendung, mit der der Nutzer spricht. Das kann zum Beispiel eine Chat Oberfläche oder ein Code Editor sein.
• Client: Eine Komponente im Host, die genau eine Verbindung zu genau einem Server hält. Außerdem erzeugt der Host für jeden Server einen eigenen Client.
• Server: Ein Programm, das Kontext und Fähigkeiten bereitstellt. Es kann zum Beispiel ein Dateisystem, eine Datenbank oder einen SaaS Dienst kapseln.

Das Wort "Server" führt leicht in die Irre. Ein MCP Server ist nicht zwingend eine entfernte Maschine, denn er kann lokal laufen. Also gilt auch ein kleines Programm auf demselben Rechner als MCP Server.

Zum Beispiel agiert ein Code Editor als Host. Zunächst öffnet er einen Client für das Dateisystem und einen zweiten Client für ein Projektwerkzeug. Dann sieht das Modell alle Fähigkeiten beider Server in einer gemeinsamen Liste.

Das Schöne an dieser Aufteilung: Die Teile bleiben also unabhängig. Zum Beispiel weiß der Host, welche Server verbunden sind, und kann jederzeit einen entfernen oder hinzufügen. Die Server sehen sich nie gegenseitig, denn jeder spricht nur mit seinem eigenen Client.

Welche drei Bausteine bietet ein MCP Server an?

Die offizielle Dokumentation beschreibt drei Kernbausteine, die ein Server anbieten kann: Tools, Ressourcen und Prompts. Jeder dient einem anderen Zweck, und jeweils eine andere Partei steuert ihn.

Diese Unterscheidung ist wichtig, weil jeder Baustein andere Erwartungen an Sicherheit und Freigabe hat. Tools erledigen echte Arbeit. Deshalb müssen Sie diesen Teil am sorgfältigsten steuern.

Was genau machen MCP Tools?

Ein Tool ist eine ausführbare Funktion, die eine KI Anwendung aufrufen kann. Die offizielle Dokumentation nennt als Beispiele Dateioperationen, API Aufrufe und Datenbankabfragen. Außerdem hat jedes Tool einen Namen, eine Beschreibung und ein Schema für die erwarteten Eingaben.

Zunächst fragt der Client den Server nach seiner Tool Liste. Danach zeigt er diese Liste dem Modell. Anhand der Nutzeranfrage entscheidet das Modell dann, welches Tool es mit welchen Eingaben aufruft.

Die Liste kann sich allerdings ändern. Konkret: Fügt ein Server eine Fähigkeit hinzu oder nimmt er eine weg, kann er den Client benachrichtigen. Somit bleibt die Anwendung auf dem aktuellen Stand.

Tool Beschreibungen beeinflussen die Entscheidung des Modells. Eine gut formulierte Beschreibung führt dazu, dass das Tool zur richtigen Zeit mit der richtigen Eingabe läuft. Eine vage Beschreibung dagegen führt zu falschen Aufrufen.

Daher empfehlen wir Tools, die eine Aufgabe gut erledigen, klare Namen tragen und enge Eingaben haben. Denn ein einziges "Supertool" für alles verwirrt das Modell und erhöht das Risiko.

Wann brauchen Sie Ressourcen und Prompts?

Ressourcen liefern Kontext, statt das Modell arbeiten zu lassen. Der Inhalt einer Datei, ein Tabellenschema oder eine API Antwort kann eine Ressource sein. Dann liest das Modell diese Daten und stützt seine Antwort darauf.

Der Unterschied zu einem Tool ist einfach: Eine Ressource lesen Sie, ein Tool führen Sie aus. Zum Beispiel ist es Ressourcenarbeit, das Modell einen Produktkatalog lesen zu lassen. Das Preisfeld eines Katalogeintrags zu ändern, ist Tool Arbeit.

Prompts sind wiederverwendbare Nachrichtenvorlagen. Ein Server bietet also eine Vorlage an, die für eine bestimmte Aufgabe gut funktioniert. Dann wählt der Nutzer sie aus, füllt die Lücken und sendet sie an das Modell.

Beispielszenario: Ein MCP Server für ein Support Team könnte einen Prompt "Kundenbeschwerde zusammenfassen" anbieten. Folglich schreibt das Team die Anweisung nicht jedes Mal neu. Somit starten alle von derselben guten Vorlage.

In der Praxis beginnen viele Teams nur mit Tools. Das ist nicht falsch, denn Tools decken die meisten Bedarfe ab. Trotzdem hilft es, Ressourcen und Prompts zu kennen, weil Ihr Entwurf dadurch sauberer wird.

Welche Schichten und Transportwege nutzt die MCP Kommunikation?

Laut offizieller Dokumentation besteht MCP aus zwei Schichten: einer Datenschicht und einer Transportschicht. Zunächst legt die Datenschicht Aufbau und Bedeutung der Nachrichten fest. Die Transportschicht bestimmt dagegen, über welchen Kanal die Nachrichten laufen.

Konkret baut die Datenschicht auf JSON RPC 2.0 auf. Client und Server schicken sich also Anfragen und erhalten Antworten. Außerdem gibt es Benachrichtigungen für Fälle, in denen keine Antwort nötig ist. Auch das Herausfinden, was ein Server unterstützt, gehört zu dieser Schicht.

Zwei Transportwege stechen hervor:

• stdio: Spricht über Standardeingabe und Standardausgabe zwischen Prozessen auf demselben Rechner. Es entsteht kein Netzwerkaufwand, daher eignet sich dieser Weg für lokale Server.
• Streamable HTTP: Spricht über HTTP mit entfernten Servern. Er bedient viele Clients gleichzeitig und unterstützt außerdem gängige HTTP Verfahren zur Anmeldung.

Schließlich empfiehlt die Dokumentation für die Autorisierung bei entfernten Servern OAuth. Details können sich weiterentwickeln, deshalb prüfen Sie die aktuelle Fassung in der MCP Spezifikation.

Wie hängt MCP mit KI Agenten zusammen?

Ein KI Agent ist ein System, das Schritte plant und Werkzeuge nutzt, um ein Ziel zu erreichen. Damit ein Agent nützlich ist, muss er also diese Werkzeuge erreichen. Genau hier kommt MCP ins Spiel.

Der Agent übernimmt Planung und Entscheidungslogik. MCP ist dagegen der standardisierte Kanal, über den der Agent mit der Außenwelt spricht. Dank dieser Trennung fügen Sie ein Tool hinzu, ohne den Agenten zu ändern. Ebenso aktualisieren Sie den Agenten, ohne das Tool anzufassen.

Zum Beispiel kann ein Agent für ein Marketing Team über einen Server einen Anzeigenbericht abrufen und über einen anderen den Redaktionskalender lesen. Die Logik des Agenten bleibt dabei gleich. Stattdessen wechseln nur die verbundenen Server.

Allerdings bringt diese Flexibilität auch Verantwortung. Je mehr Tools ein Agent erreicht, desto größer wirkt eine falsche Entscheidung. Planen Sie deshalb den Ablauf für Rechte und Freigaben von Anfang an mit ein.

Agenten behandeln wir in eigenen Artikeln. Hier skizzieren wir nur den Platz von MCP in der Agenten Architektur.

Welche Funktionen bietet ein MCP Client dem Server an?

Informationen fließen nicht nur vom Server zum Client. Die offizielle Dokumentation beschreibt außerdem Funktionen auf der Client Seite. Das deutlichste Beispiel ist Elicitation, mit der ein Server beim Nutzer zusätzliche Angaben oder eine Bestätigung anfragen kann.

Mitten in einer Aufgabe kann ein Server zum Beispiel fragen: "Bestätigen Sie, dass ich diesen Eintrag lösche?" Der Client zeigt die Frage dem Nutzer und gibt die Antwort zurück. So bleibt der Mensch im Ablauf.

Diese Funktion ist zudem für die Sicherheit wertvoll. Bei Aktionen, die sich nicht rückgängig machen lassen, kann der Server selbst eine Freigabe verlangen. Dennoch unterstützt nicht jeder Client jede Funktion. Außerdem können sich Client Funktionen mit der Entwicklung des Protokolls ändern oder auslaufen.

Nehmen Sie deshalb beim Entwurf eines Servers nicht einfach an, welche Client Funktionen vorhanden sind. Beim Verbindungsaufbau tauschen Client und Server ihre Fähigkeiten aus, daher sollte Ihr Server sein Verhalten daran anpassen. Details finden Sie in der aktuellen Spezifikation.

Wie läuft eine MCP Anfrage von Anfang bis Ende ab?

Den Ablauf Schritt für Schritt zu betrachten, macht die Frage "Was ist MCP" greifbar. Die folgende Reihenfolge ist eine konzeptionelle Zusammenfassung. In echten Anwendungen kommen manche Schritte außerdem aus einem Zwischenspeicher.

1. Zunächst erzeugt der Host einen Client, um sich mit einem MCP Server zu verbinden.
2. Danach erfährt der Client, welche Fähigkeiten der Server unterstützt.
3. Dann fragt der Client die Tool Liste des Servers ab und reicht sie an das Modell weiter.
4. Währenddessen schreibt der Nutzer eine Anfrage, und das Modell entscheidet, dass ein Tool hilft.
5. Anschließend leitet der Host den Aufruf an den richtigen Client weiter und holt bei Bedarf eine Freigabe des Nutzers ein.
6. Schließlich führt der Server die Operation aus und liefert das Ergebnis zurück.
7. Zuletzt gibt der Host das Ergebnis an das Modell, das dem Nutzer in normaler Sprache antwortet.

In der Praxis verbindet sich das Modell in diesem Ablauf nie direkt mit dem Server. Stattdessen übernimmt der Host dazwischen Weiterleitung, Freigabe und Kontrolle. Deshalb dreht sich ein Großteil der Sicherheitsdiskussion um genau diese Zwischenschicht.

Was ist der Unterschied zwischen MCP und Function Calling?

Beide werden oft verwechselt, weil in beiden ein Modell eine Funktion aufruft. Der Unterschied liegt deshalb in der Ebene, die sie lösen. Function Calling ist die Fähigkeit des Modells, strukturiert mitzuteilen, welche Funktion es mit welchen Eingaben aufrufen möchte. Das ist also ein Modellverhalten.

MCP dagegen ist ein Protokoll, das standardisiert, wie Tools definiert, gefunden und aufgerufen werden. MCP ersetzt Function Calling also nicht. Meistens arbeitet es darauf aufbauend.

Eine einfache Faustregel: Function Calling beantwortet die Frage, wie das Modell sagt, was es will. MCP beantwortet andererseits die Frage, wer diese Funktionen wo und nach welchen gemeinsamen Regeln anbietet.

Schreiben Sie für eine einzige Anwendung ein paar Funktionen, kann direktes Function Calling genügen. Möchten Sie dagegen, dass mehrere Anwendungen dieselben Tools nutzen, bietet MCP eine wiederverwendbare Struktur. Die Details zu Function Calling lesen Sie daher in unserem Schwesterartikel.

Wie arbeiten MCP, RAG und Structured Outputs zusammen?

Diese drei Begriffe tauchen oft im selben Projekt auf, erledigen aber verschiedene Aufgaben. RAG bedeutet, passende Dokumentteile zu finden und vor der Antwort in den Kontext zu legen. MCP kann ein standardisierter Weg sein, diesen Dokumentenspeicher zu erreichen.

Zum Beispiel könnte ein MCP Server ein Tool zum Durchsuchen von Firmendokumenten anbieten. Dann ruft das Modell es auf, liest die gelieferten Teile und stützt seine Antwort darauf. Hier ist RAG die Methode, und MCP ist der Zugangskanal zu dieser Methode.

Structured Outputs sorgen dagegen dafür, dass die Ausgabe des Modells einem vorgegebenen Schema folgt. Sie helfen zum Beispiel, wenn Sie Tool Ergebnisse sicher an das nächste System weiterreichen möchten. Folglich ergänzen sich alle drei, statt zu konkurrieren.

Ist MCP dasselbe wie WebMCP?

Nein. Die Namen ähneln sich, die Ziele unterscheiden sich jedoch. MCP ist ein allgemeines Protokoll, das KI Anwendungen mit Werkzeugen und Datenquellen verbindet. Meist läuft es also über ein Serverprogramm.

WebMCP dagegen betrifft Websites, die ihre eigenen Funktionen ausdrücklich für KI Agenten im Browser bereitstellen. Der Fokus liegt somit auf der Webseite selbst.

Kurz gesagt: MCP ist eine allgemeine Brücke, WebMCP ist ein Ansatz auf der Seite der Website. Den Unterschied erklären wir ausführlich in einem eigenen Artikel, deshalb wiederholen wir ihn hier nicht.

In welchen Praxisfällen hilft MCP?

Der Wert von MCP zeigt sich dort, wo KI vom Reden zum Erledigen übergeht. Die folgenden Beispiele sind Beispielszenarien und keine echten Kundenergebnisse.

• Entwicklungsumgebung: Der Assistent im Code Editor liest Projektdateien und verbindet sich mit Fehlerprotokollen. So hilft er, während er das Problem sieht.
• Interner Wissensassistent: Mitarbeiter stellen im Chat Fragen zu Unternehmensrichtlinien. Der Assistent erreicht den Dokumentenspeicher also über einen MCP Server.
• Support Team: Der Assistent schlägt einen Bestelldatensatz nach und entwirft eine Antwort. Danach gibt ein menschlicher Mitarbeiter den Entwurf frei.
• Redaktion: Der Assistent liest die Produktliste als Ressource und entwirft dann Kategorietexte.
• Reporting: Der Assistent holt eine Übersichtstabelle aus Messwerkzeugen und schreibt dann einen Wochenkommentar.

Wie Sie sehen, ist kein Beispiel Science Fiction. Alle drehen sich also darum, dass ein Assistent vorhandene Systeme erreicht. Das ist die praktische Antwort auf die Frage, was ist MCP: ein standardisierter Weg von der KI zu den Orten, an denen Ihre Arbeit stattfindet.

Gemeinsam ist allen Fällen zudem, dass der Zugriff nach außen über einen Standardweg läuft und nicht über jedes Mal neu geschriebene Connectors. Verwandte Ideen für das Marketing finden Sie in unserem Artikel zu KI Agenten im Marketing.

Welche Vorteile hat MCP?

Der größte Vorteil von MCP ist, dass es wiederkehrende Connector Arbeit verringert. Sie schreiben also einen Server einmal und nutzen ihn in vielen Anwendungen, die MCP unterstützen.

• Wiederverwendung: Derselbe Server funktioniert dann in verschiedenen Clients.
• Entkopplung: Werkzeuganbieter und KI Anwendung entwickeln sich somit unabhängig voneinander.
• Auffindbarkeit: Der Client listet die Fähigkeiten eines Servers dann zur Laufzeit auf.
• Ökosystem: Laut offizieller Dokumentation unterstützt eine breite Palette von Clients und Servern MCP.
• Kontrollpunkt: Weil alle Aufrufe über einen Weg laufen, sind Überwachung und Freigaben einfacher.

Teams, die mehrere Werkzeuge mit mehreren KI Anwendungen nutzen, profitieren am meisten von dieser Wiederverwendung. Arbeiten Sie andererseits nur mit einem Werkzeug und einer Anwendung, fällt der Vorteil kleiner aus.

Ein weiterer Gewinn ist die Unabhängigkeit. Wechseln Sie morgen Ihre KI Anwendung, müssen Sie Ihre Server oft nicht neu schreiben, denn sie sprechen das gemeinsame Protokoll. Folglich sinkt das Risiko, an einen einzigen Anbieter gebunden zu sein.

Welche Sicherheitsrisiken bringt MCP mit sich?

MCP ist mächtig, weil es einem Modell echte Aktionen erlaubt. Deshalb gehört Sicherheit in den Mittelpunkt Ihres Entwurfs. Die MCP Spezifikation nennt drei Prinzipien: Zustimmung und Kontrolle des Nutzers, Datenschutz und Tool Sicherheit.

Laut Dokumentation stehen Tools für beliebige Codeausführung und verlangen sorgfältigen Umgang. Ein Host sollte außerdem die ausdrückliche Zustimmung des Nutzers einholen, bevor er ein Tool aufruft. Beschreibungen des Tool Verhaltens gelten als nicht vertrauenswürdig, sofern sie nicht von einem vertrauenswürdigen Server stammen.

Zwei Risiken wiegen besonders schwer:

• Schädliche Tool Beschreibung: Ein böswilliger Server kann in der Beschreibung versteckte Anweisungen platzieren, die das Modell lenken. Das ist also eine Form von Prompt Injection.
• Zu weitreichende Rechte: Geben Sie einem Server mehr Zugriff als nötig, richten ein Fehler oder ein Angriff großen Schaden an.

Das Protokoll kann diese Prinzipien nicht allein durchsetzen. Das Team, das die Anwendung baut, muss deshalb Freigabe und Rechteabläufe selbst einrichten.

Ein weiterer Punkt verdient Beachtung: Das Modell sollte auch dem Text nicht blind trauen, den ein Tool zurückgibt. Zum Beispiel können Inhalte aus einer Webseite oder einem Dokument versteckte Anweisungen tragen. Gestalten Sie das System daher so, dass Tool Ausgaben als Daten gelten und nicht als Befehle.

Wie schützen Sie sich vor einem nicht vertrauenswürdigen MCP Server?

Die offizielle Seite zu Sicherheitspraktiken listet konkrete Risiken für Nutzer und Entwickler auf. Wir übersetzen sie unten in die Sprache des Geschäftsalltags.

1. Installieren Sie Server nur aus Quellen, die Sie kennen. Fügen Sie also kein unbekanntes Paket per Mausklick hinzu.
2. Lesen Sie vor dem Hinzufügen genau den Befehl, den ein lokaler Server ausführt. Denn lokale Server laufen mit denselben Rechten wie der Client.
3. Geben Sie einem Server nur die engste Berechtigung, die die Aufgabe braucht. Bevorzugen Sie stattdessen Rechte, die bei Bedarf wachsen.
4. Ein Server darf ein Zugriffstoken, das Sie ihm gegeben haben, nicht einfach an einen anderen Dienst durchreichen. Denn die Dokumentation verbietet dieses Verhalten ausdrücklich.
5. Verlangen Sie menschliche Freigabe für Aktionen, die sich nicht rückgängig machen lassen, etwa Schreiben, Löschen und Senden.
6. Protokollieren Sie Tool Aufrufe. Denn bei Problemen sollten Sie sehen, was wann aufgerufen wurde.

Diese Schritte geben keine Schutzgarantie. Sie senken allerdings den größten Teil des Risikos auf ein beherrschbares Maß. Geht es zum Beispiel um personenbezogene oder regulierte Daten, ist dieser Artikel keine Rechtsberatung. Sprechen Sie dann mit Ihrer Fachperson.

Worin unterscheidet sich ein eigener MCP Server von einem fertigen?

Beide Wege sind möglich, denn Ihr Bedarf kann abweichen. Nutzen Sie einen fertigen Server, starten Sie schnell, müssen aber prüfen, was er tut und welche Daten er berührt. Schreiben Sie einen eigenen Server, behalten Sie die Kontrolle, tragen aber auch den Wartungsaufwand.

Für einen eigenen Server erleichtern die offiziellen SDKs die Arbeit. Zunächst definieren Sie ein Tool, beschreiben die Eingabe mit einem Schema und legen Ihre Geschäftslogik in die Funktion. Den Rest des Protokolls übernimmt dann das SDK.

Wir schlagen meist diese Reihenfolge vor. Probieren Sie zunächst einen fertigen Server aus bekannter Quelle, der nur lesend zugreift. Schreiben Sie danach, wenn der echte Bedarf klar ist, einen schmalen eigenen Server. Somit lernen Sie dazu und vermeiden unnötige Zugriffsrechte.

In beiden Fällen behandeln Sie den Server wie Software eines Drittanbieters. Verfolgen Sie daher seine Version, lesen Sie die Änderungen und prüfen Sie seine Zugriffe regelmäßig.

Wo liegen die Grenzen von MCP und welche Missverständnisse gibt es?

MCP ist kein Zauberstab. Die offizielle Architekturübersicht sagt, MCP sei nur ein Protokoll für den Austausch von Kontext. Es legt zudem nicht fest, wie eine KI Anwendung ein Sprachmodell nutzt oder den Kontext verwaltet.

• MCP ist kein Modell. Die Antwortqualität bestimmt also das Modell selbst.
• MCP ist kein Agent. Ein Agent ist Planungs und Entscheidungslogik. MCP ist andererseits eine Verbindungsschicht, die ein Agent nutzen kann.
• MCP sorgt nicht von selbst für Sicherheit. Freigabe, Rechte und Überwachung liegen daher in Ihrer Verantwortung.
• Nicht jedes Werkzeug bietet einen MCP Server. Manche Dienste haben zum Beispiel keinen offiziellen Server.
• Das Protokoll entwickelt sich weiter. Manche Funktionen können sich zwischen Versionen ändern oder auslaufen.

Prüfen Sie deshalb vor einem Projektstart die aktuelle Version und die unterstützten Funktionen in der offiziellen Dokumentation. Die Konzepte in diesem Artikel sind dauerhaft, die Details dagegen können sich ändern.

Wie lässt sich MCP mit ähnlichen Begriffen vergleichen?

Die folgende Tabelle stellt MCP neben die Begriffe, mit denen es am häufigsten verwechselt wird. Jede Zeile enthält daher nur eine kurze Zusammenfassung. Details finden Sie in den verwandten Artikeln.

Wie die Tabelle zeigt, ersetzen sich diese Begriffe nicht gegenseitig. In der Praxis arbeiten in den meisten Projekten mehrere davon zusammen.

Welche Checkliste hilft vor dem Start eines MCP Projekts?

Die folgende Liste ist ein praktischer Einstieg für Unternehmer und Entwickler. Gehen Sie erst weiter, wenn Sie jeden Punkt mit Ja beantworten können.

• Ziel: Haben wir in einem Satz festgehalten, welche Aufgabe wir an die KI abgeben?
• Zugriff: Haben wir die Systeme und Daten aufgelistet, die der Assistent erreicht?
• Rechte: Haben wir für jedes System die engste nötige Berechtigung festgelegt?
• Freigabe: Gibt es bei nicht umkehrbaren Aktionen eine menschliche Bestätigung?
• Vertrauen: Haben wir Quelle und Betreuer des Servers geprüft?
• Gestaltung: Sind Tool Namen und Beschreibungen klar, eng und auf einen Zweck bezogen?
• Protokoll: Zeichnen wir Aufrufe auf und werten sie regelmäßig aus?
• Versionen: Haben wir Protokollversion und unterstützte Funktionen in der offiziellen Dokumentation geprüft?
• Datenschutz: Haben wir bei personenbezogenen Daten mit der Datenschutzstelle gesprochen?

Wenden Sie diese Liste in einer kleinen Testumgebung an. Der gesündeste Weg ist also, mit lesenden Tools zu beginnen und Schreibrechte erst mit wachsendem Vertrauen zu ergänzen. Damit beantworten Sie die Frage "Was ist MCP" gemeinsam mit Ihrem Team durch einen konkreten Versuch.

Wie startet ein Team, das fragt: Was ist MCP, den ersten Pilot?

Ein erster Pilot sollte klein, messbar und umkehrbar sein. Bevor Sie einen großen Umbau planen, wählen Sie zunächst einen einzigen Arbeitsablauf. Ein rein lesender Assistent, der interne Dokumente durchsucht, ist zum Beispiel ein guter Anfang.

1. Zunächst wählen Sie einen Anwendungsfall und notieren das Erfolgsmaß, zum Beispiel "das Team braucht weniger Zeit, um die Richtlinie zu finden".
2. Danach starten Sie mit einem fertigen Server aus bekannter Quelle oder einem schmalen Testserver.
3. Außerdem vergeben Sie nur Leserechte und öffnen Schreibzugriff nicht am ersten Tag.
4. Danach nutzen Sie ihn eine Woche mit zwei oder drei Kollegen und werten die Aufrufprotokolle aus.
5. Außerdem halten Sie falsche Tool Wahl, unnötigen Datenzugriff und unklare Antworten fest.
6. Schließlich vereinfachen Sie anhand der Ergebnisse die Tool Beschreibungen und entscheiden, ob Sie den Umfang erweitern.

Mit diesem Vorgehen sehen Sie also den echten Nutzen von MCP ohne Übertreibung. Zudem entdecken Sie mögliche Sicherheitsprobleme in einem kleinen Bereich.

Welche Fehler machen Teams mit MCP am häufigsten?

Die Fehler, die wir in der Praxis sehen, betreffen meist den Entwurf und nicht die Technik. Die folgende Liste sammelt die Stellen, an denen neue Teams am häufigsten stolpern.

• Einem Server zu viele Rechte geben und sagen: "Das schränken wir später ein."
• Tool Beschreibungen vage lassen, sodass das Modell das falsche Tool wählt.
• Einen Server aus unbekannter Quelle in Eile installieren.
• Schreib und Löschaktionen ohne Freigabe lassen.
• Kein Aufrufprotokoll führen und Probleme nicht zurückverfolgen können.
• MCP für einen Agenten oder eine Sicherheitslösung halten.

Allerdings ist keiner dieser Fehler ein Mangel des Protokolls. Alle entstehen, weil die Aufmerksamkeit nachlässt, sobald die Verbindung einfach wird. Also muss die Disziplin wachsen, wenn der Komfort wächst.

Wann ist die Frage "Was ist MCP" für Ihr Unternehmen relevant?

Nicht jedes Unternehmen braucht MCP. Für einen einfachen Chatbot oder eine einmalige Texterstellung kann es daher überflüssig sein. Stellen Sie sich dann drei Fragen, um zu entscheiden.

1. Muss der Assistent mehr als ein externes System erreichen?
2. Möchten wir dieselben Tools in mehr als einer KI Anwendung nutzen?
3. Wird die Pflege von Connectors für uns zur Dauerlast?

Antworten Sie auf zwei der drei Fragen mit Ja, lohnt sich ein ernsthafter Blick auf MCP. Sonst ist ein direkter API Aufruf womöglich die schlichtere Lösung.

Interessiert Sie außerdem die Einrichtung, behandelt unser Leitfaden zum selbst gehosteten KI Agenten die Grundschritte für den Betrieb eines Agenten auf eigener Infrastruktur. Möchten Sie einen Agenten an Ihre Geschäftsprozesse anbinden, unterstützt Sie unsere Leistung zur Entwicklung von KI Agenten. Für Grundlagen wie Kosten und große Sprachmodelle lesen Sie zudem unseren Artikel zu Tokens.