Nutzung

Der Server spricht Standard-MCP über Streamable HTTP — grundsätzlich verbindet sich jeder MCP-fähige Client über dieselbe URL (.../api/mcp?code=<Function-Key>). Die folgenden Abschnitte zeigen die konkrete Einrichtung für die gängigsten Clients.

Claude Code

Dieses Repository bringt bereits eine passende .mcp.json mit:

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

Lokal (Core Tools / Debugger): Der lokale Function-Host prüft den Auth-Level Function nicht — der Platzhalterwert local in der URL reicht aus. Voraussetzung ist nur, dass die Function App tatsächlich auf Port 7062 läuft (nicht der func-Standard 7071!):

• Visual Studio / dotnet run: Startprofil DataBridge aus src/DataBridge/Properties/launchSettings.json (setzt bereits --port 7062).
• VS Code: Task func: host start aus .vscode/tasks.json (ebenfalls fest auf --port 7062).
• Rider: die in der IDE angezeigte „Azure Functions Project"-Run-Configuration DataBridge — im Feld „Function host arguments" muss host start --pause-on-error --port 7062 stehen.

Danach lädt Claude Code den databridge-Server automatisch; die Tools erscheinen mit dem Präfix mcp__databridge__....

Gegen eine Azure-Deployment-Instanz: DATABRIDGE_FUNCTION_KEY als Umgebungsvariable auf den echten Function Key setzen (Azure Portal → Function App → Funktionen → Mcp → Funktionsschlüssel) und localhost:7062 in einer lokalen .mcp.local.json (siehe .gitignore) durch die echte Function-App-URL ersetzen — niemals einen echten Key in .mcp.json committen.

Beispiel-Interaktion

Ein typischer Anwendungsfall: prüfen, ob ein Mapping-Feld wirklich im Zielsystem existiert.

Prompt: „Prüfe, ob das Mapping BCAccounts gültige Zielfelder hat — vergleiche mit den echten Metadaten der Connection."

Claude ruft dafür typischerweise nacheinander auf:

1. get_mapping mit rowKey: "BCAccounts" → liefert die konfigurierten Feld-Mappings inkl. TargetTable/TargetPath.
2. get_connector_table_schema mit der targetConnection aus dem zugehörigen Job sowie tableName/apiPath aus dem Mapping → liefert das tatsächliche Schema.
3. Vergleicht beide Ergebnisse und meldet fehlende Felder oder Typ-Abweichungen.

Damit lassen sich Mapping-Fehler bereits vor dem ersten produktiven Lauf eines Jobs erkennen, statt sie erst über eine fehlgeschlagene Dead-Letter-Nachricht zu bemerken (siehe peek_dead_letter_queue_messages, Operationen).

GitHub Copilot (VS Code)

VS Code (ab Version 1.99, Agent-/Chat-Modus) unterstützt MCP-Server nativ über eine mcp.json — entweder projektweit unter .vscode/mcp.json oder als Nutzer-Konfiguration über die Command Palette (MCP: Open User Configuration). Anders als Claude Codes .mcp.json liegt der Server hier unter dem Schlüssel servers, nicht mcpServers:

{
  "servers": {
    "databridge": {
      "type": "http",
      "url": "https://<function-app-name>.azurewebsites.net/api/mcp?code=${input:databridgeFunctionKey}"
    }
  },
  "inputs": [
    {
      "id": "databridgeFunctionKey",
      "type": "promptString",
      "description": "DataBridge MCP Function Key",
      "password": true
    }
  ]
}

Der inputs-Block sorgt dafür, dass VS Code beim ersten Verbindungsversuch einmalig nach dem Function Key fragt (maskierte Eingabe) statt ihn im Klartext in der Datei zu speichern — dieselbe Absicht wie die ${DATABRIDGE_FUNCTION_KEY:-local}-Umgebungsvariable im Claude-Code-Beispiel oben, nur über den VS-Code-eigenen Mechanismus. Lokal (Function-Host ohne Auth-Prüfung) reicht auch hier ein beliebiger Platzhalterwert. Details zu Input-Variablen: VS Code MCP-Konfigurationsreferenz.

Nach dem Speichern zeigt VS Code den Server im Chat-/Agent-Modus an; die Tools lassen sich dort wie jedes andere MCP-Tool auswählen und aufrufen.

Microsoft 365 Copilot

Microsoft 365 Copilot bindet externe MCP-Server nicht direkt per URL im Chat ein, sondern über Copilot Studio — dort lässt sich ein bestehender MCP-Server einem Agenten als Tool hinzufügen, und dieser Agent dann in Microsoft 365 Copilot veröffentlichen. Die Einrichtung erfolgt über den MCP-Onboarding-Wizard in Copilot Studio:

1. Im Agenten zur Seite Tools wechseln → Add a tool → New tool → Model Context Protocol.
2. Server-URL eintragen: https://<function-app-name>.azurewebsites.net/api/mcp.
3. Als Authentifizierungsart API key wählen (nicht OAuth 2.0 — unser Server nutzt den Azure-Functions-eigenen Function-Key-Mechanismus, kein OAuth).
4. Als Type Query wählen und als Parametername code eintragen — das entspricht genau dem ?code=-Query-Parameter, den auch Claude Code und VS Code verwenden.
5. Create, dann den Function Key als API-Key-Wert für die Verbindung hinterlegen.

Copilot Studio unterstützt für MCP ausschließlich den Streamable-HTTP-Transport (SSE ist seit August 2025 deprecatet) — genau das Protokoll, das McpApi.cs implementiert, es sind also keine serverseitigen Anpassungen nötig.

Alternativ lässt sich der Server auch als benutzerdefinierter Connector über eine OpenAPI-Beschreibung in Power Apps einbinden (x-ms-agentic-protocol: mcp-streamable-1.0) — das ist der Weg, wenn mehr Kontrolle über die Connector-Konfiguration nötig ist als der Wizard bietet. Details dazu: Microsoft-Dokumentation zu MCP in Copilot Studio.