MCP für die Testumgebung

Die DataBridge in der Podman-Testumgebung bringt denselben MCP-Server mit wie jede andere Instanz. Damit kann ein KI-Assistent die Beispiel-Jobs und -Mappings lesen und die Metadaten der Testdatenbanken abfragen, ohne dass dafür etwas in Azure laufen muss.

Zwei Server nebeneinander

Die .mcp.json im Repository definiert zwei DataBridge-Server:

{
  "mcpServers": {
    "databridge": {
      "type": "http",
      "url": "${DATABRIDGE_MCP_URL:-http://localhost:7062}/api/mcp?code=${DATABRIDGE_FUNCTION_KEY:-local}"
    },
    "databridge-dev": {
      "type": "http",
      "url": "http://localhost:7062/api/mcp?code=local"
    }
  }
}

• databridge zeigt auf eine Azure-Instanz, sobald DATABRIDGE_MCP_URL und DATABRIDGE_FUNCTION_KEY gesetzt sind — üblicherweise im Block env der persönlichen .claude/settings.local.json (siehe MCP-Server → Nutzung).
• databridge-dev zeigt immer auf die Testumgebung. Der Function Key ist dort fest auf local gesetzt (dev/functions-secrets/host.json), es muss also nichts konfiguriert werden.

In Claude Code erscheinen die Tools entsprechend mit den Präfixen mcp__databridge__… und mcp__databridge-dev__…. Im Prompt genügt es zu sagen, welcher Server gemeint ist, z. B. „frag über databridge-dev die Tabellen von oracle-dev ab“.

Port 7062 ist derselbe wie beim Debuggen aus der IDE. Läuft gleichzeitig ein lokaler Function Host aus Visual Studio, Rider oder VS Code, belegt er den Port — dann entweder den Host oder die Testumgebung stoppen, oder in dev/.env einen anderen DATABRIDGE_PORT wählen und die URL von databridge-dev entsprechend anpassen.

Was sich damit testen lässt

Alle Tools aus MCP-Server → Operationen stehen zur Verfügung. Mit den Beispieldaten sind vor allem diese sinnvoll:

Die Service-Bus-Tools (list_queue_statuses, get_queue_status, peek_*) funktionieren, sobald das Profil servicebus läuft (dev/up.sh servicebus oder automatisch über getchanges/process, siehe Service Bus). Ohne dieses Profil liefern sie einen Verbindungsfehler, weil unter ExportQueueServiceBus dann nur der Dummy-Connection-String steht.

Weil in allen Datenbanken dieselben Tabellen liegen, eignet sich die Umgebung gut, um die Typ-Abbildung der Connectoren zu vergleichen: dieselbe Spalte, z. B. IsActive oder CreatedOnUtc, einmal je Connection abfragen.

Ohne Claude Code aufrufen

Der Endpoint spricht Standard-MCP über HTTP und lässt sich auch direkt aufrufen, z. B. zum schnellen Prüfen nach einer Code-Änderung:

• Windows (PowerShell)
• Linux / macOS

Invoke-RestMethod 'http://localhost:7062/api/mcp?code=local' -Method Post `
  -ContentType 'application/json' -Headers @{ Accept = 'application/json, text/event-stream' } `
  -Body '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_connector_table_schema","arguments":{"connectionName":"mssql-dev","tableName":"Account"}}}'

curl -s 'http://localhost:7062/api/mcp?code=local' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_connector_table_schema","arguments":{"connectionName":"mssql-dev","tableName":"Account"}}}'

Log

Jeder MCP-Aufruf schreibt eine Zeile ins Log der DataBridge, mit dem Namen der Operation und — wo vorhanden — dem gelesenen Job, Mapping bzw. der Connection und Tabelle:

MCP list_jobs
MCP get_job: job=oracle-to-mssql-account
MCP get_mapping: mapping=dev-opportunity
MCP get_connector_table_schema: connection=oracle-dev, table=Account

In der Testumgebung sieht man sie mit:

• Windows (PowerShell)
• Linux / macOS

podman compose -f dev/compose.dev.yml logs -f databridge | Select-String "MCP "

podman compose -f dev/compose.dev.yml logs -f databridge | grep "MCP "