Was ist ein MCP-Server? Model Context Protocol einfach erklärt

Eric Fischer • 24. August 2026 • 8 Min. Lesezeit

MCP-Server erklärt: OIT-Mitarbeiter arbeitet konzentriert am Monitor an einer Model-Context-Protocol-Anbindung

KI: Künstliche Intelligenz-Experte

Eric Fischer

OIT GmbH

Ein MCP-Server ist ein Programm, das einer KI-Anwendung auf standardisiertem Weg Werkzeuge und Daten zur Verfügung stellt. MCP steht für Model Context Protocol – ein offener Standard, den Anthropic im November 2024 veröffentlicht hat. Statt für jede Kombination aus KI-Modell und Fachanwendung eine eigene Schnittstelle zu bauen, sprechen beide Seiten dasselbe Protokoll. Das gängige Bild dafür: MCP ist der Universalanschluss für KI-Anwendungen.

Stand: 24.08.2026 · Basis: MCP-Spezifikation 2026-07-28 (aktuelle Version)

Was ist ein MCP-Server – kurz und präzise

Ein MCP-Server ist kein Server im Sinne einer Maschine im Rechenzentrum. Das ist die häufigste Verwirrung beim Einstieg. Gemeint ist ein Prozess, ein laufendes Programm – es kann genauso gut lokal auf deinem Notebook laufen wie zentral in der Cloud.

Die Aufgabe dieses Programms: Es stellt einer KI-Anwendung Fähigkeiten bereit, die das Sprachmodell selbst nicht hat. Ein Sprachmodell kann von sich aus keine Rechnung in deinem ERP anlegen, keinen Kalendereintrag lesen und keine Datenbank abfragen. Ein MCP-Server gibt ihm genau diese Möglichkeit – kontrolliert, dokumentiert und in einem Format, das jede MCP-fähige KI-Anwendung versteht.

Wie funktioniert ein MCP-Server?

MCP kennt drei Beteiligte. Diese Unterscheidung ist der Schlüssel zum Verständnis:

MCP Host
Die KI-Anwendung, mit der du arbeitest – zum Beispiel Claude Desktop, Claude Code, Visual Studio Code oder ChatGPT.

MCP Client
Die Verbindungskomponente im Host. Pro Server ein eigener Client – vier Server bedeuten vier Clients.

MCP Server
Das Programm, das die Werkzeuge und Daten bereitstellt – lokal oder zentral betrieben.

Technisch besteht MCP aus zwei Schichten. Die Datenschicht definiert das Protokoll selbst und setzt auf JSON-RPC 2.0 auf. Die Transportschicht regelt, wie die Nachrichten physisch übertragen werden. Beide sind bewusst getrennt: Dasselbe Nachrichtenformat funktioniert über jeden Transportweg.

Welche Bausteine kann ein MCP-Server bereitstellen?

Ein MCP-Server kann der KI-Anwendung drei Arten von Fähigkeiten anbieten. In der Praxis sind Tools der wichtigste Fall.

Baustein	Was es ist	Beispiel aus dem Alltag
Tools	Ausführbare Funktionen, die das Modell aufrufen kann	„Lege im CRM einen neuen Kontakt an“, „Frage den Lagerbestand ab“
Resources	Datenquellen, die als Kontext gelesen werden	Das Schema einer Datenbank, der Inhalt einer Datei
Prompts	Vorgefertigte Vorlagen für wiederkehrende Abläufe	„Erstelle den Monatsbericht nach unserem Standardaufbau“

Jeder Baustein hat Methoden zum Auflisten (tools/list) und zum Ausführen (tools/call). Seit der aktuellen Spezifikation liefern die Listen-Endpunkte für alle Clients dasselbe Ergebnis – sie variieren nicht mehr pro Verbindung.

stdio oder Streamable HTTP: welcher Transportweg passt?

MCP unterstützt zwei Transportmechanismen. Die Wahl entscheidet darüber, wo der Server läuft und wer ihn erreichen kann.

