De
En
Fr
It
Es
Uk
Was ist ein MCP-Server?
Ein MCP-Server ist ein Programm, mit dem KI-Assistenten ein Produkt nutzen können: Er stellt die Aktionen und Daten des Produkts über das Model Context Protocol (MCP) bereit, sodass ein Modell wie Claude oder ChatGPT im Auftrag des Nutzers Informationen abrufen und Aktionen ausführen kann. Sie können ihn sich als API vorstellen, die für KI-Clients statt für menschliche Entwickler gestaltet ist.
Das Model Context Protocol ist ein offener Standard, den Anthropic im November 2024 vorgestellt hat, um ein wiederkehrendes Problem zu lösen: Jede KI-Anwendung brauchte eigenen Code, um sich mit jedem Tool zu verbinden. MCP definiert einen gemeinsamen Weg, auf dem eine KI-Anwendung (der Client, auch Host genannt) herausfindet, was ein Server anbietet, und es aufruft. Die Nachrichten verwenden JSON-RPC 2.0. Sobald ein Produkt einen MCP-Server hat, kann sich jeder MCP-kompatible Assistent ohne individuelle Integration damit verbinden, ähnlich wie jeder Browser jede Website öffnen kann, die HTTP spricht.
Was stellt ein MCP-Server bereit?
Ein MCP-Server stellt drei Arten von Fähigkeiten bereit: Tools, Ressourcen und Prompts. Tools werden am häufigsten genutzt. Ressourcen und Prompts sind je nach Produkt und je nachdem, was der Client unterstützt, sinnvolle Ergänzungen.
| Fähigkeit | Was sie ist | Wer über die Nutzung entscheidet | Beispiel in einem SaaS für Projektmanagement |
|---|---|---|---|
| Tools | Funktionen, die das Modell aufrufen kann, mit Name, Beschreibung und JSON-Eingabeschema | Das Modell, meist mit Zustimmung des Nutzers | create_task, update_status, log_time, search_tasks |
| Ressourcen | Lesbare Daten, identifiziert durch eine URI | Die Anwendung oder der Nutzer | Das README eines Projekts, ein Sprint-Bericht, ein Dokument |
| Prompts | Wiederverwendbare Prompt-Vorlagen mit Parametern | Der Nutzer, oft als Slash-Befehl | "Fasse diesen Sprint zusammen", "Entwirf Release Notes" |
Eine gute Tool-Beschreibung ist genauso wichtig wie der Code dahinter. Das Modell entscheidet anhand von Name, Beschreibung und Eingabeschema, welches Tool es aufruft, daher führen vage Beschreibungen zu falschen Aufrufen. Tool-Ergebnisse sollten kompakt und lesbar sein: Geben Sie die Felder zurück, die ein Modell braucht, nicht eine vollständige Datenbankzeile mit fünfzig Spalten.
Das Protokoll definiert auch Funktionen in umgekehrter Richtung, vom Client zum Server, etwa die Abfrage fehlender Eingaben beim Nutzer (Elicitation) oder die Anforderung einer Modellantwort (Sampling). Die Unterstützung dafür unterscheidet sich je nach Client, deshalb setzen die meisten produktiven Server in erster Linie auf Tools.
Wie verbindet sich ein MCP-Server: stdio oder HTTP?
MCP-Server verbinden sich über einen von zwei Standard-Transporten: stdio für lokale Server, die auf dem Rechner des Nutzers laufen, und HTTP (der Transport "Streamable HTTP") für Remote-Server, die in der Cloud laufen. Ein SaaS-Produkt braucht fast immer einen Remote-Server über HTTP.
| stdio (lokal) | Streamable HTTP (remote) | |
|---|---|---|
| Wo er läuft | Als Prozess, den der KI-Client auf dem Rechner des Nutzers startet | Auf Ihren Servern, erreichbar über eine URL |
| Installation | Nutzer installiert und konfiguriert ihn | Nutzer fügt eine URL hinzu und meldet sich an |
| Typische Nutzung | Entwicklertools, Dateisystem, lokale Datenbanken, CLIs | SaaS-Produkte, gemeinsam genutzte Unternehmenssysteme |
| Authentifizierung | Meist ein Token oder Schlüssel in der lokalen Konfiguration | OAuth-basierte Autorisierung pro Nutzer |
| Updates | Jeder Nutzer aktualisiert seine Kopie | Sie deployen einmal für alle |
| Logging und Kontrolle | Auf dem Rechner des Nutzers | Zentral, unter Ihrer Kontrolle |
Frühere Versionen der Spezifikation verwendeten für Remote-Server einen separaten Transport aus HTTP und Server-Sent Events. Der Transport Streamable HTTP hat ihn 2025 abgelöst. Wenn Sie einen älteren Server oder ein älteres SDK bewerten, prüfen Sie, welchen Transport es implementiert, denn neuere Clients erwarten den aktuellen.
Wie funktioniert die Authentifizierung bei einem MCP-Server?
Remote-MCP-Server authentifizieren Nutzer mit OAuth: Der Assistent schickt den Nutzer durch den Anmelde- und Zustimmungsbildschirm Ihres Produkts, erhält ein Access Token und legt dieses Token bei jeder Anfrage vor. Der Server handelt dann mit genau den Berechtigungen dieses Nutzers.
Die Autorisierungsspezifikation von MCP baut auf OAuth 2.1 und verwandten Standards auf, einschließlich Metadaten, die Clients mitteilen, wo sich Ihr Autorisierungsserver befindet. In der Praxis bedeutet das:
- Der Nutzer fügt die URL Ihres Servers in seinem Assistenten hinzu.
- Der Assistent findet Ihren Autorisierungsserver und startet einen OAuth-Ablauf.
- Der Nutzer meldet sich in Ihrem Produkt an und bestätigt den angeforderten Zugriff.
- Jeder Tool-Aufruf trägt ein Token, das auf diesen Nutzer und diese Berechtigungen beschränkt ist.
Zwei Regeln verhindern die meisten Sicherheitsprobleme. Erstens muss der Server prüfen, dass Tokens für ihn ausgestellt wurden, und darf das Token eines Clients nicht an andere Dienste weiterreichen. Zweitens müssen Berechtigungen bei jedem Aufruf auf dem Server durchgesetzt werden, genauso wie Ihre Web-App sie durchsetzt. Für interne Tools und frühe Prototypen ist ein API-Schlüssel pro Nutzer eine verbreitete Abkürzung, ein SaaS mit Kundenzugang sollte aber richtiges OAuth verwenden.
Wann sollte ein SaaS-Produkt einen MCP-Server ausliefern?
Ein SaaS-Produkt sollte einen MCP-Server ausliefern, wenn Kunden bei der Arbeit bereits KI-Assistenten nutzen und davon profitieren würden, diese Assistenten Daten im Produkt lesen oder ändern zu lassen. Wenn Nutzer regelmäßig Daten aus Ihrer App in ChatGPT oder Claude kopieren oder nach "einer Integration mit KI" fragen, ist das das Signal.
Gute Gründe, einen zu bauen:
- Ihr Produkt enthält Arbeitsdaten, die Menschen zusammengefasst, durchsucht oder aktualisiert haben wollen: Aufgaben, Tickets, CRM-Datensätze, Dokumente, Bestellungen, Analysen.
- Aktionen wiederholen sich: Datensätze anlegen, Status ändern, Zeiten erfassen, Antworten entwerfen.
- Kunden fragen nach KI-Funktionen, und Sie möchten ihnen entgegenkommen, ohne einen vollständigen Assistenten in Ihr Produkt einzubauen.
- Distribution: KI-Assistenten listen und empfehlen zunehmend Konnektoren. Wer dort verfügbar ist, bringt sein Produkt dorthin, wo Nutzer bereits arbeiten.
Gründe zu warten: Das Produkt hat noch keine stabile API, die Daten sind hochsensibel und Ihr Berechtigungsmodell ist nicht feingranular, oder der Kern-Workflow ist visuell und lässt sich nicht in Aktionen übersetzen, die ein Modell ausführen kann. In diesen Fällen bringen Sie zuerst API und Berechtigungen in Ordnung oder starten mit reinen Lese-Tools.
Ein MCP-Server ersetzt keine KI-Funktionen im Produkt. Er ergänzt sie: Funktionen im Produkt bedienen Nutzer innerhalb Ihrer Oberfläche, MCP bedient Nutzer, die in ihrem Assistenten arbeiten. Wenn Sie zwischen beidem abwägen, behandelt unser Leitfaden zur Integration von ChatGPT und Claude in Ihr Produkt die Seite innerhalb des Produkts.
Was sind die Sicherheitsrisiken von MCP-Servern?
Die Hauptrisiken sind Prompt Injection, zu weit gefasste Berechtigungen, destruktive Aktionen ohne Bestätigung und Datenlecks zwischen Nutzern. Ein MCP-Server gibt einem Modell die Fähigkeit zu handeln, deshalb muss der Server, nicht das Modell, der Ort sein, an dem Grenzen durchgesetzt werden.
- Prompt Injection: Text in einem Dokument, einer E-Mail oder einer Webseite kann das Modell anweisen, Tools aufzurufen, die der Nutzer nie beabsichtigt hat. Gehen Sie davon aus, dass Tool-Eingaben manipuliert sein können, und validieren Sie sie wie jede nicht vertrauenswürdige Eingabe.
- Manipulierte Tool-Beschreibungen: Clients sollten sich nur mit vertrauenswürdigen Servern verbinden, denn bösartige Beschreibungen können ein Modell steuern. Als Anbieter halten Sie Beschreibungen sachlich und stabil.
- Zu weit gefasste Scopes: Geben Sie Tokens nur die minimal nötigen Berechtigungen. Bieten Sie reine Lese-Scopes für Kunden an, die nur Suche und Zusammenfassungen wollen.
- Destruktive Aktionen: Vermeiden Sie Lösch- und Massenoperationen oder kennzeichnen Sie sie deutlich. Bevorzugen Sie Soft Deletes und Entwürfe. Viele Clients lassen den Nutzer Tool-Aufrufe bestätigen, verlassen Sie sich aber nicht allein darauf.
- Datenlecks zwischen Mandanten: Jede Abfrage muss auf den authentifizierten Nutzer und die Organisation beschränkt sein, mit Tests, die das belegen.
- Rate Limits und Kosten: Ein Modell in einer Schleife kann ein Tool hunderte Male aufrufen. Setzen Sie Rate Limits pro Nutzer.
- Audit-Logs: Protokollieren Sie, welcher Nutzer, welcher Client und welches Tool, mit Eingaben und Ergebnissen, damit Kunden sehen können, was ihr Assistent getan hat.
Wie wird ein MCP-Server gebaut?
Ein MCP-Server wird meist mit einem der offiziellen SDKs (verfügbar für TypeScript, Python und mehrere andere Sprachen) als dünne Schicht über einer bestehenden API oder Service-Schicht gebaut. Die Arbeit dreht sich weniger um das Protokoll als um die Auswahl der richtigen Tools und die Durchsetzung von Berechtigungen.
Ein typisches Projekt läuft in diesen Schritten ab:
- Aufgaben auswählen: Listen Sie die 5 bis 20 Aufgaben auf, die Nutzer einen Assistenten in Ihrem Produkt erledigen lassen würden. Wenige, gut beschriebene Tools sind besser als ein Tool für jeden Endpunkt.
- Tools gestalten: klare Namen, für ein Modell geschriebene Beschreibungen, typisierte Eingabeschemata, kompakte Ausgaben und hilfreiche Fehlermeldungen, von denen sich das Modell erholen kann.
- Autorisierung: OAuth für Remote-Server, Berechtigungen auf Nutzerebene bei jedem Aufruf, Scopes für Lesen und Schreiben.
- Sichere Standardwerte: Entwürfe statt sofortiger Veröffentlichung, Bestätigungen für unumkehrbare Aktionen, Grenzen für Massenoperationen.
- Tests mit echten Clients: Claude, ChatGPT und ein Entwicklertool verbinden, realistische Anfragen ausführen und prüfen, ob das Modell die richtigen Tools mit den richtigen Argumenten wählt.
- Beobachtbarkeit: Logging, Metriken pro Tool und Alarme bei Fehlerspitzen.
Für ein Produkt mit sauberer API dauert ein erster Remote-Server typischerweise 2 bis 6 Wochen. Wenn Ihr Produkt KI-Funktionen über MCP hinaus braucht, etwa Agenten, die Workflows selbstständig ausführen, siehe unseren Leitfaden zu den Kosten der KI-Agenten-Entwicklung.
Wie entwickeln wir MCP-Server bei Lytvynov Production?
Wir entwickeln MCP-Server zuerst für unsere eigenen Produkte. Unser internes Projektboard und das CMS unserer Website haben beide MCP-Server, sodass unser Team und unsere KI-Coding-Agenten jeden Tag aus Claude und anderen Assistenten heraus Aufgaben anlegen und aktualisieren, Zeiten erfassen und Inhalte der Website bearbeiten. Diese tägliche Nutzung hat uns gezeigt, wo solche Server brechen: vage Tool-Beschreibungen, fehlende Feldvalidierung, Schreib-Tools, die sofort veröffentlichen, wo ein Entwurf sicherer wäre, und Lücken zwischen dem Servercode und dem, was tatsächlich deployt ist.
Für Kunden wenden wir denselben Ansatz auf SaaS-Produkte und interne Systeme an. Wir haben Aufgaben- und Ticketsysteme gebaut, etwa eine individuelle Plattform für Aufgabenmanagement für ein Support-Team eines Telekommunikationsunternehmens, sowie LLM-Funktionen in unserem eigenen SaaS AI Resume Master. Unser Back-End-Stack ist PHP/Symfony mit React im Front-End, und wir bauen MCP-Server in der Sprache, die zu Ihrem Produkt passt, auf Basis Ihrer bestehenden API und Ihres Berechtigungsmodells.
Nächster Schritt
Wenn Sie einen MCP-Server für Ihr Produkt in Betracht ziehen, beginnen wir mit einem kurzen Scoping-Gespräch: Wir prüfen Ihre API und Ihre Berechtigungen, wählen den ersten Satz an Tools aus und geben Ihnen danach ein Festpreisangebot. Siehe unsere Services KI-Integration und KI-Agenten entwickeln lassen, oder kontaktieren Sie uns, um über Ihr Produkt zu sprechen.
