MCP-Server erstellen: Anleitung für Unternehmen

Einen MCP-Server erstellen Sie, indem Sie mit einem offiziellen SDK (meist Python oder TypeScript) eine kleine Anwendung schreiben, die ausgewählte Funktionen und Daten eines Systems als Werkzeuge über das Model Context Protocol bereitstellt. KI-Anwendungen wie Claude, ChatGPT, Copilot oder Cursor erkennen diese Werkzeuge dann automatisch und können sie aufrufen. Ein einfacher Server läuft in einer Stunde. Ein Server, der im Unternehmen sicher an echte Daten darf, braucht dagegen eher Tage bis wenige Wochen, und der größte Teil davon fließt in Rechte, Authentifizierung, Tests und Betrieb, nicht in den Code.

Wir bei TAISC verbinden KI-Agenten für den Mittelstand mit bestehenden Systemen und nutzen MCP auch selbst im Alltag, etwa um Analysedaten per Klartext abzufragen. In diesem Beitrag zeigen wir, wie Sie einen eigenen MCP-Server Schritt für Schritt aufbauen, wann sich das überhaupt lohnt, worauf Sie bei der Sicherheit achten müssen und mit welchen Kosten Sie rechnen sollten. Was MCP grundsätzlich ist und warum es sich als Standard durchgesetzt hat, beschreiben wir ausführlich im Beitrag Model Context Protocol (MCP): Wie Unternehmen mit ihren eigenen Daten chatten.

Was ist ein MCP-Server, und wann brauchen Sie einen eigenen?

Ein MCP-Server ist die standardisierte Brücke zwischen einer KI-Anwendung und einem konkreten System, zum Beispiel einer Datenbank, einem Ticketsystem oder einer internen API. Er meldet dem KI-Modell, welche Fähigkeiten er anbietet, und führt die Aufrufe aus, wenn das Modell sie anfordert. Das Model Context Protocol kennt dafür drei Bausteine:

• Tools: Funktionen, die das Modell aufrufen kann, etwa „Auftragsstatus abfragen” oder „Ticket anlegen”.
• Resources: Daten, die der Server zum Lesen bereitstellt, etwa ein Dokument oder ein Datensatz.
• Prompts: vorbereitete Vorlagen für wiederkehrende Aufgaben.

In der Praxis sind Tools der wichtigste Teil. Technisch steckt dahinter dasselbe Prinzip wie beim Tool- bzw. Function-Calling: Das Modell schlägt einen Aufruf vor, Ihr Code führt ihn aus und gibt das Ergebnis zurück. Der Unterschied ist, dass Sie die Anbindung nur einmal bauen und jede MCP-fähige Anwendung sie nutzen kann.

Einen eigenen Server brauchen Sie nicht immer. Für verbreitete Tools wie GitHub, Notion, Slack oder viele Datenbanken gibt es bereits fertige Server, oft direkt vom Hersteller. Ein eigener Server lohnt sich, wenn mindestens einer dieser Punkte zutrifft:

• Sie wollen ein eigenes oder branchenspezifisches System anbinden, für das es keinen Server gibt.
• Sie wollen der KI nur einen engen Ausschnitt eines Systems freigeben, statt den vollen Funktionsumfang eines Hersteller-Servers.
• Sie brauchen eigene Geschäftslogik zwischen Modell und Daten, etwa Plausibilitätsprüfungen, Berechnungen oder Freigaben.
• Die Daten dürfen Ihr Netz nicht verlassen, und der Server soll in Ihrer Infrastruktur laufen.

Eigener MCP-Server, fertiger Server oder Workflow-Tool?

Bevor Sie Code schreiben, lohnt sich ein Blick auf die Alternativen. Diese Übersicht nutzen wir in Erstgesprächen als Orientierung:

Ein Hinweis zur zweiten Zeile: Wenn Sie ohnehin mit n8n automatisieren, kann n8n selbst als MCP-Server auftreten und bestehende Workflows als Werkzeuge bereitstellen. Das ist oft der schnellste Weg, wenn die Logik schon in einem Workflow steckt. Mehr dazu im Beitrag n8n im Unternehmen. Für einen einmaligen, klar umrissenen Abruf ist dagegen ein direkter API-Aufruf im eigenen Code oft einfacher als jeder MCP-Server.

