Thin vs Native MCP: Warum das Modell hinter dem Server über alles entscheidet

Ein MCP-Server ist nur so gut wie das Modell dahinter

Das Model Context Protocol hat seinen Moment. Anbieter überschlagen sich mit der Ankündigung, dass ihr Enterprise-Architecture-Werkzeug nun „MCP spricht“, als wäre das Protokoll das Produkt. Ist es nicht. MCP ist ein Konnektor — eine Commodity, der USB-Port der KI. Die interessante Frage ist nie, ob ein Werkzeug MCP kann; sie ist, worüber der Agent tatsächlich schließen kann, sobald er verbunden ist.

Das hängt vollständig vom Modell ab, das der Server freigibt. Verbinden Sie einen Agenten mit einer flachen Anwendungstabelle und Sie bekommen Suche. Verbinden Sie ihn mit einem gouvernierten semantischen Graphen und Sie bekommen Wirkungsanalyse. Dasselbe Protokoll, zwei verschiedene Welten. Deshalb zählt die Unterscheidung zwischen einem Thin MCP und einem nativen MCP mehr als das MCP-Abzeichen auf der Schachtel.

Thin MCP: ein Wrapper, der Zeilen zurückgibt

Ein Thin MCP ist ein leichtgewichtiger API-Wrapper über den Tabellen des Repositorys. Er gibt Zeilen und Attribute frei, und nicht viel mehr. Fragen Sie ihn „zeige mir die Anwendungen mit dem Tag Zahlungen“ und er gibt genau das zurück: eine flache Liste von Anwendungsdatensätzen, vielleicht mit ein paar Spalten.

Daran ist für einfache Nachschlagungen nichts falsch, und es ist schnell gebaut. Aber der Agent am anderen Ende hat keine Ahnung, was diese Anwendungen unterstützen, wem sie gehören, welche Kontrollen sie abdecken oder was bricht, wenn eine stillgelegt wird. Das Modell hinter dem Server ist im Wesentlichen eine Tabelle. Der Agent kann lesen; er kann nicht schließen.

• Gibt Zeilen und Attribute frei, keine Beziehungen
• Beantwortet „was ist mit X getaggt“, aber nicht „was hängt von X ab“
• Keine Geschäftssemantik, kein Lebenszyklus, kein Governance-Kontext
• Billig auszuliefern, aber der Agent erbt eine oberflächliche Welt

Native MCP: ein Server, der das Metamodell freigibt

Ein natives MCP gibt das Metamodell selbst frei — die Geschäftssemantik, die Beziehungen, die Lebenszyklusstände, die Governance-Regeln, die ein EA-Modell zu mehr als einer Liste machen. Stellen Sie dieselbe Zahlungsfrage und ein nativer Server kann einen Pfad verfolgen: von der regulatorischen Anforderung über die Kontrolle, die sie adressiert, über den Geschäftsprozess, den sie schützt, zu den Anwendungen, die ihn betreiben, zur Infrastruktur darunter.

Entlang dieses Pfads bringt er zutage, was eine flache Liste nicht kann: eine Anwendung ohne benannten Eigentümer, einen Prozess ohne zugeordnete Kontrolle, eine Abhängigkeit, die auf eine veraltete Komponente zeigt. Das ist der Unterschied zwischen Daten abrufen und über ein Modell schließen. Bizzdesign gebührt Anerkennung dafür, diese Thin-versus-native-Rahmung öffentlich aufgeworfen zu haben; es ist ein wahrhaft nützlicher Weg, Konnektoren, die bloß antworten, von Konnektoren, die tatsächlich informieren, zu trennen.

• Verfolgt Anforderung → Kontrolle → Prozess → Anwendung → Infrastruktur
• Bringt Eigentümerlücken und Abdeckungslücken beim Schließen zutage
• Trägt Geschäftsbedeutung, nicht nur Feldwerte
• Verwandelt „vernetzt“ in „fähig zur Wirkungsanalyse“

Aber nativ ist auch nicht die Ziellinie

Hier neigt das Branchengespräch dazu aufzuhören — und genau hier sollte es das nicht. Ein natives MCP macht Antworten reicher, aber reich ist nicht dasselbe wie vertrauenswürdig. Zwei Fehlermodi überleben selbst ein perfektes Metamodell, und beide zählen in regulierten Finanzinstituten mehr als die Thin-versus-native-Lücke selbst.

