Eigener MCP-Server in TypeScript: Firmendaten sicher an KI anbinden

KI-generiert, menschlich reviewt

17.7.2026 · ai-integrations

Ihre Entwickler:innen nutzen längst KI-Assistenten. Die offene Frage ist, wie diese Assistenten an interne Systeme kommen — an die Dokumentenablage, das Ticket-System, die Wissensdatenbank. Der bequeme Weg ist Copy-Paste: Inhalte aus dem Backend in den Chat kippen. Der kontrollierte Weg ist ein Dienst, der genau definierte Fähigkeiten anbietet — mit Authentifizierung, Protokollierung und ohne Direktzugriff aufs Backend. Genau diese Rolle übernimmt ein Server, der das Model Context Protocol (MCP) spricht.

Dieser Artikel zeigt konzeptionell, wie Sie einen MCP-Server erstellen, der ein internes System als Werkzeuge für Claude & Co. bereitstellt — self-hosted und auditierbar. Als durchgehendes Beispiel dient eine Dokumentenablage, aus der ein Assistent ausschließlich lesen darf.

Warum ein eigener MCP-Server statt Direktzugriff

MCP ist ein offener, von Anthropic initiierter Standard mit breiter Client-Unterstützung. Ein MCP-Server stellt einem KI-Assistenten drei Arten von Fähigkeiten bereit: Tools (Aktionen, die der Assistent aufrufen kann), Resources (lesbare Datenquellen) und Prompts (vordefinierte Abläufe). Der Assistent entdeckt diese Fähigkeiten zur Laufzeit selbst — Sie müssen kein Client-spezifisches Plugin pflegen.

Der eigentliche Gewinn gegenüber Direktzugriff ist die Kontrollschicht dazwischen. Statt dem Modell einen Datenbank-Zugang oder einen API-Schlüssel in die Hand zu geben, definieren Sie einen klaren Berechtigungsschnitt: Der Server exponiert nur die Tools, die Sie explizit freigeben, prüft jeden Aufruf und schreibt ihn ins Log. Was der Assistent nicht als Tool sieht, existiert für ihn nicht.

Dieselbe Definition wirkt für jeden Client gleich. Ob ein Desktop-Assistent, eine interne Chat-Oberfläche oder ein automatisierter Agent zugreift — alle sehen dieselben Tools, dieselben Grenzen und dieselbe Audit-Spur. Sie pflegen die Berechtigungen an einer Stelle, nicht pro Integration.

Einen MCP-Server in TypeScript erstellen

Für TypeScript gibt es das offizielle SDK. Ein minimales Projekt braucht zwei Abhängigkeiten:

npm install @modelcontextprotocol/sdk zod

Das SDK liefert eine High-Level-Klasse McpServer, die den Protokoll-Handshake, die Fähigkeits-Aushandlung und die Nachrichten-Serialisierung übernimmt. Sie beschreiben nur noch Ihre Tools:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "dokumentenablage",
  version: "1.0.0",
});

name und version melden sich beim Client an — mehr Konfiguration ist für den Start nicht nötig.

Ein Read-only-Tool definieren

Der Berechtigungsschnitt entsteht bei der Tool-Definition. Das folgende Tool durchsucht die Dokumentenablage und gibt Treffer zurück — lesend, ohne Schreibpfad:

server.registerTool(
  "suche_dokumente",
  {
    title: "Dokumente suchen",
    description:
      "Durchsucht die interne Dokumentenablage und liefert passende Treffer. Nur lesender Zugriff.",
    inputSchema: {
      query: z.string().describe("Suchbegriff"),
      limit: z.number().int().min(1).max(20).default(5),
    },
  },
  async ({ query, limit }) => {
    const treffer = await ablage.suche(query, limit); // Ihre bestehende Suchfunktion
    return {
      content: [{ type: "text", text: JSON.stringify(treffer, null, 2) }],
    };
  }
);

Zwei Dinge sind hier entscheidend. Erstens beschreibt das inputSchema per Zod, welche Parameter erlaubt sind — das SDK validiert jeden Aufruf, bevor Ihr Code ihn sieht. Zweitens ruft der Handler Ihre bestehende Suchfunktion auf. Der MCP-Server ersetzt Ihre Domänenlogik nicht, er verpackt sie in ein klar umrissenes Interface. Ein Schreib-Tool wie lösche_dokument lassen Sie hier bewusst weg oder legen es hinter zusätzliche Prüfungen — der lesende Standardfall bleibt so eng geschnitten wie möglich.

Server starten: stdio oder HTTP

MCP kennt zwei gängige Transportwege.

stdio eignet sich, wenn der Server als lokaler Unterprozess des Clients läuft — etwa in einer Desktop-App auf dem Rechner der Nutzer:in:

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const transport = new StdioServerTransport();
await server.connect(transport);