MCP-Server erstellen in sechs Schritten

Die folgenden Schritte entsprechen dem Vorgehen, mit dem wir Anbindungen für KI-Agenten aufbauen. Die Reihenfolge ist bewusst gewählt: Erst kommen Zuschnitt und Rechte, dann der Code.

1. Welche Aufgabe soll die KI mit dem System erledigen?

Starten Sie nicht mit der Frage „Welche Endpunkte hat unsere API?”, sondern mit den Fragen, die Mitarbeitende der KI stellen sollen. Zum Beispiel: „Wie ist der Status von Auftrag 104711?” oder „Welche offenen Tickets betreffen Kunde X?”. Aus diesen Fragen leiten Sie eine kleine Zahl von Werkzeugen ab. Drei bis acht gut geschnittene Tools funktionieren in der Regel besser als fünfzig, die jede API-Funktion eins zu eins abbilden. Je mehr Werkzeuge ein Modell zur Auswahl hat, desto öfter greift es zum falschen.

Legen Sie in diesem Schritt auch fest, welche Werkzeuge nur lesen und welche etwas verändern. Für den Einstieg empfehlen wir fast immer einen reinen Lese-Server.

2. Welches SDK und welcher Transport passen?

Für MCP gibt es offizielle SDKs in mehreren Sprachen, darunter Python, TypeScript, C#, Java und Go. Nehmen Sie die Sprache, in der Ihr Team ohnehin arbeitet. Für Python ist der schnellste Einstieg die im SDK enthaltene FastMCP-Schnittstelle, für TypeScript das Paket @modelcontextprotocol/sdk.

Wichtiger als die Sprache ist der Transport, also der Weg, über den Client und Server miteinander sprechen:

• stdio: Der Server läuft als lokaler Prozess auf dem Rechner der Nutzerin oder des Nutzers. Ideal für Prototypen, Entwicklerwerkzeuge und Einzelplatz-Szenarien.
• Streamable HTTP: Der Server läuft zentral als Webdienst und wird von vielen Nutzern gleichzeitig verwendet. Das ist der Standard für den Unternehmenseinsatz, weil Sie Zugriffe zentral steuern, protokollieren und aktualisieren können.

Ältere Anleitungen beschreiben noch einen separaten SSE-Transport. Der ist inzwischen durch Streamable HTTP abgelöst, für neue Server sollten Sie ihn nicht mehr verwenden.

3. Wie beschreiben Sie Tools so, dass die KI sie richtig nutzt?

Die Beschreibung eines Tools ist für das Modell die Bedienungsanleitung. Sie entscheidet darüber, ob die KI das richtige Werkzeug mit den richtigen Parametern aufruft. Ein minimaler Server in Python sieht so aus:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("auftraege")

@mcp.tool()
def auftragsstatus(auftragsnummer: str) -> dict:
    """Liefert Status, Liefertermin und Positionen eines Kundenauftrags.
    Nur lesend. Die Auftragsnummer ist sechsstellig, z. B. 104711."""
    return auftragsdienst.lese_auftrag(auftragsnummer)

if __name__ == "__main__":
    mcp.run()

Name, Typ-Hinweise und Docstring werden automatisch zur Tool-Definition, die das Modell sieht. Drei Regeln haben sich bewährt:

• Fachlich benennen: auftragsstatus statt get_order_v2. Das Modell versteht Fachsprache besser als interne Kürzel.
• Format der Eingaben nennen: Beispiele für gültige Werte in der Beschreibung verhindern viele Fehlaufrufe.
• Strukturiert antworten: Geben Sie feste Felder zurück statt Fließtext. So kann die KI Ergebnisse zuverlässig weiterverarbeiten, und Ihr Code kann sie prüfen.

Zusätzlich können Sie Tools mit Hinweisen versehen, etwa ob ein Werkzeug nur liest oder etwas löscht. Gute Clients nutzen das, um vor riskanten Aufrufen eine Bestätigung einzuholen. Verlassen Sie sich aber nicht allein darauf, die eigentliche Absicherung gehört in den Server.

