Was MCP wirklich löst: von N × M Integrationen zu N + M

Die Frage hinter dem Hype

Ein Team, das MCP-Unterstützung ausliefert (einen Server mit 16 Tools plus einen Client, der sich mit anderen MCP-Servern verbindet), hört früher oder später den schärfsten Einwand aus den eigenen Reihen: Wenn MCP nur APIs aufruft und Daten zurückgibt, wozu dann der Aufwand? REST-APIs gibt es doch schon.

Die Frage ist berechtigt, und die meisten MCP-Erklärungen stolpern, weil sie beim Protokoll statt beim Problem anfangen. Fangen wir also beim Problem an.

Für welches Problem es MCP gibt

Stellen Sie sich eine Führungskraft vor, die einen KI-Assistenten fragt: Welche Bestellanforderungen liegen in meiner Freigabe-Warteschlange? Das Beschaffungssystem kennt die Antwort und hat vermutlich eine REST-API davor. Was fehlt also noch? Es gibt vier übliche Wege, jeder mit einem Haken:

1. Die Datensätze ins Chatfenster kopieren. Das klappt einmal, von Hand, und die Kopie veraltet sofort.
2. Einen Chatbot direkt in die Beschaffungs-App einbauen. Schöner, aber die KI ist jetzt auf diese App beschränkt und die Integration müssen Sie für immer pflegen.
3. Die API-Dokumentation einfügen und darauf vertrauen, dass das Modell den richtigen Endpunkt wählt. Kann funktionieren, bricht aber leicht.
4. Für jeden im Unternehmen genutzten Assistenten eine eigene Integration schreiben.

Der letzte Weg wird schnell chaotisch. Ein Unternehmen mit 10 internen Systemen und 5 Assistenten braucht womöglich bis zu 10 × 5 = 50 separate Integrationen, jede mit eigenem Auth-Code, eigenen Eigenheiten und eigener Wartung. MCP wurde genau dafür entworfen, diese Multiplikation zu beseitigen.

Von N × M zu N + M

Statt jeden KI-Client mit jedem System zu verdrahten, beschreibt jedes System seine Fähigkeiten einmal über ein Standardprotokoll, und jeder KI-Client implementiert dieses Protokoll einmal. Ohne MCP braucht jede Kombination ihre eigene Integration:

Without MCP: every pair needs its own integration

System A ──── AI Client 1
System A ──── AI Client 2
System B ──── AI Client 1
System B ──── AI Client 2N × M integrations

Mit MCP wird jede Seite einmal gebaut:

With MCP: build once on each side

System A ──┐             ┌── AI Client 1
System B ──┼──── MCP ────┼── AI Client 2
System C ──┘             └── AI Client 3N + M implementations

Bei zehn Systemen und fünf Assistenten sinkt die Zahl der Implementierungen von 50 auf 15. In einem Satz: Mit MCP kann ein Assistent herausfinden, was ein System anbietet, und es nach einer gemeinsamen Konvention aufrufen.

Drei Ideen lassen das einrasten.

1. Im MCP-Server steckt keine KI

Das ist wohl das häufigste Missverständnis. Man stellt sich eine Kette wie diese vor:

User → AI → MCP Server → API → AI → Answer

mit einem zweiten Modell, das auf der anderen Seite nachdenkt. So etwas gibt es nicht. Der Server ist schlichter, herkömmlicher Code, der nie ein LLM aufruft. In der Praxis sieht es eher so aus:

User
 ↓
LLM            decides which tool it needs
 ↓
MCP Client     sends the call
 ↓
MCP Server     executes it
 ↓
Your API / business logic
 ↓
Structured data
 ↓
LLM            interprets the result
 ↓
Answer

Der Server sind die Hände, das Modell ist das Gehirn.

2. „Wir haben doch schon REST-APIs“

Stimmt, und die API war nie das, was fehlte. Nehmen wir eine Beschaffungs-App mit diesem Endpunkt:

GET /api/v1/rtps?view=inbox&page=0

Ein Mensch liest die Doku und versteht das. Ein Modell muss zur Laufzeit herausfinden, wofür der Endpunkt steht, wann er passt und welche Parameter es senden soll, und niemand hat den Klebecode geschrieben, der ihm das sagt.

MCP ergänzt Discovery. Ein Client kann einen Server fragen, was er kann, und bekommt eine Liste von Fähigkeiten:

list_my_approvals
get_purchase_request
search_suppliers
get_purchase_order
create_rfq

Jeder Eintrag hat eine Beschreibung und ein Eingabeschema. Das erste Tool erreicht das Modell etwa so:

{
  "name": "list_my_approvals",
  "description": "List purchase requests waiting for the current user's approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page": { "type": "integer", "description": "Zero-based page number" }
    }
  }
}

Stellen Sie GET /api/v1/rtps?view=inbox&page=0 neben list_my_approvals. Die URL benennt eine Route, der Toolname beschreibt eine Fähigkeit in Worten, über die ein Modell nachdenken kann. Genau diese Lücke schließt MCP.