Kriterium	stdio	Streamable HTTP
Läuft	Lokal, als Kindprozess des Hosts	Remote, als Webdienst
Nutzer	Typisch ein Client	Typisch viele Clients
Authentifizierung	Nicht nötig – gleiche Maschine	OAuth empfohlen, auch Bearer-Token oder API-Key
Geeignet für	Lokale Dateien, Entwicklungswerkzeuge	Firmenweite Systeme: ERP, CRM, Ticketsystem

Für Unternehmen ist meist Streamable HTTP die richtige Wahl: Ein zentral betriebener MCP-Server bedient das ganze Team, und Zugriffsrechte lassen sich an einer Stelle steuern. Der ältere HTTP+SSE-Transport gilt als abgekündigt und sollte für Neuentwicklungen nicht mehr verwendet werden.

Was hat die Spezifikation 2026-07-28 geändert?

Die aktuelle Protokollversion ist 2026-07-28, Vorgänger war 2025-11-25. Die Änderungen sind für den Betrieb im Unternehmen erheblich – viele Anleitungen im Netz beschreiben noch den älteren Stand:

MCP ist jetzt zustandslos. Der frühere initialize-Handshake und der Mcp-Session-Id-Header sind entfallen. Jede Anfrage trägt Protokollversion und Client-Fähigkeiten im Feld _meta. Praktische Folge: Ein MCP-Server läuft hinter einem gewöhnlichen Load Balancer, ohne Sticky Sessions und ohne gemeinsamen Session-Speicher. Das vereinfacht den Betrieb deutlich.
Neu: server/discover. Jeder Server muss diesen Aufruf beantworten und dabei unterstützte Protokollversionen, Fähigkeiten und Identität nennen. Clients können damit vorab die passende Version aushandeln.
Benachrichtigungen laufen über subscriptions/listen. Ein einziger langlebiger Antwort-Stream ersetzt den früheren HTTP-GET-Endpunkt und resources/subscribe. Clients melden sich gezielt für die Änderungstypen an, die sie brauchen.
Tasks und interaktive Oberflächen sind Extensions. Lang laufende Vorgänge (io.modelcontextprotocol/tasks) und HTML-Oberflächen im Chat („MCP Apps“) sind aus dem Kern herausgelöst und leben als offizielle Erweiterungen. Sie versionieren sich unabhängig vom Protokoll und werden über Kennungen im Reverse-Domain-Format identifiziert.
Volles JSON Schema 2020-12 für Werkzeug-Schemata, inklusive oneOf, anyOf und allOf.

Abgekündigt seit 2026-07-28, frühester Entfall ab 28.07.2027: Sampling (stattdessen direkte Anbindung an die LLM-Anbieter-API), Roots (stattdessen Werkzeugparameter, Resource-URIs oder Serverkonfiguration), Logging (stattdessen stderr bzw. OpenTelemetry) und die Dynamic Client Registration. Wer heute neu baut, sollte diese vier nicht mehr verwenden.

MCP-Server oder klassische API-Anbindung?

Die berechtigte Frage: Wozu ein neues Protokoll, wenn es REST-APIs gibt? Der Unterschied liegt nicht in der Technik, sondern im Aufwand bei mehreren Systemen.

Kriterium	Eigene API-Anbindung	MCP-Server
Aufwand bei 5 Systemen, 3 KI-Anwendungen	Bis zu 15 Integrationen	5 Server, alle 3 Anwendungen nutzen sie
Werkzeug-Beschreibung	Manuell im Prompt gepflegt	Vom Server geliefert, maschinenlesbar
Wechsel des KI-Anbieters	Integration meist neu bauen	Server bleibt unverändert
Sinnvoll bei	Einem System, einem festen Anwendungsfall	Mehreren Systemen oder KI-Anwendungen

Ehrlich gesagt: Bei genau einem System und einem festen Anwendungsfall ist eine direkte API-Anbindung oft der kürzere Weg. MCP zahlt sich ab dem Punkt aus, an dem mehrere Systeme oder mehrere KI-Werkzeuge im Spiel sind – und ab dem Punkt, an dem du dir die Freiheit erhalten willst, das Modell zu wechseln.

Wofür setzen Unternehmen MCP-Server ein?

Fachsysteme öffnen
ERP, CRM oder Ticketsystem werden für KI-Assistenten zugänglich – lesend für Auswertungen, schreibend für Routinevorgänge.

