Operationen

Die zehn MCP-Tools im Detail: was jedes einzelne liest — und was bewusst nicht zurückgegeben wird.

Alle zehn Tools sind als ReadOnly = true, Idempotent = true und Destructive = false markiert (MCP-Tool-Annotationen, die dem aufrufenden Client mitgeben, dass wiederholte Aufrufe risikolos sind). Kein Tool schreibt, löscht oder sendet — weder in der jobs-/mappings-Tabelle, noch in den Service-Bus-Queues, noch in einem Quell-/Zielsystem.

Grenze ist Metadaten vs. Nutzdaten, nicht nur lesend vs. schreibend

Auch innerhalb der reinen Lesezugriffe gibt es eine bewusste zweite Grenze: Betriebs-/ Konfigurationsdaten (Job-Namen, Schemata, Fehlermeldungen, Zeitstempel) sind unkritisch und werden vollständig zurückgegeben. Fachliche Nutz-/Kundendaten — z. B. der Inhalt einer Service-Bus-Nachricht — werden dagegen nie zurückgegeben, selbst wenn das zugrunde liegende Tool ansonsten “nur liest”. Details dazu unten bei den Peek-Tools.

Jobs & Mappings (Table Storage)

Lesen ausschließlich aus den beiden Tabellen jobs/mappings, über dieselben In-Memory-Caches wie JobApi/MappingApi (IJobService.Jobs/IMappingService.Mappings — reine Query<T>()-Reads, kein Upsert/Delete im Codepfad).

Tool	Liest	Liest nicht
`list_jobs`	Alle konfigurierten Jobs: Quelle/Ziel-Connection, Richtung, Priorität, Zeitplan, Mapping-Name, aus der `jobs`-Tabelle	Keine Connection-Credentials (nur der Name der Connection, nicht ihre Zugangsdaten)
`get_job`	Ein einzelner Job anhand seines `RowKey` (Job-Name) — dieselben Felder wie `list_jobs`	dito
`list_mappings`	Alle Feld-Mappings zwischen Quell- und Zielsystemen aus der `mappings`-Tabelle	Keine tatsächlichen Datensatz-Inhalte — nur die Mapping-Konfiguration (welches Feld auf welches Feld abgebildet wird), nicht produzierte/synchronisierte Daten
`get_mapping`	Ein einzelnes Mapping anhand seines `RowKey`	dito

Warum keine Credentials möglich sind: IConnectionService.GetConnector(name) liefert nur die IConnector-Instanz zurück, nicht das zugrunde liegende ConnectionSetting-Objekt. Felder wie ClientSecret, Password oder ApiKeyValue sind private Felder in den konkreten Connectoren und nicht Teil des IConnector-Interfaces — es gibt schlicht keinen Rückgabewert, über den sie herauskommen könnten.

Service Bus (Diagnose)

Reine Peek-/Status-Operationen über IServiceBusService. Die beiden Peek-Tools erzeugen den Empfänger ohne PeekLock und rufen ausschließlich receiver.PeekMessagesAsync(...) auf — es gibt im Codepfad kein ReceiveMessagesAsync, CompleteMessageAsync, DeadLetterMessageAsync oder AbandonMessageAsync. Auch SendMessageAsync (existiert auf IServiceBusService für GetChanges) ist von keinem MCP-Tool aus erreichbar.

Tool	Liest	Liest nicht
`list_queue_statuses`	Laufzeit-Status (aktive/dead-letter/geplante Nachrichtenanzahl) aller Export-Queues	Keine einzelnen Nachrichten — nur Zähler
`get_queue_status`	Laufzeit-Status einer einzelnen Queue für eine Job-Priorität	dito
`peek_queue_messages`	Sequenznummer, JobName, SourceKey, Enqueue-Zeitpunkt, Zustellversuche und `BodySize` (Größe des Nachrichteninhalts in Bytes) je Nachricht	Den Nachrichteninhalt selbst (`Body`) nicht — siehe Kasten unten
`peek_dead_letter_queue_messages`	Zusätzlich zu den obigen Feldern: DeadLetterReason, DeadLetterErrorDescription, ErrorMessage, ErrorTimeStamp, ErrorStackTrace, OperationId	dito — auch hier nur `BodySize`, nie `Body`

Warum kein Nachrichteninhalt

