Universal MCP Client: Chatbot trifft 50 Custom-Apps

Phillip Pham | 11 Min. Lesezeit | 03.06.2026

TL;DR

Universal MCP Client löst das eigentliche Mittelstands-Problem mit Enterprise-Chatbots: Der Chatbot kann zwar SAP, Microsoft 365 und Salesforce, aber kennt die 50 wichtigen Custom-Apps des Hauses nicht — das Reklamationssystem von 2014, die Excel-getriebene Vertriebsplanung, das eigenentwickelte Konstruktions-Portal, das Lager-Tool. Pexon Consulting baut einen Aggregations-Layer, der MCP-Server für Custom-Apps standardisiert produziert und über einen einzigen Client an den Chatbot bringt — als 8-Wochen-Sprint statt 18-Monate-Migrations-Projekt.

Warum dein Chatbot 90% deiner Apps nicht kennt

Wir sehen in fast jedem Pexon-Erstgespräch das gleiche Muster: Der CIO ist stolz auf den Roll-out des Enterprise-Chatbots — Copilot for Microsoft 365 plus einen Anthropic- oder OpenAI-basierten Wissensagenten. Die Standardsoftware-Anbindung steht, MCP-Server für SAP und ServiceNow laufen. Die Frage des CTO im Erstgespräch ist dann immer: „Wann kann der Chatbot auch unser Reklamationssystem ansprechen? Und das Vertriebs-Dashboard? Und die 32 anderen Custom-Apps, die unser Tagesgeschäft tragen?“

Die ehrliche Antwort: Heute eigentlich nie, weil niemand die 32 Custom-Apps einzeln über MCP-Server anbinden möchte. Pro Custom-App bedeutet das aktuell drei bis fünf Wochen Engineering — Datenmodell verstehen, Auth-Brücke bauen, MCP-Server schreiben, deployen, monitoren. Bei 32 Apps sind das im Best Case 96 Wochen oder zwei Engineering-Personenjahre. Das macht niemand. Folge: Der Chatbot kennt die Strategie-Folien, aber nicht die Reklamationsstatistik der letzten zwölf Monate.

Das eigentliche Problem ist nicht MCP an sich — das Protokoll ist gut spezifiziert und etabliert. Anthropic, OpenAI und Block haben Ende 2025 die Agentic AI Foundation gegründet, um MCP als Cross-Vendor-Standard zu zementieren. Das Problem ist die Engineering-Tax pro Custom-App: Jeder MCP-Server für eine eigenentwickelte App braucht den gleichen Bauplan immer wieder. Auth, Schema-Inferenz, Tool-Definition, Error-Handling, Audit-Trail. Das standardisieren wir mit einem Universal MCP Client plus einem strukturierten Server-Pattern.

Wer den Konzept-Background braucht, fängt mit unseren bestehenden Posts an: MCP-Erklärung für Mittelstand und MCP vs API vs iPaaS. Dieser Beitrag setzt voraus, dass MCP grundsätzlich klar ist, und behandelt das Aggregation-Problem.

Was ein Universal MCP Client eigentlich tut

Der Begriff ist 2026 noch etwas wabernd, deshalb klare Definition: Ein Universal MCP Client ist eine Software-Schicht zwischen Chatbot und beliebig vielen MCP-Servern, die drei Funktionen übernimmt. Erstens Aggregation: Der Chatbot spricht mit einem einzigen Endpunkt, der intern auf 5, 20 oder 100 MCP-Server routet. Zweitens Standardisierung: Custom-Apps werden über ein einheitliches Server-Pattern angebunden, statt jede Anbindung als Einzelprojekt zu schreiben. Drittens Cross-Cutting Concerns: Auth, Permissions, Rate-Limiting, Audit-Trail werden zentral statt pro Server gelöst.

Damit verschiebt sich der Aufwand pro Custom-App von „MCP-Server bauen“ zu „Custom-App-Adapter konfigurieren“. Das ist eine Reduktion von Wochen auf Tage, weil 80% des MCP-Server-Codes generisch ist und nur 20% wirklich app-spezifisch.

Architektur in Stichworten: Der Chatbot (Claude über Bedrock, ChatGPT Enterprise, Copilot Studio, oder ein selbstgebauter LangGraph-Agent) spricht einen einzigen MCP-Endpunkt — den Universal Client. Dieser hält intern eine Registry der angebundenen Custom-MCP-Server. Jeder Custom-Server folgt einem standardisierten Pattern, das wir als Pexon-Code-Repo liefern. Auth läuft zentral über das Unternehmens-IdP (Entra ID, Keycloak), Permissions werden im Aggregator durchgesetzt, jeder Tool-Call wird konsolidiert geloggt.