Wissen erschließen
Dokumentationen, Handbücher und Wikis werden als Resources bereitgestellt, statt sie in Prompts zu kopieren.

Abläufe automatisieren
Angebot erstellen, Ticket klassifizieren, Bericht zusammenstellen – als Tools abgebildet.

Eigene Werkzeuge kapseln
Gewachsene interne Skripte bekommen eine einheitliche Schnittstelle, statt in jedem Team neu erfunden zu werden.

Worauf kommt es beim Betrieb eines MCP-Servers an?

Ein MCP-Server führt Aktionen in echten Systemen aus. Das macht ihn nützlich – und erfordert Sorgfalt. Die fünf Punkte, die in der Praxis am häufigsten unterschätzt werden:

Rechte eng schneiden. Der Server sollte genau die Berechtigungen haben, die seine Werkzeuge brauchen – nicht mehr. Ein Lesezugriff bleibt ein Lesezugriff.
Schreibende Werkzeuge trennen. Lesen und Schreiben in getrennten Werkzeugen abbilden. So lässt sich Schreiben gezielt einzelnen Nutzergruppen erlauben.
Werkzeugbeschreibungen sind Teil des Prompts. Was in der description steht, landet im Kontext des Modells. Ungenaue Beschreibungen führen zu falsch aufgerufenen Werkzeugen – das ist die häufigste Fehlerquelle überhaupt.
Nachvollziehbarkeit herstellen. Wer hat wann welches Werkzeug mit welchen Parametern aufgerufen? Ohne Protokollierung ist im Zweifelsfall nichts rekonstruierbar.
Datenschutz mitdenken. Sobald personenbezogene Daten über einen MCP-Server an ein Sprachmodell gehen, ist die Frage nach Verarbeitungsort und Auftragsverarbeitung relevant – unabhängig davon, wie gut die Technik funktioniert.

Häufige Fragen zu MCP-Servern

Ist ein MCP-Server ein Server im klassischen Sinn?

Nein. Es ist ein laufender Prozess, keine Hardware. Er kann lokal auf einem Notebook laufen (stdio-Transport) oder zentral als Webdienst (Streamable HTTP).

Was ist der Unterschied zwischen MCP-Server und API?

Ein MCP-Server nutzt in der Regel selbst APIs. Der Unterschied ist die Standardisierung nach außen: Er beschreibt seine Werkzeuge in einem Format, das jede MCP-fähige KI-Anwendung ohne Anpassung versteht. Eine REST-API muss für jede KI-Anwendung einzeln eingebunden werden.

Kann ChatGPT MCP-Server nutzen?

Ja. MCP wird über den Anthropic-Ursprung hinaus breit unterstützt – unter anderem von Claude, ChatGPT, Visual Studio Code und Cursor. Ein Server, der einmal gebaut ist, funktioniert in allen MCP-fähigen Anwendungen.

Sind MCP-Server sicher?

Das Protokoll bringt Authentifizierungsmechanismen mit – für Streamable HTTP wird OAuth empfohlen. Sicherheit entsteht aber in der Umsetzung: eng geschnittene Rechte, getrennte Lese- und Schreibwerkzeuge, Protokollierung aller Aufrufe. Ein MCP-Server ist so sicher wie die Rechte, die man ihm gibt.

Wie OIT dabei unterstützt

Wir bauen MCP-Server für Systeme mittelständischer Unternehmen – Microsoft 365, Odoo, WordPress und gewachsene Eigenentwicklungen – und betreiben sie im OIT KI Gateway: einer eigenen, isolierten KI-Plattform mit Nutzerverwaltung, Kostenkontrolle und MCP-Anbindung, gehostet in Deutschland. Einen Überblick über unser gesamtes Portfolio findest du unter Leistungen.

Wenn du wissen willst, ob sich MCP für einen konkreten Anwendungsfall bei dir lohnt: Wir schauen uns das gemeinsam an – und sagen auch, wenn eine einfache API-Anbindung der günstigere Weg wäre.

Jetzt Erstgespräch anfragen

Weiterlesen: MCP im Glossar · KI-Integrationen für Microsoft 365 und Odoo · KI-Compliance und EU AI Act · KI-Implementierung im Mittelstand