4. Welche Rechte bekommt der Server?

Hier entscheidet sich, ob ein MCP-Server ein nützliches Werkzeug oder ein Sicherheitsrisiko ist. Der Grundsatz heißt Least Privilege: Der Server bekommt genau die Rechte, die seine Tools brauchen, und keine mehr. Konkret bedeutet das:

• Ein eigener technischer Zugang mit Leserechten auf genau die benötigten Tabellen oder Endpunkte, kein Admin-Konto.
• Bei zentral betriebenen Servern eine Anmeldung über OAuth, die die MCP-Spezifikation für HTTP-Server vorsieht. So handelt die KI im Namen der jeweiligen Person und sieht nur, was diese Person sehen darf.
• Zugangsdaten gehören in einen Secret-Speicher, nicht in den Code und nicht in die Tool-Beschreibung.
• Tokens, die der Client mitschickt, reicht der Server nicht ungeprüft an nachgelagerte Systeme weiter. Die Spezifikation verbietet dieses „Token Passthrough” ausdrücklich.

5. Wie testen Sie einen MCP-Server?

Für den ersten Test gibt es den MCP Inspector, ein offizielles Werkzeug, das Sie mit npx @modelcontextprotocol/inspector starten. Damit sehen Sie, welche Tools Ihr Server meldet, und können sie von Hand aufrufen, bevor ein Modell beteiligt ist.

Danach folgt der wichtigere Test: echte Fragen aus dem Fachbereich. Sammeln Sie 20 bis 50 typische Anfragen und prüfen Sie, ob die KI das richtige Tool wählt, die Parameter korrekt füllt und die Antwort stimmt. Nehmen Sie bewusst auch Grenzfälle auf: unvollständige Angaben, falsche Auftragsnummern, Fragen, die der Server gar nicht beantworten darf. Wie solche Testsätze systematisch aufgebaut werden, beschreiben wir im Beitrag zu Ground-Truth-Daten in RAG-Systemen. Das Prinzip gilt für MCP genauso.

6. Wie bringen Sie den Server in den Betrieb?

Ein produktiver MCP-Server ist ein normaler Webdienst und braucht dieselbe Sorgfalt wie jede andere Anwendung:

• Hosting in Ihrer Cloud oder On-Premise, nah an den Daten.
• Protokollierung jedes Tool-Aufrufs: wer, wann, welches Tool, mit welchen Parametern.
• Versionierung der Tool-Definitionen, damit Änderungen nachvollziehbar sind und nicht still passieren.
• Monitoring von Fehlerraten und Antwortzeiten.

Wie sicher ist ein eigener MCP-Server?

So sicher, wie Sie ihn bauen. Die bekannten Angriffe auf MCP richten sich selten gegen das Protokoll selbst, sondern gegen zu großzügige Rechte und gegen die Tatsache, dass Sprachmodelle Anweisungen in Daten nicht zuverlässig von echten Anweisungen unterscheiden. Ein eigener Server hat hier einen Vorteil: Sie kontrollieren den Code und die Tool-Beschreibungen selbst und sind nicht auf fremde Server angewiesen.

Diese Checkliste gehen wir vor jedem Go-live durch:

1. Nur lesen, wo es reicht. Schreibende Tools nur dort, wo ein klarer Nutzen besteht.
2. Eingaben im Server prüfen. Jeder Parameter wird validiert, bevor er an eine Datenbank oder API geht. Keine frei zusammengesetzten Abfragen aus Modelleingaben.
3. Mensch bei kritischen Aktionen. Alles, was löscht, versendet oder Geld bewegt, braucht eine Freigabe. Warum dieses Human-in-the-Loop-Prinzip die bessere Architektur ist, haben wir in KI, die nachfragt beschrieben.
4. Mit Prompt Injection rechnen. Inhalte aus Tickets, E-Mails oder Dokumenten können versteckte Anweisungen enthalten. Der Server darf nichts tun, nur weil ein Text es verlangt.
5. Ausgaben begrenzen. Liefern Sie nur die Felder, die die Aufgabe braucht, und keine kompletten Datensätze mit personenbezogenen Daten.
6. Fremde Server prüfen. Wenn Sie Ihren Server mit Servern Dritter kombinieren, prüfen Sie deren Herkunft und Tool-Beschreibungen, und fixieren Sie Versionen.

