MCP-Server sind wichtige Bausteine für den Live-Zugriff auf Fachsysteme wie DATEV oder ADDISON. Für den echten Gesamtblick auf Mandanten reichen Connectoren aber nicht aus. Entscheidend ist eine semantische Bedeutungsschicht im Microsoft-365-Tenant – mit Microsoft Graph, Semantic Index, Work IQ und agentischer Ausführung über Copilot Cowork.
Lesezeit: ca. 11 Minuten
Inhaltsverzeichnis
- Was ist ein MCP-Server — und was ist er nicht?
- Das Silo-Problem: Warum 13 Connectoren keinen Mandantenblick ergeben
- Microsoft Graph: das Datenmodell unter allem
- Semantic Index: von Stichworten zu Bedeutung
- Work IQ: die Bedeutungsschicht bekommt einen Namen
- Copilot Cowork: die Schicht bekommt Hände
- Die eigentliche Konsequenz: Datenhaltung ist die strategische Entscheidung
- Und die Fachdaten? Hybrid ist die Antwort
- Governance nicht vergessen: § 203 StGB, DSGVO und die Grenzen des Index
- Fazit
Wer sich derzeit mit KI in der Steuerberatung beschäftigt, begegnet einem Versprechen in immer neuen Varianten: Man baue ein paar MCP-Connectoren zu den Fachsystemen, und schon könne das Sprachmodell mit Mandantendaten arbeiten — Anomalie-Checks vor der UStVA, Auswertungen in Sekunden, Jahresgespräche, die sich fast von selbst vorbereiten. Das ist nicht falsch. Aber es ist nur die halbe Architektur. Denn ein Protokoll ist kein Gedächtnis, ein Connector ist kein Index, und dreizehn Datenquellen ergeben noch keinen Gesamtblick auf den Mandanten.
Dieser Beitrag sortiert die Begriffe: Was ist ein MCP-Server, wie unterscheidet er sich von einer API, was leisten Microsoft Graph, der Semantic Index, Work IQ und Copilot Cowork — und was folgt daraus für die Datenhaltung einer Steuerkanzlei, die wirklich alle Signale zusammenführen will: Buchhaltungsdaten, transkribierte Telefonate, erzeugte Steuererklärungen, die interne Mitarbeiterkommunikation, E-Mails und das Mandantenportal.
Was ist ein MCP-Server — und was ist er nicht?
Das Model Context Protocol (MCP) ist ein offener Standard, den Anthropic Ende 2024 vorgestellt hat und der inzwischen unter dem Dach der Linux Foundation von praktisch allen großen KI-Anbietern getragen wird. Er definiert, wie ein Sprachmodell — genauer: die Host-Anwendung, in der das Modell läuft — mit externen Werkzeugen und Datenquellen spricht. Ein MCP-Server ist die Softwarekomponente, die dieses Protokoll auf der Gegenseite implementiert: Sie stellt dem Modell Tools („frage den Saldo von Konto 1200 ab"), Ressourcen („hier ist die Mandantenstammakte") und vordefinierte Prompts standardisiert zur Verfügung.
Die Abgrenzung zur API ist einfacher, als sie oft dargestellt wird. Eine API — etwa DATEVconnect oder eine REST-Schnittstelle — ist anbieterspezifisch: Jedes System spricht seinen eigenen Dialekt, und wer zwei KI-Anwendungen an fünf Fachsysteme anbinden will, baut zehn individuelle Integrationen. MCP setzt eine Abstraktionsschicht darüber. Der MCP-Server kapselt die jeweilige API und übersetzt sie in ein einheitliches Format, das jeder MCP-fähige Client versteht — Claude, Copilot, ein Agent in n8n oder ein selbst gebautes Werkzeug. Das berühmte n×m-Integrationsproblem wird zu n+m.
Die Gemeinsamkeiten sind ebenso wichtig: Beides sind Schnittstellen für den Datenzugriff, beides transportiert nur, was das dahinterliegende System hergibt, und in der Praxis nutzt fast jeder MCP-Server im Hintergrund eine klassische API. MCP ersetzt APIs also nicht — es standardisiert die Schicht zwischen Modell und API. Neu gegenüber klassischen APIs ist vor allem die dynamische Tool-Discovery: Das Modell entdeckt zur Laufzeit, welche Werkzeuge verfügbar sind, statt gegen eine fest verdrahtete Spezifikation programmiert zu werden.
Für die Kanzleipraxis ist das bereits konkret. Es existieren erste MCP-Server, die über das DATEVconnect-Gateway lesend auf Mandanten, Buchungen, Belege und Lohndaten zugreifen, sowie lokale Varianten, die DATEV-Buchungsstapel im EXTF-Format direkt auf dem eigenen Rechner befragbar machen — die Daten verlassen dabei die Kanzleiumgebung nicht. Für ADDISON-Kanzleien führt ein anderer Weg zum selben Ziel: Der ADDISON DataCube exportiert Stamm-, Bewegungs- und Abschlussdaten mandanten- und bereichsübergreifend in eine SQL-Datenbank, die eigentlich für Power-BI-Auswertungen gedacht ist. Genau diese SQL-Datenbank lässt sich aber ebenso über einen (Standard-)MCP-Server für Datenbanken an ein Sprachmodell anbinden — inklusive des Benutzerberechtigungssystems, das den Zugriff auf Tabellenebene steuert. Der Effekt ist derselbe: Das Modell kann Fachdaten live und deterministisch abfragen.
Und genau hier beginnt das Problem.
Das Silo-Problem: Warum 13 Connectoren keinen Mandantenblick ergeben
Ein MCP-Server ist ein Transportweg, kein Wissensmodell. Er beantwortet die Frage, die man ihm stellt — aber er weiß nicht, welche Fragen man stellen müsste. Wenn eine Kanzlei dreizehn Connectoren betreibt (Fibu, Lohn, DMS, Steuersoftware, CRM, Zeiterfassung …), dann hat sie zur Laufzeit dreizehn Silos, die das Modell bei jeder einzelnen Anfrage selbst orchestrieren muss: pull-basiert, begrenzt durch das Kontextfenster, ohne Gedächtnis zwischen den Sitzungen, ohne Ranking über Quellen hinweg.
Was dabei strukturell fehlt, ist die Bedeutungsschicht: ein persistenter, semantischer Index, der weiß, dass die E-Mail von letzter Woche, das transkribierte Telefonat vom Dienstag, der Buchungsstapel im Fachsystem und der Entwurf der Steuererklärung alle denselben Sachverhalt beim selben Mandanten betreffen. Proaktive Muster — „dieser Mandant weicht beim Vorsteuervolumen deutlich vom Vorjahr ab, und im Schriftverkehr findet sich der Grund" — entstehen nicht dadurch, dass dreizehn Endpunkte abfragbar sind. Sie entstehen dadurch, dass jemand die Signale vorab verknüpft hat.
Microsoft Graph: das Datenmodell unter allem
Hier kommt die Microsoft-Seite ins Spiel, und zwar von unten nach oben. Die Basis ist Microsoft Graph: die einheitliche API und das darunterliegende Datenmodell für alles, was in einem Microsoft-365-Tenant passiert. Jede E-Mail in Exchange, jedes Dokument in SharePoint und OneDrive, jeder Teams-Chat, jedes Meeting-Transkript, jeder Kalendereintrag und — entscheidend — jede Beziehung zwischen diesen Objekten und den Personen, die mit ihnen arbeiten, ist im Graph repräsentiert. Der Graph ist kein Analysewerkzeug, sondern die Landkarte: Er weiß, was es gibt, wer darauf zugreifen darf und wie die Dinge zusammenhängen. Über Graph- bzw. Copilot-Connectoren lassen sich auch Nicht-Microsoft-Quellen in dieses Modell einspeisen, sodass externe Inhalte dieselbe Berechtigungs- und Compliance-Logik erben.
Semantic Index: von Stichworten zu Bedeutung
Auf dem Graph sitzt der Semantic Index. Während eine klassische Suche Stichworte abgleicht, bildet der semantische Index Inhalte als Bedeutungsvektoren ab: Er findet das Protokoll zur „Betriebsaufspaltung Meyer", auch wenn dort nur von „Verpachtung des Grundstücks an die Betriebs-GmbH" die Rede war. Microsoft beschreibt diese Komponente als Abruf nach Bedeutung statt nach Schlüsselwörtern — und genau das ist die Fähigkeit, die einem reinen MCP-Setup fehlt: Ein Connector kann nur beantworten, wonach explizit gefragt wird; ein semantischer Index findet, was gemeint ist. Wichtig für die Kanzlei: Der Index wird permissionsbasiert aufgebaut. Was eine Mitarbeiterin nicht sehen darf, findet sie auch semantisch nicht — Sensitivity Labels und Berechtigungen des Tenants gelten durchgängig.
Work IQ: die Bedeutungsschicht bekommt einen Namen
Work IQ ist Microsofts Antwort auf genau die Frage, die dieser Beitrag stellt. Auf der Ignite im November 2025 angekündigt und seit dem 16. Juni 2026 mit allgemein verfügbaren APIs versehen, ist Work IQ die Intelligenzschicht über Graph und Semantic Index. Microsoft beschreibt sie als das „Gehirn" hinter Copilot, das Kontext, Beziehungen und Arbeitsmuster versteht — aufgebaut aus drei Ebenen: Daten (die Signale aus Dateien, E-Mails, Meetings, Chats und angebundenen Geschäftssystemen), Kontext bzw. Memory (wer arbeitet mit wem woran, welche Projekte laufen, welche Präferenzen und Instruktionen gelten) und Skills & Tools (spezialisierte Fähigkeiten und Aktionen, die Copilot und Agenten ausführen können).
Im Blogbeitrag zur API-Verfügbarkeit formuliert Microsoft den Anspruch, Work IQ liefere „a real-time model of how your organization operates" — ein Echtzeitmodell dessen, wie die Organisation arbeitet, also Intelligenz, die aus den Rohdaten allein nicht zu gewinnen ist. Bemerkenswert ist dabei zweierlei. Erstens: Work IQ ist selbst per MCP ansprechbar. Microsoft stellt Work-IQ-MCP-Server bereit, über die auch eigene Agenten — etwa in Copilot Studio oder Foundry — auf diese Bedeutungsschicht zugreifen können. MCP und semantische Schicht sind also keine Gegensätze; Microsoft nutzt das Protokoll, um die Schicht zu exponieren. Zweitens: Microsoft grenzt sich in der eigenen Kommunikation ausdrücklich von Ansätzen ab, die allein auf Connectoren aufbauen — die Pointe ist, dass Kontextverständnis vorverarbeitet werden muss und nicht bei jeder Anfrage neu zusammengesucht werden kann.
Copilot Cowork: die Schicht bekommt Hände
Mit Copilot Cowork — seit dem 16. Juni 2026 allgemein verfügbar — kommt die Handlungsebene hinzu. Cowork ist ein agentisches System: Man beschreibt ein Ergebnis, und das System plant die Schritte, arbeitet über Anwendungen und Dateien hinweg, läuft cloudseitig auch bei zugeklapptem Laptop weiter und legt Zwischenstände zur Freigabe vor. Technisch bemerkenswert: Microsoft hat dafür in enger Zusammenarbeit mit Anthropic die Technologie hinter Claude Cowork in Microsoft 365 integriert — Multi-Model-Architektur inklusive, mit Claude- und GPT-Modellen je nach Aufgabe. Cowork gründet dabei vollständig auf Work IQ: Der Agent muss nicht mit Kontext gefüttert werden, er hat ihn. Und er operiert innerhalb der bestehenden Governance — Sensitivity Labels, Audit-Logging, eDiscovery und Purview-Kontrollen gelten für Cowork-Interaktionen genauso wie für den Rest des Tenants; sensible Aktionen wie der Versand einer E-Mail pausieren für die menschliche Freigabe.
Für die Kanzlei heißt das im Zusammenspiel: Graph ist die Landkarte, der Semantic Index das Auffinden nach Bedeutung, Work IQ das Verständnis von Zusammenhängen und Mustern, Cowork die delegierbare Ausführung. Jede Ebene setzt die darunterliegende voraus.
Die eigentliche Konsequenz: Datenhaltung ist die strategische Entscheidung
Wenn die Bedeutungsschicht nur das indexieren kann, was im Tenant liegt oder sauber angebunden ist, dann wird die Frage, wo Daten gehalten werden, zur eigentlichen KI-Strategieentscheidung der Kanzlei. Der Gesamtblick auf den Mandanten entsteht nur, wenn wirklich alle Signalarten zusammenfließen:
Transkribierte Telefonate und Meetings. Wer Mandantengespräche in Teams führt (oder Telefonate über Teams Telephony bzw. angebundene Lösungen transkribiert), erhält Transkripte, die automatisch im Graph liegen und von Work IQ mitverstanden werden. Der Anruf, in dem der Mandant die geplante Anteilsübertragung erwähnt, wird damit Teil des Mandantenkontexts — nicht eine Datei, die in einem Telefonanlagen-Portal versauert.
Erzeugte Arbeitsergebnisse. Steuererklärungen, Jahresabschlüsse, BP-Korrespondenz und Gutachten, die im Fachsystem erzeugt werden, sollten als PDF bzw. Dokument strukturiert in die mandantenbezogene SharePoint-Ablage zurückfließen. Das Fachsystem bleibt führend für die Erstellung — aber das Ergebnis muss dort liegen, wo die Bedeutungsschicht es sieht.
Die interne Kommunikation. Der vielleicht meistunterschätzte Datenschatz: das Mitarbeitergespräch untereinander. „Bei Mandant X bitte auf die 15a-Verluste achten, das hatten wir letztes Jahr." Dieser Teams-Chat ist gelebtes Kanzleiwissen. In Messenger-Insellösungen ist er für jede KI verloren; in Teams ist er Teil des Index, selbstverständlich berechtigungsgetrimmt.
E-Mails. In Exchange Online ohnehin im Graph — vorausgesetzt, die Kanzlei archiviert nicht in Systeme hinein, die den Mandantenbezug abschneiden.
Das Mandantenportal. Hier lohnt eine bewusste Architekturentscheidung: Ein Portal, das als externe Web-Anwendung mit eigener Datenbank läuft, ist für die Bedeutungsschicht bestenfalls eine weitere externe Quelle, die per Connector angebunden werden muss — mit allen Latenzen und Verlusten. Baut man das Portal dagegen auf SharePoint auf (etwa über extern freigegebene, mandantenbezogene Bereiche mit Entra External ID), dann ist jeder vom Mandanten hochgeladene Beleg, jede geteilte Unterlage nativ Teil des Tenants: sofort indexiert, sofort im Berechtigungsmodell, sofort Teil des Mandantenblicks — ohne Synchronisation, ohne Doppelhaltung und ohne die Frage, welche Kopie führend ist.
Und die Fachdaten? Hybrid ist die Antwort
Bedeutet das, alle Buchhaltungsdaten nach Microsoft 365 zu replizieren? Nein — und das ist der Punkt, an dem die MCP-Kritiker wieder Recht bekommen. Transaktionale Fachdaten will man live und deterministisch abfragen, nicht aus einem Index approximieren, der gestern synchronisiert wurde. Einen UStVA-Status, einen Kontensaldo oder offene Posten fragt man im Moment der Anfrage im führenden System ab — per MCP-Server auf DATEVconnect, per Anbindung an die DataCube-SQL-Datenbank oder künftig direkt über die Schnittstellen der Fachverlage. GoBD-seitig bleibt das Fachsystem ohnehin das führende, unveränderbar archivierende System; die semantische Schicht ist Auswertungs-, nie Aufbewahrungsebene.
Die tragfähige Architektur für die Kanzlei ist damit dreistufig: Erstens die semantische Schicht im Tenant für alles Unstrukturierte — Korrespondenz, Gespräche, Dokumente, Portal-Uploads und internes Wissen. Zweitens MCP-Zugriffe auf die Fachsysteme für alles Transaktionale — live, lesend und feingranular berechtigt. Drittens eine Agentenschicht darüber — Cowork oder eigene Agenten über Work IQ MCP —, die beide Welten in einer Aufgabe verbindet: „Bereite das Jahresgespräch mit Mandant Y vor" heißt dann: Zahlen live aus dem Fachsystem, Kontext aus einem Jahr Korrespondenz, Transkripten und Notizen sowie den Entwurf als Dokument in der Mandantenablage.
Governance nicht vergessen: § 203 StGB, DSGVO und die Grenzen des Index
Für Berufsgeheimnisträger ist die Konsolidierung im Tenant kein Selbstläufer. Wer Mandantendaten systematisch in Microsoft 365 zusammenführt und von einer Intelligenzschicht verarbeiten lässt, braucht das vertragliche Fundament — § 203 StGB-konforme Zusatzvereinbarungen und Auftragsverarbeitungsverträge mit Microsoft, saubere Subprozessor-Transparenz sowie die EU Data Boundary im Blick — und das technische Fundament: konsequente Sensitivity Labels, ein gepflegtes Berechtigungsmodell und Microsoft Purview-Kontrollen.
Denn die Bedeutungsschicht macht Datenbeziehungen sichtbar, die vorher niemand gesucht hat. Ein vergessenes Sensitivity Label oder eine zu weit freigegebene Dokumentbibliothek wird durch KI nicht gefährlicher — aber deutlich schneller auffindbar. Microsoft berichtet aus dem eigenen Rollout, dass solche Erkenntnisse regelmäßig kein Work-IQ-Problem waren, sondern ein Governance-Signal: Die KI honorierte exakt die Berechtigungen, die ihr gegeben wurden. Vor dem semantischen Index kommt deshalb die Datenhygiene.
Fazit
MCP ist ein wichtiger, offener Baustein. Als Standard für den Live-Zugriff auf Fachsysteme wie DATEV oder die ADDISON-Datenwelt ist er der richtige Weg, und dass Microsoft selbst Work IQ per MCP exponiert, zeigt, dass Protokoll und Plattform keine Gegner sind.
Aber ein Protokoll erzeugt keine Bedeutung. Den Gesamtblick auf den Mandanten liefert erst eine semantische Schicht, die alle Signale — Zahlen, Sprache, Dokumente und Gespräche — dauerhaft miteinander verknüpft, sowie eine Agentenschicht, die darauf handeln kann.
Für Kanzleien im Microsoft-Ökosystem bedeutet das konkret: Unstrukturierte Daten konsequent in den Tenant bringen, wo immer Mandantenwissen entsteht – bis hin zum Mandantenportal auf SharePoint statt als separates System. Gleichzeitig sollten transaktionale Fachdaten weiterhin live über MCP angebunden und nicht repliziert werden. Und schließlich muss die Governance mit derselben Priorität behandelt werden wie die technische Architektur.
Modelle kommen und gehen. Was bleibt, ist nicht irgendein Connector. Was bleibt, ist die Bedeutungsschicht über den eigenen Daten — und diese sollte in der Hoheit der Kanzlei liegen.
Quellen und weiterführende Informationen
- Microsoft Tech Community: A closer look at Work IQ (2026)
- Microsoft 365 Blog: Announcing the new Work IQ APIs (Juni 2026)
- Microsoft 365 Blog: Copilot Cowork: A new way of getting work done (März 2026)
- Microsoft Learn: Work IQ MCP Overview
- Microsoft Inside Track: Intelligence on Tap – How Work IQ enables AI and agents at Microsoft
- Wolters Kluwer: Produktdokumentation ADDISON DataCube
- Model Context Protocol (Linux Foundation): Spezifikation