from pexon_mcp_universal import UniversalMcpServer, AppAdapter

server = UniversalMcpServer(
    idp_provider="entra_id",
    audit_backend="postgres://audit-log/mcp",
    rate_limit_per_user="60/min",
)

server.register_app(AppAdapter(
    name="reklamation_app",
    base_url="https://reklamationen.intern.example.com/api/v2",
    auth_method="oauth2_passthrough",
    schema_inference="auto",
    permissions_rule="role:vertrieb OR role:qm",
))

server.register_app(AppAdapter(
    name="lager_tool",
    base_url="https://lager.intern.example.com",
    auth_method="basic_service_account",
    schema_inference="manual",
    schema_file="lager_tool_mcp_schema.yaml",
    permissions_rule="role:lager OR role:einkauf",
))

server.run(port=8443, tls_cert="universal-mcp.crt")

Was der Code andeutet: Anbindung einer Custom-App ist 5-10 Zeilen plus ggf. ein YAML-Schema. Nicht 500 Zeilen Custom-MCP-Server-Code.

Vier Custom-App-Patterns für den Mittelstand

Wir haben bei drei Mittelständlern Bestand-Audits gemacht und 80-130 Custom-Apps gesehen. Vier strukturelle Patterns wiederholen sich konstant — und der Universal MCP Client hat für jedes ein passendes Anbindungs-Verfahren.

Pattern 1 ist der Idealfall. OpenAPI 3.x ist da, der Aggregator zieht das Schema automatisch und exponiert die Endpoints als Tools. Auth läuft über OAuth2-Passthrough (User-Token wird durchgeschleift). Bei einem unserer Pilotkunden hatten 14 von 80 Custom-Apps OpenAPI-Specs — die waren in zwei Wochen alle angebunden.

Pattern 2 ist die häufigste Realität. Die App hat REST-Endpoints, aber keine maschinenlesbare Spec. Wir generieren die Spec halbautomatisch — Lese-Zugriff auf die App-Doku plus 30 Minuten Klick-Reverse-Engineering mit Postman plus 1-2 Stunden manuelle Refinement-Arbeit. Resultat ist ein YAML-Schema, das der Aggregator gleichbehandelt wie OpenAPI.

Pattern 3 sind die Altsysteme. SOAP-Wrapper, XML-RPC-Endpoints, klassische WSDL-Definitionen. Hier brauchen wir einen Adapter, der die SOAP/XML-Calls in MCP-Tool-Calls übersetzt. Das ist die teuerste Anbindungs-Klasse, aber sie ist machbar und löst oft das größte Pain-Point-Problem, weil genau diese Altsysteme das Tagesgeschäft tragen.

Pattern 4 ist der unterschätzte Bereich. Viele Mittelständler haben kritische Business-Logik in Excel-Workbooks oder Access-Datenbanken vergraben. Vertriebsplanung, Sonderkalkulationen, Margenrechner. Wir bauen einen File-Reader-MCP, der die Excel-Logik versteht (formeln, Pivot, Macros) und als Tool exponiert. Das ist überraschend mächtig — bei einem Kunden hat das die wichtigste Bestandskunden-Margenrechnung erstmals für den Chatbot zugänglich gemacht.

Auth, Permissions und Audit-Trail zentral

Hier liegt der größte Engineering-Wert. In der naiven Anbindung muss jeder MCP-Server seine eigene Auth-Lage und Permissions-Durchsetzung haben. Bei 30 Servern entstehen 30 Mini-Auth-Implementierungen, die alle leicht unterschiedlich sind und gemeinsam ein Audit-Albtraum sind.

Der Universal MCP Client zentralisiert das. Auth läuft über das vorhandene Unternehmens-IdP — Entra ID, Keycloak, oder vergleichbar. Der Chatbot-User authentifiziert sich einmal, der Token wird im Aggregator validiert, weitergegeben an die Custom-Apps via OAuth2-Passthrough oder über ein Service-Account-Mapping für Apps, die keine User-Auth unterstützen. Im Audit landet, welcher Mensch welchen Tool-Call ausgelöst hat — nicht „Service-Account X hat geschrieben“, sondern „Müller hat in der Reklamations-App Eintrag 4711 geändert“.

Permissions werden im Aggregator über deklarative Regeln durchgesetzt. Jeder registrierte App-Adapter bekommt eine Permissions-Regel — typisch über Role-Based-Access-Control gegen das IdP. Wer die Vertriebs-Dashboard-App nicht sehen darf, bekommt die zugehörigen Tools im Chatbot gar nicht erst angezeigt. Das ist nicht nur Security, sondern UX: Der Chatbot wird nicht mit Tools überladen, die der User eh nicht aufrufen darf.

