MCP-Server im Unternehmen: Eigene Tools für die KI-Integration

Ein eigener lokaler MCP-Server für interne Bibliotheken, Coding-Standards und Team-Skills ist in vielen Szenarien sehr sinnvoll. Statt jedem KI-Assistenten einzeln beizubringen, wie das Unternehmen arbeitet, bündelt ein MCP-Server dieses Wissen an einer Stelle – und jeder Client, ob Claude, Cursor oder ein eigener Agent, greift darauf zu.

Was MCP ist, wie das Protokoll funktioniert und wie man einen ersten Server einrichtet, haben wir in Teil 1 dieser Serie ausführlich erklärt. Dieser Artikel baut darauf auf und konzentriert sich auf die Frage: Warum sollte ein Unternehmen einen eigenen MCP-Server bauen – und wie sieht das in der Praxis aus?

Warum ein eigener MCP-Server sinnvoll ist

Die öffentlichen MCP-Server-Verzeichnisse listen über 500 Server für gängige Dienste: GitHub, Slack, PostgreSQL, Notion, Salesforce. Für Standardintegrationen reicht das. Aber die interessanteren Szenarien entstehen dort, wo kein öffentlicher Server existiert – im eigenen Unternehmen.

Implizites Wissen als Engpass

Jedes Unternehmen hat Wissen, das nirgends steht – oder nur in Dokumenten, die niemand findet. Welche Architekturentscheidungen wurden getroffen und warum? Wie funktioniert der Freigabeprozess für einen neuen Microservice? Welche Namenskonventionen gelten für API-Endpoints? Welche Compliance-Regeln müssen bei Kundendaten beachtet werden?

Dieses implizite Wissen lebt in den Köpfen einzelner Mitarbeiter, in verstreuten Confluence-Seiten, in Slack-Threads. Ein neuer Mitarbeiter braucht Monate, um es zusammenzutragen. Ein KI-Assistent ohne Zugang dazu gibt generische Antworten, die an der Realität des Unternehmens vorbeigehen.

Ein MCP-Server macht dieses Wissen maschinenlesbar und abrufbar – für jeden KI-Client, ohne dass jemand Kontext kopieren muss.

Der entscheidende Unterschied zu Ansätzen wie Microsoft 365 Copilot: Ein Copilot im Tenant hat Vollzugriff auf alles, was der Nutzer sehen darf – und muss aus diesem riesigen Kontext selbst gewichten, was relevant ist. Ein MCP-Server dreht das Prinzip um. Welche Informationen bereitgestellt werden, ist bewusst kuratiert. Irrelevantes wird gar nicht erst exponiert, sensible Daten können gezielt ausgeschlossen werden, und die Gewichtung passiert nicht im Modell, sondern in der Architektur. Das Ergebnis: präzisere Antworten, weniger Rauschen und eine Kontrolle darüber, was die KI überhaupt sehen kann – statt darauf zu vertrauen, dass sie aus dem Vollzugriff die richtige Auswahl trifft.

Konkrete Szenarien, die sofort Wert liefern

Interne Coding-Standards und Bibliotheken: Ein MCP-Server kann Team-Konventionen als aufrufbare Tools bereitstellen. Statt Coding-Guidelines in einem Wiki zu pflegen, die niemand liest, werden sie zu Funktionen: „Erstelle eine neue Komponente nach unserem Standard”, „Validiere diesen Code gegen unsere Architekturregeln”, „Generiere einen API-Endpoint nach unserem Template”. Bei einem 15-köpfigen Entwicklerteam spart das erfahrungsgemäß 20 bis 40 Minuten pro Entwickler und Woche – weil niemand mehr nachfragen muss, wie der Standard aussieht.

Onboarding beschleunigen: Ein neuer Entwickler stellt dem KI-Assistenten die Frage „Wie deploye ich einen neuen Service?” – und bekommt nicht die generische Kubernetes-Antwort, sondern den tatsächlichen internen Prozess: welches Helm-Chart, welche Umgebungsvariablen, welcher Slack-Channel für die Freigabe. Das verkürzt die Einarbeitungszeit von Wochen auf Tage.

