# MCP für die Testumgebung > Den MCP-Server der lokalen Podman-Testumgebung als eigenen Server databridge-dev in Claude Code nutzen — parallel zur Cloud-Instanz. --- Site [llms.txt](/llms.txt) --- Die DataBridge in der [Podman-Testumgebung](../lokale-testumgebung/) bringt denselben [MCP-Server](/docs/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: | Server | Ziel | URL | |---|---|---| | `databridge` | Eine Azure-Instanz (bzw. ohne Konfiguration der lokale Host) | `${DATABRIDGE_MCP_URL:-http://localhost:7062}/api/mcp?code=${DATABRIDGE_FUNCTION_KEY:-local}` | | `databridge-dev` | Die Podman-Testumgebung | `http://localhost:7062/api/mcp?code=local` | ```json { "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](/docs/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“. > **Session neu starten** > > Claude Code verbindet sich nur beim Start einer Session mit den MCP-Servern. Läuft die > Testumgebung beim Start noch nicht, meldet `databridge-dev` einen Verbindungsfehler. Dann > `dev/up.sh` abwarten und die Session neu starten. Beim ersten Mal fragt Claude Code, ob der > Projekt-Server `databridge-dev` erlaubt werden soll. 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](/docs/mcp-server/operationen/) stehen zur Verfügung. Mit den Beispieldaten sind vor allem diese sinnvoll: | Tool | Beispiel | Ergebnis | |---|---|---| | `list_jobs` | — | Die generierten Jobs, z. B. `oracle-to-mssql-account` | | `get_job` | `rowKey: "mssql-to-postgres-opportunity"` | Quelle, Ziel, Mapping und Watermark des Jobs | | `list_mappings` | — | `dev-account`, `dev-opportunity`, `dev-opportunityproduct` | | `get_mapping` | `rowKey: "dev-account"` | Die 19 Feldzuordnungen von `Account` | | `list_connector_tables` | `connectionName: "postgres-dev"` | `account`, `opportunity`, `opportunityproduct` | | `get_connector_table_schema` | `connectionName: "oracle-dev"`, `tableName: "Account"` | Spalten mit .NET-Typ, Nullable, Länge, Precision/Scale und Primary Key | | `list_connector_tables` | `connectionName: "bc-dev"` (`apiPath` optional, leer = `v2.0`) | `customers`, `opportunities`, `opportunityLines` (aus der EDMX des Mocks, nur mit `dev/up.sh … bc`) | | `get_connector_table_schema` | `connectionName: "nav-dev"`, `tableName: "Customers"` | 8 Spalten, Primärschlüssel `No` | | `get_connector_table_schema` | `connectionName: "openapi-dev"`, `tableName: "customers"` | 8 Spalten aus der OpenAPI-Spec des Mocks | | `get_connector_table_schema` | `connectionName: "bc-dev"`, `tableName: "v2.0/opportunities"` (`apiPath` weggelassen) | Funktioniert ebenso — das Tool trennt den API-Pfad selbst ab, wenn er noch Teil von `tableName` ist | 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](../lokale-testumgebung/#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: 
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: 
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 "