Aus der Praxis: Was wir aus dem RMEP-Projekt übertragen

Für die Beteiligungsgesellschaft RMEP haben wir den monatlichen Portfolio-Report mit KI-Agenten automatisiert. Die Pipeline ruft die Zahlen aus den Datenquellen per API ab, Agenten prüfen Vollständigkeit und Konsistenz, und ein Mensch gibt den Report frei, bevor er versendet wird. Die Ausführungsschicht basiert dort auf Agent Skills und nicht auf einem MCP-Server. Die Architekturprinzipien sind aber genau die, die einen guten MCP-Server ausmachen:

• Rechnen im Code, nicht im Modell. Alle Berechnungen laufen in deterministischen Python-Werkzeugen. Das Sprachmodell entscheidet, welches Werkzeug es aufruft, die Zahlen selbst kommen aus geprüftem Code. Für MCP heißt das: Ein Tool liefert fertige Kennzahlen zurück, statt der KI Rohdaten zum Kopfrechnen zu geben.
• Harte Prüfungen vor jeder Ausgabe. Fällt eine Summen- oder Konsistenzprüfung durch, geht nichts raus. Dieselbe Logik gehört in schreibende MCP-Tools.
• Freigabe durch einen Menschen. Die KI bereitet vor, der Mensch entscheidet.

Ein naheliegender nächster Schritt in solchen Projekten ist der Chat direkt auf den Daten: Ad-hoc-Fragen wie „Wie hat sich Kennzahl X im Quartal entwickelt?” ohne neuen Report. Genau dafür ist ein schmaler, rein lesender MCP-Server das passende Werkzeug, weil er bestehende, geprüfte Berechnungen wiederverwendet, statt neue zu erfinden.

Ein zweites Muster stammt aus Logify, unserer KI-Logfile-Analyse für den IT-Support von BCT: Modellausgaben werden dort in ein festes, validiertes Format überführt, bevor sie weiterverarbeitet werden. Dieselbe Disziplin empfehlen wir für die Antworten jedes MCP-Tools.

Was kostet es, einen MCP-Server zu erstellen?

Die Kosten hängen weniger vom Protokoll ab als von der Anbindung dahinter. Die folgenden Spannen sind Schätzungen aus unserer Projekterfahrung, Stand Oktober 2026:

• Prototyp mit stdio, zwei bis fünf Lese-Tools: ein bis drei Personentage, wenn eine dokumentierte API vorhanden ist.
• Zentraler Lese-Server mit OAuth, Protokollierung und Hosting: etwa zwei bis vier Wochen inklusive Tests mit dem Fachbereich.
• Server mit schreibenden Tools, Freigabeprozess und Anbindung eines Altsystems ohne gute API: deutlich mehr, weil der Großteil des Aufwands in die Datenanbindung fließt.

Die laufenden Kosten für den Server selbst sind meist gering, weil er nur Aufrufe weiterreicht. Die größeren laufenden Posten sind die Modellkosten der KI-Anwendung und die Pflege, wenn sich das angebundene System ändert. Rechnen Sie außerdem Zeit für die Abstimmung mit IT-Sicherheit und Datenschutz ein, vor allem wenn personenbezogene Daten im Spiel sind.

Welche Fehler sehen wir beim Bau von MCP-Servern am häufigsten?

Die ganze API als Tools spiegeln. Ein Werkzeug pro Endpunkt klingt gründlich, überfordert aber das Modell. Besser sind wenige Tools, die fachliche Fragen beantworten.

Admin-Rechte „für den Anfang”. Was im Prototyp bequem ist, bleibt erfahrungsgemäß im Betrieb. Starten Sie mit minimalen Rechten, erweitern ist einfacher als zurückdrehen.

Rohdaten statt Antworten. Wenn ein Tool tausend Zeilen zurückgibt, sprengt das das Kontextfenster und lädt zu Fehlern ein. Filtern und aggregieren Sie im Server.