Unternehmens-Wissensbasis: Interne Dokumentation, Prozessbeschreibungen, Entscheidungsprotokolle – als Resources über MCP zugänglich, ohne dass sensible Daten an externe Dienste fließen. Der Server läuft lokal oder im internen Netz. Der entscheidende Unterschied zu einer RAG-Pipeline: MCP-Resources haben stabile URIs und werden vom Server aktiv verwaltet. Es ist keine einmalige Indexierung, sondern eine lebendige Schnittstelle.

Prozessautomatisierung: Ticket-Erstellung im internen Tracker, Deployment-Status abfragen, Release-Notes generieren, Datenbank-Migrationen anstoßen – alles über standardisierte Tool-Aufrufe statt über maßgeschneiderte Skripte. Ein Entwickler sagt „Erstelle ein Ticket für den Login-Bug mit Prio 2 und weise es dem Backend-Team zu” – und der MCP-Server erstellt es im richtigen Projekt, mit den richtigen Labels, im richtigen Format.

Compliance als eingebaute Leitplanke: In regulierten Branchen kann der MCP-Server vor jeder Aktion prüfen, ob sie den Richtlinien entspricht. Bevor Kundendaten abgefragt werden: Hat der Nutzer die Berechtigung? Ist die Verarbeitung DSGVO-konform? Das ist kein nachgelagerter Audit, sondern eine architekturbedingte Kontrolle.

Modell-Agnostik: Der gleiche Server funktioniert mit Claude, GPT, Gemini oder einem lokalen Modell. Wenn das Team den KI-Anbieter wechselt, bleibt die gesamte Tool-Integration bestehen. Das ist ein unterschätzter Vorteil: Die Investition in MCP-Tools ist nicht an einen Anbieter gebunden.

Wer MCP bereits nutzt

Die Adoption hat sich 2025 beschleunigt. Anthropic hat MCP an die Agentic AI Foundation (AAIF) unter der Linux Foundation übergeben – mitgegründet von Anthropic, Block und OpenAI. AWS, Google, Microsoft, Cloudflare und Bloomberg sind als unterstützende Mitglieder beigetreten.

Auf der Client-Seite unterstützen Claude Desktop, Claude Code, Cursor, Zed, VS Code (über Continue und Cline), Windsurf und seit März 2025 auch OpenAI über den Agents SDK und die Responses API. Google Gemini CLI hat MCP-Support nachgezogen. Mistral hat MCP-Unterstützung in seine Agents-Plattform integriert – Mistral-Agenten können sich direkt mit MCP-Servern verbinden, was das europäische Ökosystem stärkt und die Modell-Agnostik von MCP unterstreicht. Das offizielle TypeScript-SDK (@modelcontextprotocol/sdk) verzeichnet über 80 Millionen Downloads pro Monat auf npm.

Auf der Server-Seite bieten Salesforce, HubSpot, Notion, GitHub, Slack und viele andere offizielle MCP-Server an. Aber auch abseits der großen Namen passiert viel:

• Cloudflare hat MCP-Server-Hosting direkt in ihre Workers-Plattform integriert. Ein npx create-cloudflare@latest -- --type mcp-server reicht für ein Deployment. Damit wird der Schritt vom lokalen Prototyp zum gehosteten Service trivial.
• Stripe stellt einen offiziellen MCP-Server bereit, über den KI-Assistenten Zahlungen, Abonnements und Rechnungen verwalten können – mit vollständiger API-Abdeckung und Transaktionssicherheit.
• Sentry bietet einen MCP-Server für Error-Monitoring: Fehler suchen, Stack-Traces analysieren, Issues zuweisen – direkt aus dem KI-Assistenten heraus, ohne zwischen Browser-Tabs zu wechseln.
• Linear ermöglicht über MCP die komplette Projektverwaltung: Issues erstellen, Sprints planen, Statusberichte generieren. Entwickler verlassen ihren Editor nicht mehr für Projektmanagement.
• Neon (Serverless Postgres) bietet einen MCP-Server für Datenbankmanagement: Branches erstellen, Schemas migrieren, Queries ausführen – besonders interessant für Teams, die ihre Datenbankoperationen in KI-gestützte Workflows einbinden wollen.