Audit-Trail ist konsolidiert. Pro Tool-Call landet im Audit-Store: User-Identity, Tool, Parameter-Hash, Antwort-Hash, Latenz, Cost, IP-Adresse, Timestamp. Wir setzen das standardmäßig auf Postgres mit Append-Only-Trigger plus optionaler Replikation in S3 Glacier für Langzeit-Retention. Bei einem Vorfall hast du eine Quelle der Wahrheit, statt 30 Log-Files aus 30 Servern zusammenzusuchen. Das deckt sich mit dem Pattern, das wir auch in Document-Intelligence-Pipelines als Sperrlager-Logging einsetzen.

ROI-Rechnung

Konkrete Hausnummern aus einem Pilotkunden 2025/2026. Mittelständischer Industrieausrüster, 1.700 Mitarbeiter, 67 produktive Custom-Apps, Enterprise-Chatbot auf Bedrock-Claude in Pilotphase.

Die Productivity-Komponente ist der eigentliche Hebel. Wenn der Chatbot 44 zusätzliche Apps kennt und die 1.700 Mitarbeiter pro Tag im Schnitt zehn Minuten Suchzeit für Custom-App-Informationen sparen, sind das 283 Personen-Stunden pro Tag. Bei 95 EUR pro Stunde sind das 27.000 EUR pro Tag — von uns konservativ auf 540k EUR Jahres-Save heruntergerechnet, weil nicht jede Minute echte Produktivitäts-Wirkung hat.

Häufig gestellte Fragen

Warum nicht einfach eine iPaaS-Lösung wie Make oder Zapier?

iPaaS löst ein anderes Problem: Workflow-Automatisierung zwischen Apps, ohne Chatbot-Kontext. MCP ist die Schnittstelle vom Chatbot zur App, nicht von App zu App. Beide ergänzen sich — wir nutzen iPaaS für Workflow-Trigger, MCP für Chatbot-Read-und-Write. Mehr im Vergleich MCP vs API vs iPaaS.

Was passiert mit DSGVO und sensiblen Daten?

Der Universal MCP Client läuft on-prem oder im eigenen VPC, nicht in einer externen Cloud. Custom-App-Daten bleiben in der eigenen Infrastruktur. Cloud-Anteil ist nur das Chatbot-Modell selbst — bei Bedrock mit EU-Profil sauber DSGVO-tragfähig. Bei sensitiven Branchen (Defense, Banking, Healthcare) deployen wir auch das Modell on-prem. Siehe Self-Hosted Agent Stack für den Pfad ohne externe Cloud.

Wir haben Apps ohne API, nur Web-Frontend. Geht das auch?

Ja, mit Browser-Automatisierung. Wir bauen für solche Fälle einen Browser-MCP-Server, der die App per Playwright steuert und als Tool exponiert. Aufwand etwas höher als bei REST-Apps (10-20 Tage statt 3-8), und die Stabilität hängt am Frontend des Ziel-Apps — wenn das jährlich umgebaut wird, müssen wir den Browser-Adapter mit nachziehen. Für 5-10 Apps ohne API ist das machbar, für 50 nicht.

Wie integriert sich das in Microsoft Copilot Studio oder einen eigenen LangGraph-Agenten?

Beide gehen. Copilot Studio unterstützt MCP-Connectors seit Q4 2025 — der Universal Client wird als ein Connector registriert und exponiert alle dahinterliegenden Custom-Apps. Bei LangGraph nutzt du den langchain-mcp-adapters-Layer und bekommst die Tools dynamisch geladen. Bei Claude Agent SDK ist MCP first-class — mcp__universal__ ist das Namensschema.

Was, wenn ein Custom-App-Update das Schema bricht?

Wir bauen den Aggregator mit Schema-Versionierung. Bei einem Update werden neue Schemas geprüft, Inkompatibilitäten markiert, der Aggregator routet auf das alte Schema weiter, bis du die Migration explizit freischaltest. Bei einem Pilotkunden lief eine SAP-Schnittstelle drei Wochen lang parallel mit alter und neuer Schema-Variante, ohne Chatbot-Ausfall.

Nächster Schritt

Wenn dein Enterprise-Chatbot heute nur 10-25% deiner internen Apps kennt und du das ändern willst: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise einem Senior-Engineer aus dem IDP-Team. Du beschreibst deine Custom-App-Landschaft und Chatbot-Stack, wir skizzieren den Universal-MCP-Client-Aufbau für eure Realität mit Festpreis.

Verwandte Themen