Warum Tools statt einer API-Dokumentation
Ein Sprachmodell mit einer rohen API-Dokumentation auszustatten und auf das Beste zu hoffen, ist fehleranfällig. Das Model Context Protocol dreht das um: Der MCP-Server definiert eine Menge klar beschriebener Tools — jedes mit Namen, Zweck und Eingabe-Schema. Der KI-Client liest diese Tools beim Verbinden ein und entscheidet pro Anfrage, welches Tool mit welchen Parametern aufzurufen ist. Die Reichweite eines Agenten ist damit exakt das, was der Server freigibt — nicht mehr und nicht weniger.
Für die Immobilienverwaltung ist das die entscheidende Eigenschaft. „Welche offenen Aufgaben gibt es zu Objekt 1000?" wird zum Aufruf von aufgaben_auflisten mit Objekt- und Status-Filter; „Liste alle Wohnungen mit Leerstand" zu einheiten_auflisten. Der Verwalter formuliert die Absicht, der Client übersetzt sie in geprüfte Tool-Aufrufe.
Workflow statt CRUD
Die meisten Schnittstellen behandeln Status als Datenfeld. ImmoGenio nicht: Kündigung, Beschlussfassung und die Durchführung einer Versammlung sind endliche Zustandsmaschinen in der GenioFlow-Engine. Der MCP-Server bildet das ab. Zuerst fragt der Agent über *_workflow_status, welche Aktionen überhaupt erlaubt sind und welches Payload-Schema sie benötigen; dann führt er über *_workflow_transition genau eine davon aus — über den offiziellen Pfad, ohne Umgehung der Vorbedingungen.
Ein Beschluss wandert so von vorgeschlagen über die Aufnahme in eine Versammlung zur Abstimmung; beim Annehmen werden Ja-Stimmen, Nein-Stimmen und Enthaltungen als Payload übergeben und atomar gespeichert. Eine eingehende Kündigung wird über das Ereignis kuendigung_eingegangen in den Lebenszyklus überführt, statt nur ein Feld zu setzen. Guards, Side-Effects und der unveränderliche Audit-Trail greifen identisch zum Portal.
Sicherheit in der API, nicht im Modell
Eine Schnittstelle, die einem Sprachmodell Zugriff auf Verwaltungsdaten gibt, muss bei der Datenschutz-Frage überzeugen — durch Erzwingung, nicht durch Vertrauen. Ein Lauf des Servers nutzt genau ein Partner-API-Token, das Mandant und Scopes bestimmt. Personenbezogene Daten sind abgestuft: Der Basis-Scope liefert nur Identifikation, Kontaktdaten erfordern einen separaten ReadPII-Scope, Bank- und Steuerdaten werden nie exponiert. Die Mandantentrennung erzwingt PostgreSQL über Row-Level-Security; ein falsches Token sieht schlicht keine fremden Daten. Die erste Version ist bewusst single-tenant — ein Token, ein Mandant.