Das zeigt, dass MCP nicht mehr experimentell ist – es ist Infrastruktur.

Architektur: Wie MCP kommuniziert

MCP unterstützt zwei Transport-Layer, je nach Einsatzszenario.

stdio – lokale Server

Der Server läuft als Subprocess des Host-Programms. Kommunikation über stdin/stdout, Latenz im Mikrosekundenbereich, kein Netzwerk-Overhead. Ein Client pro Server-Prozess. Das ist der Standard für lokale Entwicklertools.

Streamable HTTP – remote Server

Seit März 2025 der Standard für netzwerkbasierte MCP-Server. Ein einzelner HTTP-Endpoint, der sowohl POST-Requests als auch Server-Sent Events (SSE) unterstützt. Session-Management über einen Mcp-Session-Id Header.

Das ältere SSE-Modell mit zwei separaten Endpoints ist deprecated – es verursachte Probleme mit Load Balancern und persistenten Verbindungen.

Praktisch: MCP-Server mit Node.js

Das offizielle TypeScript-SDK (@modelcontextprotocol/sdk) ist der schnellste Weg zu einem funktionierenden Server. Zod ist eine Peer-Dependency und übernimmt die Schema-Validierung.

Setup

mkdir mein-mcp-server && cd mein-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod

Ein Server mit internen Tools

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

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

// Tool: Komponente nach internem Standard erstellen
server.registerTool(
  "create_component",
  {
    description: "Erstellt eine neue UI-Komponente nach Team-Konventionen",
    inputSchema: {
      name: z.string().describe("Komponentenname in PascalCase"),
      type: z.enum(["page", "layout", "ui", "feature"])
        .describe("Komponententyp bestimmt Verzeichnis und Boilerplate"),
    },
  },
  async ({ name, type }) => {
    const template = generateTemplate(name, type);
    return {
      content: [{ type: "text", text: template }],
    };
  }
);

// Tool: Code gegen Architekturregeln prüfen
server.registerTool(
  "validate_architecture",
  {
    description: "Prüft ob ein Import-Pfad den Architekturregeln entspricht",
    inputSchema: {
      sourceModule: z.string().describe("Modul, das importiert"),
      targetModule: z.string().describe("Modul, das importiert wird"),
    },
  },
  async ({ sourceModule, targetModule }) => {
    const allowed = checkDependencyRules(sourceModule, targetModule);
    return {
      content: [{
        type: "text",
        text: allowed
          ? `Import von ${targetModule} in ${sourceModule} ist erlaubt.`
          : `Verstoß: ${sourceModule} darf nicht von ${targetModule} abhängen.`
      }],
    };
  }
);

// Server starten (stdio)
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch(console.error);

Die generateTemplate- und checkDependencyRules-Funktionen sind hier Platzhalter – in der Praxis lesen sie aus Konfigurationsdateien, Template-Verzeichnissen oder einer internen API.

Einbindung in Claude Code

In der MCP-Konfiguration (.claude/settings.json oder über claude mcp add):

{
  "mcpServers": {
    "internal-tools": {
      "command": "node",
      "args": ["./mein-mcp-server/index.js"]
    }
  }
}

Ab diesem Moment kann Claude Code die registrierten Tools aufrufen – create_component und validate_architecture erscheinen als verfügbare Funktionen.

Praktisch: MCP-Server mit Rust

Für performance-kritische Server oder Teams mit Rust-Erfahrung bietet das offizielle rmcp-Crate eine vollständige Implementierung mit Makros für ergonomische Tool-Definition.

Setup

[dependencies]
rmcp = { version = "0.16", features = ["server"] }
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
schemars = "1"

Server mit Tool-Makros