(Server können auch Ressourcen und wiederverwendbare Prompts anbieten, aber Tools sind der übliche Einstieg und das Thema hier.)

3. Spannend wird es bei der Komposition

Hier wird MCP mehr als ein Wrapper um eine API. Verbinden Sie drei Server mit einem Assistenten:

• Einen Monitoring-Server mit get_system_health und get_recent_incidents
• Einen Wissensserver mit get_document, search_documents und find_certificate
• Einen Beschaffungsserver mit den Tools get_purchase_order, get_purchase_request und list_my_approvals

Stellen Sie dem Assistenten dann eine zusammengesetzte Frage: Liste die offenen Bestellanforderungen auf und markiere alle, denen Nachweiszertifikate fehlen. Das Modell ruft die Beschaffungs-Tools auf, fragt beim Wissensserver die Zertifikate jeder Anforderung ab, führt die Ergebnisse zusammen und antwortet einmal. Keiner der Server weiß von den anderen, und das ist in Ordnung.

Die Integration übernimmt also das Modell selbst. Vergleichen Sie das mit einem einzigen überdimensionierten Chatbot, der fest an jedes Backend verdrahtet ist. Hier kommt ein neues System als ein weiterer Server hinzu, und der Assistent bleibt unangetastet.

Das Modell als Integrationsschicht

Klassische Integration sieht so aus:

System A
   ↕
Integration Layer
   ↕
System B

Mit agentischer KI wird daraus:

               AI Model
             /    |    \
            /     |     \
     MCP Server  MCP Server  MCP Server
          |          |          |
      Procurement  Knowledge  Monitoring

Das Modell entscheidet, welche Fähigkeit es braucht – grundlegend anders, als eine einzige Integrationsschicht zu bauen, die jedes System versteht.

Die Parallele zu LSP

Entwickler kennen diese Form schon vom Language Server Protocol. Früher schrieb jeder Editor für jede Sprache eigene Autovervollständigung, „Gehe zu Definition“ und Fehlermarkierung – dasselbe N × M-Knäuel. Mit LSP stellt eine Sprache diese Funktionen einmal bereit, als Language Server, und jeder Editor, der das Protokoll spricht, bekommt sie. MCP orientiert sich offen an LSP.

Kaum jemand fragt, wozu Java LSP braucht, wo es doch einen Compiler hat. Der Compiler war nie das Ziel. Genauso beschreibt Ihre API, was das System kann, während MCP beschreibt, wie ein KI-Client von diesen Fähigkeiten erfährt und sie aufruft.

Es geht also nicht um REST gegen MCP, sondern um REST darunter und MCP obendrauf für KI-Interoperabilität.

Was MCP ungelöst lässt

Diesen Teil überspringt der Hype gern.

Ein Modell wird durch MCP nicht klüger. Toolbeschreibungen wirken wie Prompts, also führt eine schlampige Beschreibung zu schlampigen Aufrufen.

Auch um Sicherheit kümmert sich niemand für Sie. search_suppliers zu veröffentlichen ist wenig riskant, weil es nur nachschlägt, aber mit approve_purchase_order geben Sie eine Finanzkontrolle aus der Hand. Planen Sie Authentifizierung, Autorisierung, minimale Rechte, Audit-Logs und eine ausdrückliche Bestätigung vor jeder Zustandsänderung ein.

Denken Sie auch daran, dass alles, was ein Tool zurückgibt, direkt im Kontext des Modells landet. Ein abgerufenes Dokument kann Anweisungen enthalten, die den nächsten Toolaufruf verbiegen sollen, also behandeln Sie Tool-Ausgaben als nicht vertrauenswürdige Eingaben. MCP öffnet die Tür zu Fähigkeiten und sagt nichts darüber, ob es sicher ist, hindurchzugehen.

Brauchen Sie MCP überhaupt?

Ob Sie eine API haben, ist der falsche Test. Der bessere: Wählt ein Modell aus einem KI-Client, den Sie nicht kontrollieren, welche Fähigkeit aufgerufen wird?

Wenn nicht, lassen Sie MCP weg; einfache API-Aufrufe oder das Function Calling Ihres Frameworks sind simpler. Wenn ja, ist Interoperabilität Ihr Problem, und Sie können es mit eigenen Plugins, proprietären Protokollen und Integrationen pro Client angehen oder einen Standard übernehmen. Darauf läuft die Entscheidung hinaus.

Was ein Server mit 16 Tools zeigt

Sobald ein Server mit 16 Tools existiert, ist das Spannende nicht, dass die eigene KI des Teams die eigene API aufrufen kann – das ging vorher auch. Spannend ist, dass ein anderer KI-Client die Fähigkeiten des Systems entdecken kann, ohne dass jemand eine Integration für diesen Client gebaut hat.

Das ist der Gewinn. Die API enthält, was getan werden kann; MCP ist der Weg, auf dem ein Assistent erfährt, was möglich ist, und es ausführt. Mit dieser Unterscheidung im Kopf wirkt MCP weniger wie ein Schlagwort und mehr wie Infrastruktur-Klempnerei.