Model Context Protocol (MCP): Der USB-Standard für KI-Tools

Letzte Woche saß ich in einem Architektur-Review für einen CompanyGPT-Rollout. Die Frage war nicht „welches Modell", sondern: Wie binden wir Confluence, Jira, das Ticketsystem und unsere Enterprise Search an – ohne für jede Kombination aus Host und Datenquelle einen eigenen Adapter zu bauen? Genau an dieser Stelle taucht Model Context Protocol (MCP) auf.

Ich kenne das Muster aus zehn Jahren Enterprise Search: Jede Anwendung baut eigene Konnektoren, eigene Authentifizierung, eigene Fehlerbehandlung. MCP verspricht, das für die KI-Schicht zu standardisieren. Kein Hype-Wort – ein tatsächlich nutzbarer Ansatz, wenn man weiß, wo er hilft und wo nicht.

In den letzten Monaten habe ich MCP in IDE-Agenten (Cursor), in Piloten mit Claude Desktop und in ersten internen Agent-Prototypen getestet. Der gemeinsame Nenner: MCP spart Integrationsarbeit beim Host-Wechsel. Die Arbeit steckt im Server – und dort beginnt auch die Verantwortung für Auth und Datenqualität.

Was MCP ist – und was nicht

MCP ist ein offener Standard für die Kommunikation zwischen KI-Anwendungen („Hosts") und externen Datenquellen oder Werkzeugen („Server"). Initiiert von Anthropic, inzwischen community-getrieben. Stell dir MCP wie einen einheitlichen Stecker vor: Ein Host (Cursor, Claude Desktop, eine eigene Agent-App) spricht MCP; Server stellen Resources (lesbarer Kontext), Tools (ausführbare Aktionen) und Prompts (Vorlagen) bereit.

MCP ist kein Ersatz für RAG-Pipelines, kein Ersatz für Zugriffskontrolle und kein Wundermittel für Agenten, die „alles können". Es standardisiert die Anbindung – nicht die Qualität deiner Daten oder Prompts.

Architektur in der Praxis

┌─────────────┐     MCP       ┌──────────────┐
│  MCP Host   │ ◄───────────► │  MCP Server  │
│ (IDE, Chat) │  JSON-RPC /   │ (Wiki, DB,   │
│             │  stdio / SSE  │  Tickets, …) │
└─────────────┘               └──────────────┘
       │                              │
       ▼                              ▼
   LLM / UI                     APIs & Daten

Drei Konzepte, die ich in Projekten tatsächlich nutze:

1. Resources – Dateien, Datensätze, Suchergebnisse als lesbarer Kontext
2. Tools – Suche ausführen, Ticket anlegen, Query schicken
3. Prompts – wiederverwendbare Vorlagen für wiederkehrende Aufgaben

MCP vs. REST vs. Function Calling

Function Calling passiert im Modell-Request. MCP sitzt davor als Schicht zwischen Host und Systemen. Ein MCP-Server für euer internes Wiki funktioniert theoretisch in Cursor, in Claude Desktop und in einer eigenen CompanyGPT-App – ohne drei separate Integrationen.

Enterprise-Szenarien, die Sinn ergeben

Aus meiner Sicht lohnen sich diese Einstiege:

• Wissenszugriff: MCP-Server auf Enterprise Search (Sinequa, Elasticsearch, SharePoint-Index)
• Entwicklung: GitHub- oder Jira-MCP in IDE-Agenten für Code- und Ticket-Kontext
• IT-Ops: Server für Monitoring-Daten, Runbooks, Log-Snippets
• Compliance: Tool-Aufrufe am Server protokollieren, Berechtigungen dort erzwingen

Was ich nicht empfehle: zehn MCP-Server gleichzeitig ausrollen, bevor ein einziger stabil läuft. Oder MCP als Ersatz für eine durchdachte RAG-Pipeline verkaufen.

Ein konkretes Beispiel: Wiki-Server

Stell dir einen MCP-Server vor, der an eure Confluence- oder Wiki-API angebunden ist:

• Resource wiki://page/{id} – liefert Seiteninhalt als Markdown
• Tool search_wiki – Parameter query, limit – gibt Treffer mit IDs zurück
• Tool get_page – Parameter page_id – lädt eine Seite nach

Der Host (z. B. Cursor) ruft search_wiki auf, bekommt IDs, lädt relevante Seiten als Resources. Das LLM arbeitet mit echtem Kontext – nicht mit geratenen URLs. Der Server erzwingt unter der Haube dieselben ACLs wie die Wiki-API: Wenn der User die Seite nicht lesen darf, kommt kein Inhalt zurück.

So ein Server ist in ein bis zwei Wochen baubar – wenn die Wiki-API sauber dokumentiert ist. Die Feinarbeit steckt in Pagination, Rate Limits und Fehlermeldungen, die das LLM verstehen kann.

Transport: stdio, SSE, HTTP