use rmcp::{
    ErrorData as McpError, ServerHandler,
    handler::server::router::tool::ToolRouter,
    handler::server::wrapper::Parameters,
    model::*,
    tool, tool_handler, tool_router,
    schemars, ServiceExt,
};

#[derive(Debug, serde::Deserialize, schemars::JsonSchema)]
pub struct ComponentRequest {
    /// Komponentenname in PascalCase
    pub name: String,
    /// Typ: page, layout, ui oder feature
    pub component_type: String,
}

#[derive(Debug, serde::Deserialize, schemars::JsonSchema)]
pub struct ValidationRequest {
    pub source_module: String,
    pub target_module: String,
}

#[derive(Clone)]
pub struct InternalTools {
    tool_router: ToolRouter<InternalTools>,
}

#[tool_router]
impl InternalTools {
    pub fn new() -> Self {
        Self {
            tool_router: Self::tool_router(),
        }
    }

    #[tool(description = "Erstellt eine UI-Komponente nach Team-Konventionen")]
    fn create_component(
        &self,
        Parameters(req): Parameters<ComponentRequest>,
    ) -> Result<CallToolResult, McpError> {
        let template = format!(
            "// {}.tsx\nexport function {}() {{\n  return <div>TODO</div>;\n}}",
            req.name, req.name
        );
        Ok(CallToolResult::success(vec![Content::text(template)]))
    }

    #[tool(description = "Prüft Import gegen Architekturregeln")]
    fn validate_architecture(
        &self,
        Parameters(req): Parameters<ValidationRequest>,
    ) -> Result<CallToolResult, McpError> {
        let msg = format!(
            "Import von {} in {} wird geprüft.",
            req.target_module, req.source_module
        );
        Ok(CallToolResult::success(vec![Content::text(msg)]))
    }
}

#[tool_handler]
impl ServerHandler for InternalTools {
    fn get_info(&self) -> ServerInfo {
        ServerInfo {
            capabilities: ServerCapabilities::builder()
                .enable_tools()
                .build(),
            ..Default::default()
        }
    }
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let service = InternalTools::new();
    let server = service.serve((tokio::io::stdin(), tokio::io::stdout())).await?;
    server.waiting().await?;
    Ok(())
}

Der Rust-Server startet in Millisekunden, verbraucht minimal Speicher und profitiert von Rusts Typsicherheit bei der Schema-Validierung über schemars.

Jenseits der Entwicklung: MCP für Fachabteilungen

MCP ist nicht nur ein Entwicklerthema. Die stärksten Anwendungsfälle entstehen oft dort, wo Fachwissen aus verschiedenen Abteilungen maschinenlesbar gemacht wird – ohne dass die Nutzer selbst programmieren müssen.

Prozessautomatisierung ohne Code

Statt komplexe Automatisierungen in Zapier oder Power Automate zusammenzuklicken, können wiederkehrende Geschäftsprozesse als MCP-Tools abgebildet werden:

• HR: Urlaubsanträge prüfen und weiterleiten, Onboarding-Checklisten generieren, Gehaltsabrechnungsdaten abfragen
• Vertrieb: CRM-Einträge anlegen, Angebote nach Vorlage erstellen, Pipeline-Reports generieren
• Projektmanagement: Statusberichte aus Jira/Linear zusammenfassen, Zeiterfassungen auswerten, Ressourcenkonflikte identifizieren
• Einkauf: Lieferantenanfragen standardisiert versenden, Preisvergleiche aus internen Datenbanken ziehen, Bestellfreigaben anstoßen

Das Besondere: Der KI-Assistent kann mehrere dieser Tools in einer Konversation kombinieren. „Erstelle einen Statusbericht für Projekt X, prüfe offene Blocker und schick eine Zusammenfassung an den Lenkungsausschuss” wird zu einer Kette von Tool-Aufrufen – ohne dass jemand ein Script schreiben muss.

Compliance und Governance

In regulierten Branchen – Finanzdienstleistung, Gesundheitswesen, öffentliche Verwaltung – ist die Frage nicht ob KI eingesetzt wird, sondern wie sie kontrolliert eingesetzt wird. MCP-Server bieten hier eine natürliche Governance-Schicht:

Datenschutz-Checks: Ein Tool, das vor jeder Datenverarbeitung prüft, ob die angeforderten Daten dem Berechtigungskonzept entsprechen. Das Modell fragt „Darf Nutzer X auf Kundendaten aus Region Y zugreifen?” – und der MCP-Server gibt eine verbindliche Antwort basierend auf den tatsächlichen Policies.

Audit-Trail: Jeder Tool-Aufruf über MCP ist protokollierbar. Wer hat wann welche Daten abgefragt, welche Aktionen ausgelöst? Das ist kein nachträgliches Logging, sondern eine architekturbedingte Eigenschaft – der MCP-Server ist der einzige Zugang, und er kann jeden Request dokumentieren.

Regulatorische Prüfungen: Vertragsklauseln gegen aktuelle Vorschriften prüfen, DSGVO-Konformität von Datenverarbeitungen bewerten, Exportkontrollvorschriften auf Transaktionen anwenden. Diese Prüfungen sind regelbasiert und eignen sich als MCP-Tools, weil die Regeln zentral gepflegt und aktualisiert werden können.

Freigabe-Workflows: Statt dass ein KI-Assistent unkontrolliert Aktionen ausführt, kann der MCP-Server mehrstufige Freigaben erzwingen. Eine Bestellung über einem bestimmten Betrag erfordert eine zusätzliche Genehmigung – das Tool gibt den Auftrag erst frei, wenn die Freigabe vorliegt.

Kostenvergleich: Lokales npm-Paket vs. gehosteter HTTP-Dienst

Eine der ersten Architekturentscheidungen: Soll der MCP-Server lokal als stdio-Prozess laufen oder als Remote-Service über HTTP bereitgestellt werden? Neben technischen Aspekten unterscheiden sich die beiden Ansätze erheblich in den laufenden Kosten.

Lokaler MCP-Server (stdio, npm-Paket)

Der Server wird als npm-Paket im Team verteilt und läuft als Subprocess des Editors. Jeder Entwickler startet ihn lokal.

Kosten:

• Infrastruktur: 0 Euro. Läuft auf dem Rechner des Entwicklers.
• Verteilung: npm install oder npx – kein Deployment nötig.
• Updates: Neue Version veröffentlichen, Entwickler aktualisieren lokal.
• Monitoring: Keins. Log-Output geht an den Client.

Einschränkungen: Ein Client pro Server-Prozess, keine zentrale Nutzerverwaltung, keine teamweiten Logs.

Remote MCP-Server (Streamable HTTP)

Der Server läuft als Dienst in der Cloud. Alle Clients verbinden sich über HTTP.

Cloudflare Workers:

• Free Tier: 100.000 Requests pro Tag, 10 ms CPU pro Request. In der Praxis problematisch: Aus eigener Erfahrung hat ein einzelner MCP-Server das Free-Tier-Limit an einem normalen Arbeitstag erreicht – ohne intensive Nutzung. Die Vermutung: Solange ein MCP-Client wie Claude aktiv läuft, erzeugt die SSE-Verbindung kontinuierliches Polling, das Requests generiert – auch ohne explizite Tool-Aufrufe. Ob das ein grundsätzliches Problem des Streamable-HTTP-Transports auf Workers ist oder spezifisch für bestimmte Client-Konfigurationen, ist noch nicht abschließend geklärt.
• Workers Paid (5 USD/Monat): 10 Millionen Requests pro Monat inklusive, danach 0,30 USD pro Million. Ob das für MCP-Workloads mit dem beschriebenen Polling-Verhalten reicht, hängt von der Anzahl gleichzeitig aktiver Clients ab. Die tatsächlichen Kosten sind schwer vorherzusagen.
• Zusatzkosten: KV Storage (0,50 USD pro Million Reads), Durable Objects (ab 0,15 USD pro Million Requests) falls Session-State oder Caching benötigt wird.
• Vorteil: Kein Server-Management, globale Edge-Verteilung, kalte Starts unter 5 ms.
• Risiko: Das Request-basierte Kostenmodell passt schlecht zu MCP-Workloads mit langlebigen Verbindungen. Für Prototypen und kleine Teams vertretbar – für Enterprise-Einsatz mit vielen gleichzeitigen Nutzern schwer kalkulierbar.