Der Body einer Queue-Nachricht enthält die fachlichen Nutzdaten des jeweiligen Jobs — z. B. bei einem BC-Artikelstamm-Job Produktcode, Bezeichnung und Dimensionswerte, bei anderen Jobs unter Umständen Kundennamen, Adressen oder Preise. Das ist etwas grundlegend anderes als Betriebsmetadaten wie ein Fehlertext oder ein Zeitstempel. Beide Peek-Tools geben deshalb bewusst nie den Nachrichteninhalt zurück — nur dessen Größe in Bytes (BodySize), berechnet über message.Body.ToMemory().Length, ohne den Inhalt jemals zu deserialisieren oder als String zu lesen. Für die Fehleranalyse reichen die übrigen Felder (insbesondere bei peek_dead_letter_queue_messages die Fehlerdetails) in aller Regel aus.

Connector-Metadaten (echtes Ziel-/Quellsystem-Schema)

Tool	Liest	Liest nicht
`list_connector_tables`	Tabellen-/Entitätsnamen einer Connection direkt aus den Metadaten des Zielsystems — zum Abgleich mit den in Jobs/Mappings konfigurierten Namen	Keine tatsächlichen Datensätze aus der Tabelle — nur ihren Namen
`get_connector_table_schema`	Spalten-Metadaten (Typ, Nullable, maximale Länge, Primary Key) einer Tabelle/Entität — zum Validieren eines Mappings gegen das tatsächliche Schema, statt sich auf die Mapping-Konfiguration allein zu verlassen	Keine tatsächlichen Datensätze/Zeilenwerte — nur die Spalten-Struktur

Beide Tools nehmen einen connectionName entgegen (den RowKey aus der connections-Tabelle — siehe Verbindungen, z. B. BC_Test oder CRM_Test) sowie einen tableName/Ressourcennamen. Für BC/NAV ist zusätzlich der apiPath erforderlich (derselbe Wert wie TableMapping.SourcePath/TargetPath im Mapping), da beide Connectoren ihr Schema über einen versionierten OData-$metadata-Endpunkt beziehen.

Diese beiden Tools sind die einzigen mit OpenWorld = true — sie greifen tatsächlich auf das externe Quell-/Zielsystem der jeweiligen Connection zu, nicht nur auf die eigene DataBridge-Infrastruktur. Ungültige Connection-Namen liefern eine klare ArgumentException („Connection ‘…’ is not configured or not initialized") statt einer rohen KeyNotFoundException — es lässt sich also nicht durch Ausprobieren beliebiger Namen etwas über das System herausfinden, das über list_jobs/get_job nicht sowieso schon sichtbar wäre.

Connector-Unterstützung

list_connector_tables/get_connector_table_schema funktionieren aktuell für D365BC, D365NAV, D365CE (Dataverse) und OpenAPI. Für die SQL-Connectoren (MSSQL, MySQL, Oracle, PostgreSQL) ist das noch nicht implementiert — der Aufruf schlägt dort mit einer Fehlermeldung fehl (GetTableMetadata is not implemented for connector '...'). Der Rückgabewert ist je Connector unterschiedlich vollständig, da nicht jedes System dieselbe Metadaten-Tiefe bietet:

Connector	Typ	Nullable	Max. Länge	Primary Key
D365BC / D365NAV	✅	✅	✅ (nur Strings)	✅
D365CE (Dataverse)	✅	✅	✅ (nur Strings)	✅
OpenAPI	✅	✅	✅ (falls `maxLength` im Schema)	❌ (kein natives Konzept — immer `null`)

Zusammenfassung: was über MCP grundsätzlich nicht möglich ist

Keine Schreib-, Lösch- oder Sende-Operation auf jobs/mappings/Service-Bus-Queues oder einem Ziel-/Quellsystem — es gibt für keines der zehn Tools einen Codepfad zu Upsert, Delete, SendMessageAsync, CompleteMessageAsync o. Ä.
Keine Connection-Credentials (Passwörter, Client-Secrets, API-Keys) — die sind strukturell nie Teil eines Rückgabewerts.
Kein tatsächlicher Nachrichteninhalt aus einer Service-Bus-Queue — nur dessen Byte-Größe.
Keine tatsächlichen Datensatz-Werte aus einem Ziel-/Quellsystem über die Connector-Tools — nur Tabellennamen und Spalten-Struktur, keine Zeilen.