MCP kennt mehrere Transports. Lokal in der IDE nutze ich oft stdio – einfach, kein Netzwerk-Exposure. Für zentrale Server im Unternehmen SSE oder HTTP hinter Reverse Proxy mit OAuth. stdio-Server auf jedem Laptop skaliert nicht; ein zentraler MCP-Server mit Auth schon – wenn Latenz und Verfügbarkeit passen.

Sicherheit – der Teil, den viele überspringen

MCP löst Integration, nicht Autorisierung. In Enterprise-Projekten brauche ich zusätzlich:

• Authentifizierung Host ↔ Server (OAuth, mTLS, API-Tokens mit Scope)
• Least Privilege: Jeder MCP-Server nur die Rechte, die er braucht
• Audit-Logs für jeden Tool-Aufruf (wer, wann, welches Tool, welches Ergebnis)
• Trennung Dev/Prod: welche Server in welcher Umgebung erlaubt sind

Ein MCP-Server mit Schreibzugriff auf Jira ohne Rollenprüfung ist ein Ticket-Spam-Risiko – unabhängig davon, wie elegant das Protokoll ist.

Wie MCP in meinen Stack passt

Ich kombiniere MCP bewusst mit anderen Schichten:

• LiteLLM für Modell-Routing, Budget und Keys
• n8n für deterministische Prozess-Automation (kein Agent, sondern Workflow)
• RAG-Backend für dokumentenbasiertes Retrieval mit ACL und Evaluation

MCP ergänzt diese Bausteine. Es ersetzt sie nicht. Ein Agent in der IDE, der per MCP ein Wiki durchsucht, braucht trotzdem saubere Index-Daten. Ein n8n-Workflow, der Tickets schließt, braucht keinen MCP-Server – REST reicht.

Wann ich MCP nicht einsetze

Nicht jede Integration braucht einen Agenten. Batch-Importe, nächtliche Synchronisation, feste Reports – das bleibt bei n8n oder klassischen ETL-Jobs. MCP lohnt sich, wenn ein interaktiver Host dynamisch entscheidet, welches Tool es wann braucht. Für deterministische Abläufe ist ein Workflow lesbarer, testbarer und günstiger im Betrieb.

Außerdem: Ein MCP-Server, der dieselben Daten wie euer RAG-Index liefert, aber ohne Hybrid Search und ohne Evaluation, reproduziert dieselben Qualitätsprobleme – nur über ein anderes Protokoll.

Was ich in Projekten anders mache

Ein Server zuerst. Ich starte mit der am häufigsten genutzten Quelle – internes Wiki oder Ticket-System. Nutzung, Fehlerrate, Latenz messen. Erst dann der nächste Server.

Kein Agent ohne Grenzen. Jeder MCP-Server bekommt eine klare Tool-Liste. „Darf alles" gibt es nicht. Schreib-Tools nur mit Bestätigung oder in separaten Umgebungen.

Gleiche Identität wie im Rest des Systems. Der MCP-Server muss die User-Identität des Hosts respektieren – nicht als Super-Admin auf alle Daten zugreifen.

Logging von Anfang an. Wer welches Tool wann aufgerufen hat, ist in regulierten Umgebungen Pflicht.

Nicht jedes Problem ist ein Agent-Problem. Viele Anforderungen löse ich schneller mit n8n und festen Workflows als mit einem explorierenden Agenten.

In regulierten Umgebungen frage ich zusätzlich: Wer haftet für eine falsche Tool-Aktion? Bei MCP muss die Antwort im Server-Design liegen – Bestätigung für Schreibzugriffe, klare Fehlertexte, keine stillen Defaults. Ein Agent, der 200 Wiki-Seiten in den Kontext zieht, weil das Tool kein Limit hat, ist kein Modellproblem – es ist schlechtes Tool-Design.

Empfehlungen und Checkliste

1. Use Case definieren: Welche Datenquelle, welcher Host, welche Tools?
2. Einen MCP-Server bauen oder adaptieren, mit minimaler Tool-Liste
3. Auth und Least Privilege implementieren, bevor Pilot-Nutzer draufgehen
4. Audit-Logging aktivieren
5. Latenz und Fehlerrate zwei Wochen beobachten
6. Erst dann skalieren – weitere Server, weitere Hosts
7. Parallel: RAG-Qualität und ACLs nicht vernachlässigen

Eine kurze Einordnung für Entscheider: MCP ist Infrastruktur, kein Feature-Slide. Der ROI zeigt sich, wenn der dritte Host angebunden wird – nicht beim ersten Prototyp. Bis dahin ist es legitime Vorarbeit.

Fazit

MCP wird 2026 zum de-facto-Integrationslayer für Agenten und IDE-Tools – nicht weil es magisch ist, sondern weil der Connector-Wildwuchs sonst jedes KI-Projekt ausbremst. Wer Enterprise-RAG und CompanyGPT plant, sollte MCP in der Architektur einplanen: als Standard für Tool- und Kontext-Anbindung, nicht als Abkürzung für solide Retrieval-Pipelines.

Fragen zur Agent-Architektur bei euch? LinkedIn