METXMEEine Verwalter-Crew in Hamburg verbrachte den März damit, ihren ersten KI-gestützten Workflow zu bauen: Mietvertrag im PDF rein, strukturierte Zusammenfassung als Markdown raus, Eintrag in Notion, Verknüpfung mit dem CAFM-System für die Vertragsfrist-Listen. Vier Wochen später war der Workflow fertig. Drei Wochen davon waren weg, weil zwei Java-Konnektoren, ein Python-Skript und ein eigenes API-Wrapper-Layer geschrieben wurden — alles, um Claude an Notion zu koppeln, an die Postgres-Datenbank im CAFM und an den Datei-Server. Jeder dieser Konnektoren war eine eigene Baustelle, jeder hatte eine eigene Authentifizierung, jeder brachte ein eigenes Wartungsproblem mit.
Im April lief die gleiche Crew auf MCP um. Drei Tage Arbeit, ein Konfig-File, vier MCP-Server: filesystem für die PDFs, postgres für das CAFM, notion für die Wissensablage, microsoft-teams für die Mitarbeiter-Kommunikation. Der Workflow war derselbe. Die Wartung schrumpfte auf nahezu null. Das ist die typische MCP-Erfahrung 2026 — und sie ist das, was den Begriff in den nächsten Monaten in jedem zweiten Verwalter-Backoffice landen lässt.
Was Model Context Protocol konkret tut
MCP ist ein offener Standard. Anthropic hat ihn Ende 2024 vorgestellt, die Spezifikation liegt frei auf GitHub, und große Anbieter — OpenAI, Google, Atlassian, Notion, Asana, Box — haben ihre eigenen MCP-Server entweder selbst gebaut oder durch die Community pflegen lassen. Der Kerngedanke: ein Sprachmodell ist nur so nützlich, wie der Kontext, mit dem es arbeitet. Wer Claude in einem Browser-Tab nutzt, hat Zugriff auf den eigenen Text und vielleicht eine Datei, die hochgeladen wurde — aber nicht auf das eigene Mietverwaltungs-System, das eigene Notion-Wiki, die eigene Outlook-Mailbox oder die eigene Postgres-Datenbank.
MCP schließt diese Lücke. Ein MCP-Server ist ein kleines Programm, das auf der eigenen Maschine oder auf einem internen Server läuft und Claude einen geprüften Zugriff auf eine bestimmte Datenquelle gibt — nicht „alles was du willst", sondern definierte Werkzeuge mit definierten Parametern. Der filesystem-Server gibt zum Beispiel drei Werkzeuge frei: Lesen einer Datei, Schreiben einer Datei, Auflisten eines Verzeichnisses. Der postgres-Server erlaubt SELECT-Queries gegen eine konfigurierte Datenbank — Schreibzugriff ist optional und meist deaktiviert. Der notion-Server kann Seiten lesen und schreiben, mit explizitem Token-Scope.
Das Ergebnis: Claude bekommt durch MCP Zugriff auf reale Geschäftsdaten, ohne dass man eine eigene Integrations-Schicht baut. Und MCP bleibt dabei quelloffen — wer den Server stoppen will, stoppt das Programm. Wer den Anbieter wechselt, behält die Server. Kein Vendor-Lock-In auf der Daten-Ebene.
Warum das im Mittelstand wichtiger ist als in Konzernen
Konzerne haben IT-Abteilungen, die jeden Datenfluss durch interne Architekturen leiten. Mittelständische Verwaltungen haben das nicht — sie haben drei IT-affine Sachbearbeiter:innen, einen externen Dienstleister und einen kleinen Server-Schrank im Keller. Genau für diese Konstellation ist MCP gemacht: ein Werkzeug pro Quelle, ein Konfig-File, ein Programm, das im Hintergrund läuft. Keine Integrations-Plattform, keine Middleware, keine Cloud-Abhängigkeit — solange die Server lokal oder in der eigenen EU-Region laufen.
Die MCP-Server-Katalog-Sektion in der Community macht genau diese Auswahl explizit: fünfzehn Server, kategorisiert nach Zweck (Dateien, Wissen, Kommunikation, Ticket, Kalender, Datenbank, Web). Jede Karte zeigt das Datenraum-Badge — lokal (läuft auf eigener Hardware), EU (europäischer Datenraum), US (US-Datenraum, AVV erforderlich), gemischt (abhängig von Konfiguration). Dazu eine Daten-Klassifizierung — C2 intern, C3 vertraulich, C4 streng vertraulich — als Diskussionsgrundlage für den eigenen Datenschutzbeauftragten.
Die fünfzehn Server in der Reihenfolge der praktischen Bedeutung
Drei Server sind für fast jede Verwaltungs-Crew relevant.
filesystem — der Anthropic-Referenz-Server für lokale Dateien. Liest und schreibt in einem konfigurierten Wurzelordner. Praxis: Übergabeprotokolle, Begehungsfotos, Standard-Vorlagen, ausgehende Korrespondenz. Datenraum lokal, Klasse C2. Wer einen geteilten Order-Pfad hat (SMB-Mount, lokales Synology, Nextcloud-Sync), gibt Claude damit den Zugriff auf das Tagesgeschäft.
memory — persistenter Wissensgraph für Claude. Personen, Objekte, Beziehungen werden über mehrere Sessions hinweg merkbar. Praxis: Bestandsmieter, Eigentümer-Zuordnungen, Vertragsstände. Vor allem ein Effizienz-Hebel: wer Claude zwölfmal am Tag den gleichen Hintergrund mitschicken muss, spart durch das Memory-Modul Tokens und mentale Energie.
fetch — holt Inhalt von URLs und konvertiert ihn in lesbares Markdown. Praxis: öffentliche Mietspiegel, Behörden-Bekanntmachungen, Anbieter-Dokumente. Datenraum gemischt — die Quelle bestimmt, wo die Daten liegen. Wer im Verwalter-Alltag öffentliche Quellen abfragt, ohne Claude direkt ins Browser-Tab zu lassen, nimmt diesen Server.
Drei Server für die Datenbank- und Wissens-Anbindung.
postgres — liest aus PostgreSQL-Datenbanken. Standard nur lesend, schreibend bewusst nicht aktiviert (wer das ändern will, kann das in der Konfiguration). Klasse C3. Praxis: produktive CAFM-Datenbank, Mietverwaltungs-Tabellen, Wartungs-Protokolle. Erste Use-Cases: „zeige alle Wartungen, die in den nächsten 30 Tagen fällig sind", „liste die Eigentümer, die Hausgeld rückständig haben". Mit Caching-Disziplin extrem effizient.
sqlite — die kleine Schwester für Teams ohne Postgres-Infrastruktur. Liest aus einer SQLite-Datei. Klasse C2. Wer strukturierte Daten in einer Datei pflegt — Wartungslisten, Geräte-Inventare, kleine Mieter-Listen — kommt hier aus.
memory (oben schon erwähnt) — wenn man's einmal ausprobiert hat, kommt man nicht wieder zurück. Es ist die Brücke zwischen einzelnen Anfragen und kontinuierlicher Arbeit.
Drei Server für die Kommunikation.
microsoft-teams — der Community-gepflegte Server für Microsoft Teams. Liest Channel-Beiträge und Chat-Threads, schreibt mit Berechtigung. Datenraum EU (wenn die Teams-Tenant-Region das vorgibt), Klasse C3. Für die meisten deutschen Mittelständler die realistischere Variante als Slack — Microsoft 365 dominiert.
slack — Anthropic-Referenz-Server für Slack. Liest und schreibt in Slack-Kanälen. US-Datenraum, Klasse C3. Wer einen #facility-Kanal hat, in dem Auffälligkeiten gepostet werden, hat damit eine zweite Brücke ins operative Tagesgeschäft.
gmail / outlook — die E-Mail-Anbindungen werden gerade aktiv ausgebaut, Stand Mai 2026 sind sie als Community-Server noch im Reife-Prozess. Wer auf E-Mail-Anbindung wartet, hat noch ein bis zwei Quartale.
Drei Server für Wissen und Tickets.
notion — offizieller Notion-Server. Workspaces lesen und beschreiben. Praxis: hausinternes Wiki, Vorlagen-Sammlung, Onboarding-Material. Datenraum US, Klasse C3. Wer in Notion arbeitet, hat damit Claude als Wissensvermittler im selben System.
atlassian — offizieller Atlassian-Server für Jira und Confluence. Tickets lesen, Felder ändern, Confluence-Seiten lesen. Datenraum EU (Atlassian Cloud Frankfurt), Klasse C3. Für größere Verwaltungen mit eigener IT-Crew der natürliche Anlaufpunkt.
asana — offiziell. Aufgaben anlegen, Status setzen, Projekte und Portfolios lesen. US-Datenraum. Verwaltungen mit Projekt-Charakter — Sanierungsmaßnahmen, Eigentümerversammlungen, größere Vergaben — kommen damit weit.
Drei spezielle Server.
github — Pull Requests, Issues, Code-Files lesen und kommentieren. Für die hauseigene Software-Crew. Im klassischen FM nur relevant, wenn ihr eigene Tools betreut.
box — Box-Speicher lesen und beschreiben. Datenschutz-freundlicher als US-Cloud-Standard, mit EU-Hosting-Option. Mittelstand mit gehobenen Compliance-Anforderungen, der Box als Vertrags-Ablage nutzt.
puppeteer — steuert Headless-Browser, klickt durch öffentliche Seiten. Praxis: regelmäßiges Abholen von Bekanntmachungen, Marktdaten. Eher technisch als Verwaltungs-affin.
Wie die Datenraum-Klassifizierung in der Praxis greift
Drei Faustregeln, die sich in der Verwaltungs-Praxis bewährt haben.
Klasse C2 (intern) — geht problemlos auf lokale MCP-Server (filesystem, sqlite, memory). Im Zweifel auch auf EU-gehostete Server (Atlassian Cloud Frankfurt, Vertex AI europe-west). US-Server nur dann, wenn keine personenbezogenen Daten oder Geschäftsgeheimnisse im Datenfluss sind.
Klasse C3 (vertraulich) — bevorzugt lokal oder EU. US-Server nur mit AVV und ausdrücklichem Trainingsausschluss. Pseudonymisierung in den Quelldaten ist Best Practice.
Klasse C4 (streng vertraulich) — nur lokal oder eigen-gehostet. Hier ist auch das Modell selbst ein Thema: Open-Weight-Hosting (Llama, Mistral) auf eigener Hardware oder über Together-AI Frankfurt ist die Variante, die sich für Mandantengeheimnisse, Steuerdaten oder hochsensible Personalakten anbietet.
Der DSGVO-Schnellcheck in der Community durchläuft die acht Fragen, die hier zu klären sind, in zehn Minuten — von „Werden personenbezogene Daten verarbeitet" bis „Ist eine Datenschutz-Folgenabschätzung erstellt".
Wie der Einstieg konkret läuft
Drei Schritte, die in praktisch jeder Verwaltung funktionieren.
Schritt eins — Inventar. Vor dem ersten Server-Setup: ein einseitiges Inventar dessen, was angeschlossen werden soll. Welche Datenquellen, welche Klasse (C2/C3/C4), welcher Eigentümer im Haus, welche AVV-Lage. Der MCP-Inventar-Vorlage in der Community ist genau dafür gebaut — Markdown-Tabelle mit Pflichtangaben pro Server, halbjährliche Re-Prüfung als Standard. Eine Stunde Aufwand für die Vorlage, dann liegt das Inventar im Wiki.
Schritt zwei — der erste Server. Fast immer filesystem. Konfiguration in der Claude-Desktop-Konfig oder in Claude Code als MCP-Eintrag, Wurzelpfad auf einen geteilten Order — etwa den hauseigenen Vorlagen-Ordner. Sofort spürbar: Claude kann die hauseigenen Standard-Mails als Vorlage nehmen, ohne dass man sie jedes Mal in den Chat kopieren muss.
Schritt drei — Datenbank- oder Wissens-Anbindung. Je nach Stack: postgres für CAFM-Datenbanken, notion für Wissens-Wikis, atlassian für Confluence-Häuser. Ab hier wird MCP zum operativen Hebel — die Anfragen wandern weg von „kopiere mir den Text aus dem CAFM" hin zu „prüfe die Wartungs-Fälligkeiten für den nächsten Monat und schreibe den Auftraggeber-Brief, falls ein Sammeleinsatz nötig ist".
Der typische Stolperstein im Mittelstand
Drei Beobachtungen aus realen Setups.
Erstens — Authentifizierung. Viele MCP-Server brauchen ein eigenes Token oder einen OAuth-Flow. Wer das im Haus nicht zentral organisiert (etwa über ein internes 1Password / Bitwarden), endet mit einem Wildwuchs aus persönlichen Tokens, der bei der nächsten Mitarbeiter-Wechsel-Welle zum Problem wird.
Zweitens — Berechtigungs-Klemme. Der erste Reflex ist, dem Server möglichst viel Lese-Recht zu geben. Das ist riskant. Bessere Praxis: minimalste Schreib-Rechte, lieber zwei Server (Lese-Server und Schreib-Server) als ein All-in-One. Die Sicherheits-Checkliste in der Community führt das in fünfundzwanzig Punkten durch.
Drittens — Versionierung. MCP-Server bekommen Updates. Wer drei Monate später nicht weiß, mit welcher Version er gestartet hat, hat ein Audit-Problem. Lösung: Server-Versionen im MCP-Inventar mitführen, Updates in einem dokumentierten Rhythmus (etwa monatlich) einspielen, nicht spontan.
Was die Community konkret hilft
Drei Sektionen in der natürlichen Reihenfolge:
Die MCP-Glossar-Erklärung (im Eintrag „MCP") gibt die zehn-Sekunden-Antwort. Wer schon weiß, was MCP ist, springt direkt zum nächsten Punkt.
Die MCP-Konfig-Generator-Sektion erstellt aus drei Eingabefeldern einen ersten Konfig-Block für Claude Desktop oder Claude Code. Schnellster Einstieg.
Der MCP-Server-Katalog ist die strategische Auswahl: fünfzehn Server kategorisiert nach Zweck, Datenraum, Klasse, mit „Passt, wenn …"-Block pro Server. Wer hier eine Stunde verbringt, hat eine fundierte Vorstellung, welche drei bis fünf Server in den nächsten Wochen die größte Wirkung entfalten.
MCP ist 2026 das stille Werkzeug, das aus Claude einen Verwaltungs-Kollegen macht, statt nur einen Browser-Tab. Wer es verstanden hat, hat eine der wichtigsten Architekturentscheidungen für die nächsten zwei bis drei Jahre getroffen — bevor der Markt sich an einen einzelnen Anbieter klemmt.