Der erste ist Aktualität. Ein nativer Graph, der einen achtzehn Monate alten Schnappschuss spiegelt, schließt selbstbewusst über eine Realität, die nicht mehr existiert — benennt Eigentümer, die gegangen sind, Kontrollen, die abgeschafft wurden, Abhängigkeiten, die umgeleitet wurden. Tiefe verstärkt veraltete Daten; sie korrigiert sie nicht. Der Kontext muss lebendig sein, um abfragenswert zu sein, weshalb wir immer wieder zur Idee eines agentenbereiten, kontinuierlich aktualisierten Repositorys zurückkehren.

Der zweite ist Souveränität. Wenn ein Agent einen nativen EA-Graphen abfragt, liest er einen nahezu vollständigen Bauplan der Organisation: das gesamte Systeminventar, die kritischen Abhängigkeiten, die veralteten Komponenten, manchmal die Sicherheitsmaßnahmen. Wenn das Modell hinter der Antwort auf einem US-Cloud-LLM läuft, verlässt dieser Bauplan Ihre Kontrolle. Für eine DORA-, CSSF- oder EU-AI-Act-regulierte Institution ist das kein Feature-Kompromiss — es ist ein Residenz- und Governance-Problem. Ein wirklich fähiges MCP muss gouvernieren, wohin die Daten gehen, nicht nur wer fragen darf.

Die Tiefe, die für regulierte Finanzinstitute wirklich zählt

Stapeln Sie die Anforderungen und eine klare Hierarchie erscheint. Semantik zuerst: Das Modell muss Bedeutung tragen, nicht nur Zeilen, sonst kann der Agent nicht schließen. Governance als Nächstes: Das Modell muss seine eigenen Regeln, Eigentümer und Kontrollen kennen, sonst ist das Schließen unverankert. Aktualität als Drittes: Das Modell muss lebendig sein, sonst schließt es selbstbewusst falsch. Souveränität zuletzt, aber nicht verhandelbar: Das Modell muss sensiblen Kontext innerhalb Ihrer Kontrolle halten, sonst ist nichts davon sicher zu nutzen.

Thin versus nativ ist der Eröffnungszug in diesem Argument, nicht das ganze Spiel. Für eine Bank oder einen Versicherer in der EU ist die echte Latte Semantik plus Governance plus Aktualität plus Souveränität — alle vier. Ein Konnektor, der die ersten zwei meistert und die letzten zwei ignoriert, ist ein selbstbewusster, wortgewandter Haftungsfall.

• Semantik — über ein Modell schließen, nicht über eine Tabelle
• Governance — Eigentümer, Kontrollen und Regeln, von denen das Modell weiß
• Aktualität — ein lebendiges Repository, kein alternder Schnappschuss
• Souveränität — Kontext, der in der EU und unter Ihrer Kontrolle bleibt

Was das für ArchiLU bedeutet — und wo wir ehrlich sind

Wir sagen klar, was wir nicht haben: ArchiLU liefert heute keinen MCP-Server aus. Es ist eine Überzeugung und eine Richtung auf unserer Roadmap, kein Feature, das Sie einschalten können. Wir sind lieber klar darüber, als ein Produkt zu vermarkten, das nicht existiert.

Was wir ausliefern, ist der Teil, der jedes zukünftige MCP überhaupt erst lohnenswert macht. Ein vernetztes, gouverniertes EA-Modell — Fähigkeiten, Anwendungsportfolio, Abhängigkeiten —, das Semantik trägt statt nackter Zeilen. Hosting in einer EU-Region oder On-Premise, das Sie kontrollieren, sodass der Kontext nie Ihren Souveränitätsperimeter verlassen muss. Natives Französisch und Englisch, gebaut um DORA- und CSSF-Dokumentationsbedürfnisse. Und ein veröffentlichter Preis, den Sie lesen können, bevor Sie je mit dem Vertrieb sprechen. Bauen Sie den Kontext richtig, halten Sie ihn lebendig, halten Sie ihn souverän — dann ist das Protokoll obendrauf ein Detail. Die Reihenfolge ist der Punkt.

Ein ehrlicher Vorbehalt, den man im Blick behalten sollte: Ein EA-Modell und ein MCP helfen Ihnen, Ihre Architektur zu dokumentieren und zu belegen; sie machen Sie nicht konform. Regulatorische Bereitschaft ist eine Dokumentations- und Nachweishilfe, keine rechtliche Garantie — behandeln Sie sie so.