Funktionsweise
Wie der MCP-Server technisch aufgebaut ist: Endpunkt, Transport, Authentifizierung, interner Aufbau und eine bekannte Einschränkung.
Die dsyr.DataBridge unterstützt das Model Context Protocol (MCP)
— den offenen Standard, über den KI-Assistenten strukturiert auf externe Systeme zugreifen. Ein
eingebauter, read-only MCP-Server macht dieselben Daten, die auch über die HTTP-APIs
(GetJobByRowKey, GetMappingByRowKey) verfügbar sind, sowie die Service-Bus-Queue-Diagnose
zusätzlich als MCP-Tools ansprechbar — sodass ein KI-Assistent (Claude Code, GitHub Copilot,
Microsoft 365 Copilot, …) direkt gegen eine laufende DataBridge-Instanz Fragen stellen kann, statt
Tabellen manuell in Azure Storage Explorer oder per REST-Aufruf durchzusehen.
Kein Tool verändert, löscht oder sendet irgendetwas. Der Server eignet sich zum Nachschlagen, Validieren und Debuggen — nicht zum Auslösen von Jobs oder Schreiben in Zielsysteme. Was genau jedes einzelne Tool lesen darf (und was bewusst nicht zurückgegeben wird, z. B. Nachrichten- inhalte oder Connection-Credentials), steht auf der Unterseite Operationen.
| Function | Mcp (DataBridge/Functions/McpApi.cs) |
| Route | POST /api/mcp (JSON-RPC-Austausch über Streamable HTTP) |
| Auth-Level | Function (Function Key als ?code=-Query-Parameter) |
| Tools | 10 — Jobs & Mappings, Service-Bus-Diagnose, Connector-Schema (siehe Operationen) |
| Schreibzugriff | Keiner — alle Tools sind read-only, siehe Operationen |
Der Server ist damit direkt an einer laufenden Function App (lokal oder in Azure) ansprechbar, ohne eigenen Prozess oder zusätzliche Infrastruktur.
Wie der MCP-Server technisch aufgebaut ist: Endpunkt, Transport, Authentifizierung, interner Aufbau und eine bekannte Einschränkung.
Die zehn MCP-Tools im Detail: was jedes einzelne liest — und was bewusst nicht zurückgegeben wird.
Den MCP-Server mit Claude Code, GitHub Copilot (VS Code) oder Microsoft 365 Copilot verbinden.