Kein Test mit echten Fragen. Ein Server, der im Inspector funktioniert, ist noch lange kein Server, mit dem die KI richtig arbeitet. Erst der Test mit realen Anfragen zeigt, ob Tool-Zuschnitt und Beschreibungen tragen.

Datenbasis ignorieren. MCP liefert den Zugang, nicht die Qualität. Sind die Daten unvollständig oder widersprüchlich, antwortet auch die beste KI falsch. Ob Ihre Systeme dafür bereit sind, klärt ein KI-Readiness-Check.

Fazit: Klein anfangen, sauber absichern

Einen MCP-Server zu erstellen ist technisch kein großes Projekt. Die eigentliche Arbeit liegt im Zuschnitt der Werkzeuge, in sauberen Rechten und in Tests mit echten Fragen. Wer mit einem schmalen, rein lesenden Server für einen konkreten Anwendungsfall startet, hat in wenigen Wochen eine Anbindung, die im Alltag trägt, und eine Vorlage für alle weiteren Systeme.

Genau das setzen wir für Unternehmen um: von der Auswahl des richtigen Anwendungsfalls über den Bau des Servers bis zum Betrieb in Ihrer Infrastruktur. Einen Überblick über unsere Leistungen finden Sie unter Services.

Häufige Fragen

Wie erstelle ich einen eigenen MCP-Server?

Sie wählen ein offizielles MCP-SDK, etwa für Python oder TypeScript, definieren eine kleine Zahl von Tools mit klaren Namen und Beschreibungen und starten den Server über stdio (lokal) oder Streamable HTTP (zentral). Danach testen Sie ihn mit dem MCP Inspector und mit echten Fragen aus dem Fachbereich, bevor er in den Betrieb geht.

Welche Programmiersprache eignet sich für einen MCP-Server?

Es gibt offizielle SDKs unter anderem für Python, TypeScript, C#, Java und Go. Am besten nehmen Sie die Sprache, in der Ihr Team und das anzubindende System ohnehin arbeiten. Für schnelle Prototypen ist Python mit FastMCP ein guter Einstieg.

Was ist der Unterschied zwischen stdio und Streamable HTTP?

Bei stdio läuft der Server als lokaler Prozess auf dem Rechner der Nutzerin oder des Nutzers, das eignet sich für Prototypen und Einzelplätze. Bei Streamable HTTP läuft der Server zentral als Webdienst. Das ist für Unternehmen meist die bessere Wahl, weil sich Anmeldung, Rechte und Protokollierung zentral steuern lassen.

Wie sichere ich einen MCP-Server ab?

Mit minimalen Rechten, möglichst nur lesend, mit Anmeldung über OAuth bei zentralen Servern, mit Prüfung aller Eingaben im Server, mit menschlicher Freigabe bei kritischen Aktionen und mit Protokollierung jedes Aufrufs. Rechnen Sie außerdem damit, dass Inhalte aus Dokumenten oder E-Mails versteckte Anweisungen enthalten können.

Was kostet ein MCP-Server?

Nach unserer Schätzung braucht ein Prototyp mit wenigen Lese-Tools ein bis drei Personentage, ein zentraler, abgesicherter Server etwa zwei bis vier Wochen. Mehr Aufwand entsteht, wenn schreibende Tools, Freigabeprozesse oder Altsysteme ohne gute Schnittstelle dazukommen. Die laufenden Kosten des Servers selbst sind meist gering.

Brauche ich immer einen eigenen MCP-Server?

Nein. Für viele Standard-Tools gibt es fertige Server, oft direkt vom Hersteller, und n8n kann bestehende Workflows als MCP-Werkzeuge bereitstellen. Ein eigener Server lohnt sich bei eigenen Systemen, wenn Sie nur einen engen Ausschnitt freigeben wollen oder eigene Geschäftslogik zwischen KI und Daten brauchen.

Sie überlegen, welche Ihrer Systeme sich sinnvoll und sicher per MCP an KI anbinden lassen? Lassen Sie uns in einem unverbindlichen Erstgespräch gemeinsam draufschauen.