MCP-Server (Model Context Protocol)
Ein MCP-Server stellt Werkzeuge, Daten und Vorlagen über das Model Context Protocol bereit, sodass beliebige KI-Anwendungen sie nutzen können, ohne dass für jede Kombination aus Anwendung und Werkzeug eine eigene Anbindung gebaut werden muss.
Welches Problem MCP löst
Vor MCP war jede Anbindung ein Einzelfall. Wer wollte, dass drei KI-Anwendungen auf vier Datenquellen zugreifen, baute zwölf Integrationen. Jede mit eigener Authentifizierung, eigenem Fehlerverhalten, eigener Pflege. Kommt eine fünfte Datenquelle dazu, sind es fünfzehn.
MCP macht daraus einen Adapter. Die Datenquelle wird einmal als Server bereitgestellt, die Anwendung spricht einmal das Protokoll. Aus n×m Integrationen werden n+m. Bei drei Anwendungen und vier Quellen also sieben statt zwölf, und der Vorteil wächst mit jeder weiteren Seite.
Das Protokoll wurde Ende 2024 von Anthropic veröffentlicht und offen spezifiziert. Es ist seither breit übernommen worden, auch von Anbietern, die mit Anthropic nichts zu tun haben. Genau das war der Punkt: Ein Standard, den nur ein Hersteller unterstützt, löst das Problem nicht.
Was ein Server anbietet: Tools, Resources, Prompts
Ein MCP-Server kann drei Arten von Bausteinen bereitstellen, und die Unterscheidung ist wichtiger, als sie zunächst klingt, weil sie festlegt, wer über die Nutzung entscheidet.
Tools sind Funktionen, die das Modell aufrufen kann: eine Suche ausführen, einen Datensatz anlegen, eine Berechnung starten. Über den Aufruf entscheidet das Modell im Rahmen dessen, was die Anwendung zulässt.
Resources sind Daten, die die Anwendung dem Gespräch beilegt: eine Datei, ein Datenbankauszug, ein Log. Hier entscheidet nicht das Modell, sondern die Anwendung oder der Nutzer, was mitgegeben wird.
Prompts sind vorbereitete Vorlagen, die der Nutzer bewusst auswählt – etwa ein fertiger Ablauf für eine wiederkehrende Aufgabe.
Welche Form passt, hängt vom Ablauf ab: Eine Datei, die die Anwendung gezielt bereitstellt, eignet sich als Resource. Eine Suche, deren Suchbegriff das Modell aus der Frage ableitet, kann sinnvoll als Tool angeboten werden. Reines Lesen macht einen Aufruf nicht automatisch zur Resource.
Wie die Verbindung läuft
MCP ist eine Client-Server-Verbindung auf Basis von JSON-RPC. Die KI-Anwendung ist der Host und betreibt pro Server einen Client. Beim Verbindungsaufbau handeln beide Seiten aus, welche Fähigkeiten sie unterstützen, danach fragt der Client ab, welche Tools, Resources und Prompts der Server anbietet.
Für lokale Prozesse gibt es stdio. Für entfernte Server ist Streamable HTTP der aktuelle Standardtransport. Private Daten und schreibende Werkzeuge brauchen geeignete Authentifizierung und Berechtigungen. Ein bewusst öffentlicher, lesender Server kann ohne Anmeldung auskommen.
Der lokale Weg ist einfacher, als er klingt, und für alles gut geeignet, was auf dem eigenen Rechner liegt. Der entfernte Weg ist der interessantere und der aufwendigere, weil ab dort jede Frage der Zugriffskontrolle wieder auftaucht.
Abgrenzung zu Function Calling und zu einer REST-API
Die häufigste Verwechslung betrifft Function Calling. Function Calling ist die Fähigkeit eines Modells, einen strukturierten Funktionsaufruf vorzuschlagen. MCP ist der Standard, über den Werkzeuge angeboten und beschrieben werden. Ein Host kann MCP-Tools über Function Calling an ein Modell anbinden. Das Protokoll selbst setzt diese Modellfähigkeit nicht voraus: Das eine ist eine Modellfähigkeit, das andere ein Protokoll zwischen Programmen.
Eine REST-API und MCP können dieselben Backend-Funktionen nutzen. MCP standardisiert unter anderem Erkennung, Beschreibung und Aufruf der angebotenen Bausteine. Auch REST-APIs können maschinenlesbare Beschreibungen wie OpenAPI haben; der Unterschied ist nicht, dass nur MCP ein Schema hätte.
Was beim eigenen Server tatsächlich Arbeit macht
Ein kleiner Prototyp ist schnell gebaut. Für den verlässlichen Betrieb sind unter anderem diese drei Punkte entscheidend:
Die Beschreibungstexte der Tools sind Teil des Modellkontexts. Sie beeinflussen, wann ein Werkzeug gewählt wird. Ähnliche oder unklare Beschreibungen können Fehlaufrufe begünstigen. Tests mit typischen Fragen helfen, die Zuständigkeiten zu schärfen.
Fehler müssen verständlich sein. Eine Rückmeldung mit fehlendem Parameter und erlaubten Werten erleichtert die Korrektur. Trotzdem müssen die Anwendung und der Server Wiederholungen begrenzen; eine verständliche Meldung garantiert keinen erfolgreichen zweiten Versuch.
Alles, was zurückkommt, ist unsicherer Text. Ein Tool-Ergebnis landet im Kontext und kann Anweisungen enthalten, die dort nicht hingehören. Wer fremde Inhalte durchreicht – Webseiten, E-Mails, Ticketsysteme – braucht eine Grenze zwischen Daten und Anweisungen. Das ist keine theoretische Sorge, sondern der Punkt, an dem Werkzeuganbindung zum Sicherheitsthema wird.
Auf designare.at stellt Evitas MCP-Server unter anderem search_knowledge für die semantische Suche und get_services für das Leistungsprofil bereit. Neue Suchabrufe werden im öffentlichen Aktivitätsbereich mit einer kurzen Themenbezeichnung und verfügbaren Quellenlinks angezeigt. Private Anfrageformulierungen werden dort nicht veröffentlicht. Evitas MCP-Anbindung im Detail.
Wann sich ein eigener Server nicht lohnt
Bei einer einzigen Anwendung und einer Datenquelle ist eine direkte API-Anbindung oft einfacher. MCP kann trotzdem sinnvoll sein, wenn der Client das Protokoll bereits unterstützt oder spätere Wiederverwendung geplant ist. Der Nutzen muss zum zusätzlichen Betriebsaufwand passen.
Ebenfalls kein Fall für einen Server: Daten, die sich nicht ändern und einfach in den Kontext gelegt werden können. Und Aufgaben, bei denen ein festes Skript zuverlässiger ist als eine Entscheidung des Modells. Nicht alles, was aufrufbar ist, sollte aufrufbar sein.