Fly.io (Container-basiert):

• Shared CPU (1x): Ab 1,94 USD/Monat für eine always-on Maschine (256 MB RAM).
• Dedicated CPU: Ab 29 USD/Monat für vorhersagbare Latenz.
• Outbound Traffic: 100 GB/Monat frei, danach 0,02 USD/GB.
• Vorteil: Volle Node.js/Rust-Runtime, keine Execution-Time-Limits, WebSocket-Support für langlebige Verbindungen.

Eigene Infrastruktur (Kubernetes, VM):

• Minimaler Footprint: Ein MCP-Server braucht wenig Ressourcen – 128 MB RAM, eine halbe CPU reicht für Hunderte gleichzeitige Verbindungen.
• Kosten: Abhängig von vorhandener Infrastruktur, aber typisch 10 bis 50 EUR/Monat für eine dedizierte VM.
• Overhead: Deployment-Pipeline, Monitoring, TLS-Zertifikate, OAuth-Setup müssen selbst betrieben werden.

Entscheidungsmatrix

Kriterium	Lokal (stdio)	Cloudflare Workers	Fly.io / VM
Monatliche Kosten	0 EUR	ab 5 EUR, schwer kalkulierbar	2 bis 50 EUR (fix)
Setup-Aufwand	Gering (npm install)	Mittel (Wrangler + Auth)	Hoch (Infra + Auth + TLS)
Mehrere Nutzer	Nein	Ja	Ja
Zentrale Logs	Nein	Ja	Ja
Auth/RBAC	Erbt OS-Rechte	OAuth 2.1 erforderlich	OAuth 2.1 erforderlich
Latenz	Mikrosekunden	5 bis 30 ms (Edge)	10 bis 100 ms
Offline-fähig	Ja	Nein	Nein

Empfehlung: Start mit einem lokalen npm-Paket – kein Risiko, keine Kosten, sofortiger Nutzen. Sobald mehr als ein Team denselben Server braucht, lohnt sich ein Container mit fixen Monatskosten (Fly.io, eigene VM oder vorhandenes Kubernetes). Das Kostenmodell ist vorhersagbar, und MCP-Workloads mit langlebigen SSE-Verbindungen passen besser zu einer Flat-Rate als zu Request-basierten Abrechnungen. Cloudflare Workers eignen sich gut für Prototypen und Proof-of-Concepts, aber das unklare Polling-Verhalten macht die Kostenkalkulation im Enterprise-Einsatz schwierig. Wer DSGVO-relevant arbeitet, sollte zudem auf einen europäischen Hoster setzen – bei Container-basierten Lösungen ist das kein Problem: Hetzner, Scaleway, OVH oder ein eigenes Rechenzentrum bieten volle Kontrolle über den Datenstandort.

Wie nutzt man MCP-Server im Alltag?

Der Server steht – aber wie greifen Nutzer darauf zu? Das hängt davon ab, ob Entwickler oder Fachabteilungen die Zielgruppe sind.

Für Entwickler: IDE und CLI

Die meisten Entwickler nutzen MCP über ihren Editor oder die Kommandozeile. Keine separate App nötig – die Tools erscheinen direkt im KI-Assistenten.

Claude Code (CLI): Ein claude mcp add internal-tools -- node ./mein-server/index.js reicht. Ab dem nächsten Start stehen die Tools zur Verfügung. Die Konfiguration kann auf drei Ebenen liegen: in ~/.claude/settings.json (gilt für alle Projekte des Nutzers), in .claude/settings.json im Repository (gilt für alle Teammitglieder, die das Repo klonen) oder projektspezifisch über .claude/settings.local.json. Für persönliche MCP-Server wie einen eigenen Wissensserver ist die Benutzer-Ebene (~/.claude/) oft der pragmatischste Ort – einmal einrichten, überall verfügbar.

