MCP-Server: Definition, Aufbau, Primitive und Abgrenzung

Ein MCP-Server ist ein kleines Hilfsprogramm, das einem KI-Assistenten (etwa ChatGPT oder Claude) Zugriff auf ein anderes System gibt, zum Beispiel auf eine Datenbank, ein Ticket-System oder einen Kalender. Er stellt drei Bausteine über das Model Context Protocol (MCP, ein offener Standard von Anthropic) bereit: Tools (ausführbare Aktionen, etwa „Ticket anlegen“), Resources (lesbare Daten, etwa ein Wiki-Eintrag) und Prompts (vorbereitete Anweisungs-Vorlagen). Damit lässt sich ein System einmal anbinden und von beliebigen KI-Anwendungen nutzen, ohne für jeden Anbieter eine eigene Schnittstelle zu programmieren.

Was ist ein MCP-Server?

Das Model Context Protocol (MCP) wurde im November 2024 von Anthropic als offener Standard veröffentlicht. Es beschreibt, wie eine KI-Anwendung mit externen Systemen sprechen darf, und teilt die Beteiligten in drei Rollen: den Host (die KI-Anwendung selbst, etwa Claude Desktop), den Client (die Verbindungsschicht innerhalb des Hosts) und den Server (das Hilfsprogramm, das Fähigkeiten eines Systems anbietet). Die Spezifikation liegt öffentlich auf [modelcontextprotocol.io](https://modelcontextprotocol.io/docs/getting-started/intro); fertige Baukästen (SDKs) für Server und Clients gibt es für Python, TypeScript, Kotlin, Swift und C#.

Ein MCP-Server exponiert drei Primitive über JSON-RPC 2.0:

Tools sind ausführbare Funktionen mit JSON-Schema-Input (Beispiel: create_ticket, run_sql). Der Client entscheidet auf Basis des Modell-Outputs, wann ein Tool aufgerufen wird, und ruft es über tools/call auf.
Resources sind lesbare Daten-Endpoints mit URI-Adresse (Beispiel: postgres://db/table, wiki://onboarding.md). Der Host bindet sie als Kontext ein und liest sie über resources/read.
Prompts sind vom Server bereitgestellte, parametrisierte Templates für wiederkehrende Workflows.

Vor dem eigentlichen Methodenverkehr läuft ein Initialize-Handshake: Client und Server tauschen Protokoll-Version und Capabilities aus. Erst nach dieser Capability-Negotiation beginnen tools/list, tools/call, resources/list und resources/read. Als Transport stehen zwei Optionen zur Wahl: stdio (lokale Prozesse, häufig für IDE-Integrationen wie Claude Desktop oder Cursor) und Streamable HTTP (Remote-Server, seit März 2025 der offizielle Ersatz für den bisherigen HTTP+SSE-Transport). Für Remote-Server ist OAuth 2.1 mit Delegated Access im Standard beschrieben.

Der Standard existiert, weil sich ohne ihn ein N×M-Integrationsproblem aufbaut: N LLM-Anbieter mal M Werkzeuge ergeben pro Kombination einen eigenen Adapter. Ein MCP-Server macht ein System einmal für alle MCP-fähigen Clients verfügbar. Anthropic, OpenAI, Google, Microsoft und AWS unterstützen MCP-Verbindungen in ihren Client-Produkten; für Enterprise-Systeme (Confluence/Jira, GitHub, ServiceNow, Snowflake, Salesforce, Azure, AWS) existieren offizielle MCP-Server der jeweiligen Anbieter. Die Community-Registry unter [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers) sammelt Referenz-Implementierungen und Anbieter-Server.

Abgrenzung: MCP-Server, MCP-Client, REST-API und Function Calling

Der Begriff wird häufig mit angrenzenden Konzepten vermischt.

Ebene	Rolle	Zweck
MCP-Server	Prozess-Seite, exponiert Fähigkeiten	Tools, Resources und Prompts eines Systems standardisiert bereitstellen
MCP-Client	Verbindungs-Seite im Host	Server-Verbindung aufbauen, Fähigkeiten dem Modell präsentieren, Tool-Calls ausführen
REST-/GraphQL-API	Schnittstelle für Entwickler	Programmatischer Zugriff mit individueller Auth-, Pagination- und Fehler-Semantik pro API
Function Calling	LLM-API-Mechanik	Modell erzeugt strukturierten Tool-Aufruf als JSON (OpenAI, Anthropic, Google)
Model Context Protocol	Der Standard als Oberbegriff	Spezifikation, Rollen (Host/Client/Server), Nachrichten, Transport

MCP-Server und MCP-Client sind komplementäre Rollen im selben Protokoll. Der Server exponiert Fähigkeiten, der Client konsumiert sie. Wer einen Server baut, definiert Tools und Resources; wer einen Client betreibt, wählt aus, welche Server verbunden werden und wie deren Tools dem Modell angeboten werden.

Gegenüber einer klassischen REST- oder GraphQL-API adressiert ein MCP-Server einen anderen Konsumenten. Eine API ist eine Schnittstelle für Entwickler, mit anbieterspezifischer Auth-, Pagination- und Fehler-Semantik. Ein MCP-Server ist eine Schnittstelle für LLM-Agenten mit einheitlicher Discovery, Fähigkeitsverhandlung und Tool-Semantik. Ein MCP-Server wrappt in der Regel eine bestehende REST-API und übersetzt sie in die MCP-Konventionen.

Function Calling liegt eine Ebene tiefer. Es beschreibt, wie ein Modell selbst einen strukturierten Aufruf formuliert (Name plus JSON-Argumente). Der MCP-Client bekommt vom Server die Tool-Definitionen, reicht sie an das Modell weiter, und das Modell entscheidet per Function Calling. Function Calling ist die Modell-API-Ebene, der MCP-Server die Server-Ebene. Das übergeordnete Model Context Protocol umfasst beide Endpunkte des Standards sowie die Nachrichten dazwischen.

Beispiel: Ein MCP-Server für ein internes Ticket-System

Ein Entwickler-Team betreibt einen MCP-Server für sein internes Ticket-System. Der Server exponiert drei Tools (search_tickets, create_ticket, update_status) und eine Resource (ticket://<id> für den Volltext eines Tickets). Alle Werkzeuge sprechen intern die REST-API des Ticket-Systems an; nach außen sprechen sie MCP mit einheitlicher Discovery und JSON-Schema-Beschreibung.

Ein Support-Team verbindet den Server in Claude Desktop, um Tickets direkt aus dem Chat-Interface zu suchen und anzulegen. Ein zweites Team nutzt denselben Server in einer Cursor-IDE für Bug-Triage. Eine dritte Anwendung bindet ihn aus einer LangGraph-Agent-Runtime für automatisierte Eskalationen ein. In allen drei Fällen ist der Server derselbe: einmal gebaut, dreifach genutzt. Vor MCP hätte jedes Konsumenten-Setup eine eigene Ticket-System-Anbindung entwickelt.