Streamable HTTP brauchen Sie, sobald der Server als eigenständiger Dienst auf Ihrer Infrastruktur läuft und von mehreren Clients über das Netz erreichbar sein soll. Das SDK bringt dafür StreamableHTTPServerTransport mit, den Sie in einen HTTP-Handler (etwa Express) einhängen. Für einen internen Firmen-Server ist das der Regelfall.

Absichern: Token und Reverse Proxy

Ein HTTP-erreichbarer MCP-Server ist ein Netzwerkdienst und gehört entsprechend abgesichert. Zwei Ebenen genügen für den Anfang:

Authentifizierung am Rand: Betreiben Sie den Server hinter einem Reverse Proxy (Traefik, Caddy, nginx), der TLS terminiert und einen Bearer-Token oder mTLS erzwingt. So erreicht kein unauthentifizierter Request überhaupt den Server.
Least Privilege im Server: Der Server nutzt einen technischen Account mit exakt den Rechten, die seine Tools brauchen — kein Admin-Zugang „für alle Fälle”.

Für höhere Anforderungen sieht MCP OAuth 2.1 vor; in Verbindung mit einem eigenen Identity-Provider wie Keycloak lassen sich Tools pro Rolle freigeben. Sinnvoll ist zudem ein Rate-Limit pro Client, damit ein fehlgeleiteter Agent Ihr System nicht mit Aufrufen flutet. Wichtig bleibt in jedem Fall: jeden Tool-Aufruf protokollieren — mit Zeitpunkt, aufrufendem Client und Parametern. Das Log ist Ihre Audit-Spur und im Zweifel der Beleg, wer wann was abgefragt hat.

Deployment auf eigener Infrastruktur

Ein MCP-Server ist ein gewöhnlicher Node-Dienst und deployt sich wie jeder andere. Auf einer self-hosted Plattform wie Coolify genügen ein Dockerfile (oder ein Nixpacks-Build), eine Umgebungsvariable für den Token und eine Domain hinter dem integrierten Reverse Proxy mit automatischem TLS. Damit bleibt der gesamte Datenpfad — Dokumente, Suchindex, Logs — auf Ihrer Infrastruktur; nichts wandert in eine Dritt-Cloud. Für eine Verarbeitung nach DSGVO ist genau das der entscheidende Punkt: Der KI-Assistent sieht nur die Antworten Ihrer Tools, nie den Rohbestand, und Sie können jeden Zugriff belegen.

Wann eine klassische API-Integration reicht

Ein MCP-Server ist nicht immer die richtige Antwort. Er lohnt sich, wenn mehrere, wechselnde KI-Clients dieselben Fähigkeiten entdecken und nutzen sollen — mit einheitlicher Auth und Audit-Spur. Genau dann zahlt sich die Selbstbeschreibung des Protokolls aus.

Geht es dagegen um eine einzelne, feste Integration — ein Dienst ruft eine bekannte API in einem festen Ablauf auf —, ist ein direkter API-Call meist einfacher, und der MCP-Server wäre Overhead. Und wenn Ihr Ziel ist, einen großen Freitext-Wissensbestand durchsuchbar zu machen, ist oft ein RAG-System der passendere Hebel als ein Werkzeug-Server — den Rahmen dafür beschreibt RAG-Systeme für Unternehmenswissen. Ob ein MCP-Server zu Ihrem Fall passt, lässt sich meist in wenigen Sätzen klären; unsere FAQ „Was ist ein MCP-Server — und brauchen wir einen?” fasst die Faustregel zusammen.

Fazit

Ein MCP-Server öffnet interne Systeme kontrolliert für KI-Assistenten — statt Copy-Paste oder Direktzugriff.
Mit dem offiziellen TypeScript-SDK ist die Grundstruktur klein: McpServer anlegen, Tools mit Zod-Schema definieren, Transport verbinden.
Der Berechtigungsschnitt entsteht in der Tool-Definition: nur exponieren, was freigegeben ist; lesend vor schreibend.
Absicherung gehört an den Rand (Reverse Proxy, Token oder OAuth) und ins Log (Audit-Spur).
Self-hosted deployt — etwa auf Coolify — bleibt der gesamte Datenpfad DSGVO-konform auf Ihrer Infrastruktur.
Kein Selbstzweck: Für einzelne feste Integrationen reicht eine klassische API; für Freitext-Wissen ist RAG oft besser.

Wenn Sie einen MCP-Server von der Tool-Definition bis zum Betrieb auf Ihrer Infrastruktur planen, begleiten wir Sie dabei — vom Berechtigungsschnitt bis zum Deployment: MCP-Server für KI-Integrationen.