Cursor, Zed, VS Code (Continue/Cline): MCP-Server werden über JSON-Config eingebunden. Bei Cursor in den Settings, bei Zed in settings.json, bei VS Code über die Continue- oder Cline-Extension. Das Prinzip ist identisch: Server-Befehl und Argumente angeben, fertig.

Programmatisch (Agents SDK): Für eigene Anwendungen bieten OpenAI (Agents SDK), Anthropic (Claude API) und Google (Gemini) direkte MCP-Integration. Ein Agent kann MCP-Server als Tool-Provider nutzen, ohne dass ein menschlicher Nutzer dazwischensteht.

Für Fachabteilungen: Desktop-Apps und Web-Oberflächen

Nicht jeder Nutzer arbeitet in einer IDE. Für HR, Vertrieb oder Projektmanagement braucht es niedrigschwelligere Zugänge.

Claude Desktop: Die GUI-App unterstützt MCP-Server nativ. Ein Admin richtet die Verbindung einmalig ein (JSON-Config), danach können Nutzer die Tools per Chat aufrufen – ohne zu wissen, was MCP ist. „Erstelle einen Urlaubsantrag für nächste Woche” funktioniert, weil im Hintergrund ein MCP-Tool den HR-Prozess anstößt.

Remote MCP über Streamable HTTP: Das ist der skalierbare Weg für Fachabteilungen. Ein zentral gehosteter MCP-Server (z.B. auf Cloudflare Workers) ist über eine URL erreichbar. Claude.ai, ChatGPT und andere Web-Clients können remote MCP-Server direkt ansprechen – ohne lokale Installation, ohne CLI, ohne Konfiguration auf dem Endgerät.

Eigene Chat-Oberflächen: Unternehmen, die volle Kontrolle über die Nutzererfahrung wollen, bauen eigene Frontends. Ein internes Chat-Interface, das im Backend MCP-Server als Tool-Provider nutzt. Der Nutzer sieht eine einfache Eingabemaske, die Komplexität steckt im Backend. Das ist der Ansatz für Unternehmen mit strikten Compliance-Anforderungen oder spezifischen UX-Bedürfnissen.

Die Einstiegshürde sinkt

Der wichtigste Punkt: Für die Nutzung eines MCP-Servers muss niemand programmieren können. Die Einrichtung erfordert technisches Know-how – ein Entwickler oder Admin konfiguriert den Server einmalig. Danach ist die Interaktion rein sprachbasiert. Das macht MCP zu einem der wenigen Protokolle, das sowohl für Entwickler als auch für Fachabteilungen praktischen Nutzen hat, ohne die Zielgruppe einzuschränken.

Herausforderungen im Enterprise-Einsatz

Technische Komplexität

MCP-Server zu bauen ist unkompliziert. MCP-Server zu betreiben – in einer Umgebung mit Load Balancern, Service Meshes, verschiedenen Netzwerksegmenten und heterogenen Client-Landschaften – ist eine andere Sache. Die Entscheidung zwischen stdio (lokal, einfach, ein Client) und Streamable HTTP (remote, skalierbar, komplex) ist eine Architekturentscheidung mit langfristigen Konsequenzen.

Authentifizierung und Autorisierung

Die Auth-Anforderungen unterscheiden sich je nach Deployment-Szenario erheblich:

Lokal (stdio): Kein zusätzliches Auth nötig. Der Server-Prozess erbt die Betriebssystem-Berechtigungen des Nutzers. Einfach, aber keine granulare Zugriffskontrolle möglich.

Intranet (HTTP, internes Netz): Die MCP-Spezifikation empfiehlt formal OAuth 2.1, aber in der Praxis nutzen viele Intranet-Deployments pragmatischere Ansätze: mTLS über bestehende PKI-Infrastruktur, API-Keys mit Rotation, oder SSO-Tokens vom Corporate Identity Provider (Entra ID, Okta, Keycloak). Wenn der Server nur aus dem VPN erreichbar ist und der IdP bereits existiert, ist ein vollständiges OAuth-2.1-Setup oft Overengineering.

Public (HTTP, öffentlich erreichbar): Hier ist OAuth 2.1 mit PKCE Pflicht – keine Diskussion. Token-Audience-Validierung und Resource Indicators (RFC 8707) sind erforderlich. Das ist der richtige Aufwand für Server, die aus dem Internet erreichbar sind.

Ein explizites Anti-Pattern in allen Szenarien: Token-Passthrough – also das direkte Weiterreichen von Client-Tokens an Downstream-APIs ohne Validierung – ist im Standard ausdrücklich verboten.

Organisatorische Governance

Wer darf welche Tools registrieren? Wer pflegt die Server? Wie werden Breaking Changes kommuniziert? Wie wird verhindert, dass 20 Teams 20 leicht unterschiedliche MCP-Server für ähnliche Aufgaben bauen? Diese Fragen sind nicht technisch, aber sie entscheiden über den langfristigen Erfolg.

Ein bewährtes Muster: Ein zentrales Platform-Team betreibt die Basis-Infrastruktur (Transport, Auth, Monitoring), einzelne Teams registrieren ihre domänenspezifischen Tools darauf.

Input-Validierung

Zod (TypeScript) und schemars (Rust) validieren die Eingaben auf Schema-Ebene. Das ist eine erste Verteidigungslinie, aber keine vollständige. Tool-Handler müssen ihre Eingaben zusätzlich gegen Business-Regeln prüfen – besonders wenn sie Schreibzugriff auf Systeme haben.

Temporäre Lösung oder dauerhafte Infrastruktur?

Die Frage ist berechtigt: Ist MCP ein weiterer Standard, der in zwei Jahren von etwas Neuem abgelöst wird?

Die Signale deuten auf Dauerhaftigkeit hin. Die Übergabe an die Linux Foundation, die Unterstützung durch Anthropic, OpenAI, Google, Microsoft und AWS, die breite Client-Adoption – das ist mehr Momentum als die meisten Protokolle nach einem Jahr haben. Google hat parallel A2A (Agent-to-Agent) vorgestellt, aber beide Protokolle adressieren unterschiedliche Ebenen: MCP verbindet Modelle mit Tools, A2A verbindet Agenten untereinander.

Das Risiko ist weniger, dass MCP verschwindet, sondern dass es sich schnell weiterentwickelt. Die Transport-Layer-Änderung (SSE zu Streamable HTTP) und die Auth-Spec-Updates zeigen, dass der Standard noch in Bewegung ist. Wer heute einen MCP-Server baut, sollte mit Updates rechnen – aber die Grundkonzepte (Tools, Resources, Prompts über JSON-RPC) sind stabil.

Der pragmatische Einstieg

Der beste Startpunkt ist ein kleiner, lokaler stdio-Server mit zwei bis drei Tools, die ein konkretes Problem lösen. Keine große Architektur, kein OAuth-Setup, kein Remote-Deployment. Ein Node.js-Script, das über die Team-Konventionen Bescheid weiß und in der MCP-Konfiguration des Editors eingetragen wird.

Wenn das funktioniert und der Nutzen sichtbar ist, wächst der Server organisch: mehr Tools, mehr Resources, vielleicht ein zweiter Server für eine andere Domäne. Der Schritt zu Remote-Servern mit Auth kommt erst, wenn mehrere Teams oder Standorte denselben Server brauchen.

Das Schöne an MCP: Der Einstieg kostet eine halbe Stunde und ein npm-Paket. Das Protokoll skaliert von einem lokalen Entwickler-Tool bis zur unternehmensweiten Infrastruktur – ohne dass man am Anfang die Endausbaustufe planen muss.

Weiterführende Ressourcen

• Model Context Protocol – Offizielle Spezifikation
• TypeScript SDK auf GitHub
• Rust SDK (rmcp) auf GitHub
• MCP Server erstellen – Offizielle Docs
• Agentic AI Foundation (AAIF)
• Mistral MCP Documentation