ArubaOS-CX MCP Server (hpe-cx-mcp)

Ein Model Context Protocol (MCP)-Server, der Aruba CX (AOS-CX)-Switches für MCP-fähige KI-Agenten (Claude, VS Code Copilot usw.) verfügbar macht. Er verwandelt die Switch-REST-API (/rest/v10.x) und die SSH-CLI in eine kuratierte Sammlung sicherer, strukturierter Tools für Beobachtbarkeit, Fehlerbehebung und Konfiguration eines Campus-/Rechenzentrums-Fabrics (VLANs, Routing, BGP/OSPF, EVPN-VXLAN, VSX/VSF, Port-Zugriff / 802.1X, NAE, ARC…).

Der Server läuft als Docker-Container, spricht MCP über streamable HTTP und wird mit optionaler benannter Bearer-Token-Authentifizierung und JSON-Auditprotokollierung ausgeliefert.

Schnellstart

cd cx-mcp

# 1) Provide credentials (git-ignored)
cp .env.example .env                 # then edit: set ARUBA_DEFAULT_PASSWORD (and any source tokens)

# 2) Provide the device list (git-ignored)
cp inventory/inventory.example.yaml inventory/inventory.yaml   # then edit: your switches & IPs

# 3) Build and start
docker compose up -d --build

# 4) Watch it come up
docker compose logs -f hpe-cx-mcp    # wait for "✅ hpe-cx-mcp server is up and running"

Der MCP-Endpunkt ist dann unter http://<docker-host>:8002/mcp verfügbar. Richten Sie Ihren MCP-Client darauf aus (siehe §9). Ausführliche Details und Hinweise zu den Plattformen finden Sie in §3.

Related MCP server: API-Central

Inhaltsverzeichnis

1. Was dieser Server tut

2. Verfügbare Tools

3. Installation (macOS / Linux / Windows)

4. Volumes

5. Umgebungsvariablen

6. Inventarverwaltung

7. Sicherheit: Bearer-Auth & Auditprotokollierung

8. Tokenverwaltung

9. Verbinden eines MCP-Clients

1. Was dieser Server tut

• Einzelner Einstiegspunkt für eine Flotte von AOS-CX-Switches, die in einem Inventar beschrieben sind.

• Lesen (Beobachten): Schnittstellen, VLANs, Routing-/ARP-/MAC-Tabellen, BGP/OSPF/EVPN, VXLAN-Tunnel, VSX/VSF-Stack-Status, Hardware-Zustand, Logs, 802.1X / Port-Zugriff, NAE-Skripte, Anwendungserkennung (ARC), vollständige Konfigurationen.

• Schreiben (Konfigurieren): VLAN-Dienste, Loopbacks, geroutete Ports, VRFs, BGP, OSPF, EVPN/VXLAN, Port-Authentifizierung, virtual-MAC, ARC – jeweils gepaart mit einem verify_*-Rücklese-Tool.

• Sicherheitsvorkehrungen:

  • Pro Gerät access_mode (standardmäßig read-only; Schreiboperationen werden verweigert, sofern ein Gerät nicht ausdrücklich read-write ist).

  • Standortbezogene Operationen (site-Parameter), um auf eine Gruppe von Geräten zu wirken.

  • Erkennung von SSH-Schreibbefehlen, um Konfigurationsänderungen über die Raw-CLI auf read-only-Geräten zu blockieren.

• Dynamisches Inventar: führt die lokale Datei mit NetBox / Nautobot-Wahrheitsquellen zusammen, mit optionaler Auflösung von Zugangsdaten über HashiCorp Vault.

2. Verfügbare Tools

Die Tools sind nach ihrem Zweck gruppiert. Lesetools setzen voraus, dass ein Gerät erreichbar ist; Schreibtools setzen zusätzlich voraus, dass das Gerät read-write ist.

Inventar und Sitzungen

Rohzugriff (Notausstiege)

System & Hardware

get_system_info, get_hardware_health, get_boot_history, get_transceivers, get_ssh_config, get_logs.

Container & Lizenzierung

get_containers (Anwendungscontainer auf dem Switch: Status, Image, CPU-/Speicherlimits, VRF-Netzwerke), get_feature_pack (Lizenzierungs-/Abonnementstatus: Verwaltungsmodus, Gültigkeit, Ablauf, Durchsetzung pro Feature).

Cloud-Verwaltung

get_aruba_central (Verbindungsstatus zu HPE ANW Central / Aruba Central: verbunden, Instanziierung, Konfigurationsquelle, Standort, VRF/Quell-IP, Activate-Konnektivität).

L2-/L3-Status

get_interfaces, get_loopbacks, get_routed_ports, get_vlan_interfaces, get_vlans, get_lldp_neighbors, get_mac_table, get_arp_table, get_routing_table, get_spanning_tree.

Routing-Protokolle

get_bgp_neighbors, get_bgp_config, get_bgp_routes, get_ospf_overview, get_ospf_neighbors, get_ospf_interfaces.

EVPN / VXLAN

get_evpn_config, get_evpn_routes, get_evpn_multihoming, get_vxlan_config, get_vxlan_tunnels, get_vxlan_static_peers, get_evpn_vtep_neighbors.

Hochverfügbarkeit (VSX / VSF)

get_vsx_status, get_vsx_config, get_vsx_sync, get_vsf_status, get_vsf_config, get_maintenance_mode.

NAE (Network Analytics Engine)

get_nae_scripts, get_nae_script, get_nae_agents, get_nae_agent.

Port-Zugriff / AAA / 802.1X

get_port_access_clients, get_port_access_client_detail, get_port_access_auth_config, get_port_access_summary, get_port_access_policies, get_port_access_roles, get_port_access_gbps, get_gbp_role_maps, get_port_access_abps, get_radius_servers, get_tacacs_servers, get_aaa_authentication, get_aaa_accounting.

Anwendungserkennung & -steuerung (ARC)

get_app_recognition, get_app_visibility.

Konfigurationsverwaltung

list_configs, get_config, get_full_config, compare_configs, manage_config (Speichern / Checkpoint / Rollback).

Konfigurieren (Schreiben) + Verifizieren-Paare

Jedes configure_*-Tool hat ein passendes verify_*-Rücklese-Tool:

Schreibschutz: Ein Aufruf von configure_* / create_* / delete_* / manage_config auf einem read-only-Gerät wird abgelehnt. Markieren Sie das Gerät im Inventar mit access_mode: read-write, um Änderungen zu erlauben.

Tool-Bereitstellung: Flat-Toolset (Standard) vs. Legacy-Atomtools

Der Server kann seine Fähigkeiten auf zwei sich gegenseitig ausschließende Arten bereitstellen, die über das Flag CX_FLAT_TOOLSET ausgewählt werden (siehe §5):

Flat-Toolset (CX_FLAT_TOOLSET=true — die Standardeinstellung). Die oben aufgeführten ~101 atomaren Tools werden zu ~23 Flat-Dispatchern zusammengefasst, die über ein scope-Argument (und bei Schreibvorgängen über ein action-Argument) gesteuert werden. Der zugrunde liegende REST-Client-Code bleibt unverändert – die Dispatcher leiten nur dorthin weiter, sodass keine Verhaltensregression entsteht. Jeder Lese-Dispatcher akzeptiert außerdem device: str | list, site oder source (eine externe Wahrheitsquellen-Abfrage) und führt den Aufruf parallel aus, wobei eine Hülle {scope, results, errors, summary} zurückgegeben wird. Ein optionales limit begrenzt lange Listenfelder in der Antwort.

Plus 7 atomare Werkzeuge, die beibehalten wurden: list_devices, list_sites, get_logs, run_ssh_commands, manage_config, logout, rollback. Write-Dispatcher behalten den Plan → Apply → Verify-Lebenszyklus und den pro-Gerät-Read-only-Schutz bei. Domänenfelder werden in einem params-Objekt übergeben (Schlüssel sind in jedem Dispatcher-Docstring dokumentiert).

Legacy-atomare Werkzeuge (CX_FLAT_TOOLSET=false). Stattdessen wird der vollständige Werkzeugkatalog oben bereitgestellt, optional geformt durch die drei untenstehenden Ebenen. Verwenden Sie dies für einen sofortigen Rollback zum bisherigen Verhalten.

Progressive Offenlegung, funktionale Präfixe & Schreibsicherheit (nur Legacy-Modus)

Drei optionale Ebenen (nur aktiv bei CX_FLAT_TOOLSET=false, jede durch ein eigenes Env-Flag gesteuert — siehe §5) formen, wie die Legacy-Werkzeuge bereitgestellt werden:

1. Progressive Offenlegung (CX_DEFERRED_TOOLS) — anstatt den vollständigen Katalog (100+ Werkzeuge) zu bewerben, veröffentlicht der Server nur etwa ~27 Tier-1-Werkzeuge (die am häufigsten verwendeten Lese-/Diagnosewerkzeuge, die Notausgänge, die Orchestratoren und die Meta-Werkzeuge). Jedes andere Werkzeug ist aufgeschoben (Tier-2) und wird bei Bedarf über zwei Meta-Werkzeuge erreicht:

Dies hält die Werkzeugliste des Agents klein und kostengünstig, während die gesamte Oberfläche erreichbar bleibt.

2. Funktionale Präfixe (CX_TOOL_PREFIXES) — beworbene Werkzeuge werden umbenannt <Domain>__<Werkzeug>, um sie nach Domäne zu gruppieren, z. B. routing__get_bgp_neighbors, overlay__configure_evpn, service__create_vlan_service, meta__invoke_tool. Domänen: inventory, exec, system, interface, switching, routing, overlay, redundancy, security, app, nae, config, service, meta. invoke_tool akzeptiert entweder den präfigierten oder den nackten Namen.

3. Schreibsicherheit (CX_WRITE_SAFETY) — ein Vorschau→Anwenden-Workflow mit Rollback:

Workflow: Rufen Sie ein beliebiges Schreibwerkzeug mit apply=false (Standard) auf, um einen Plan und ein dry_run_token zu erhalten; rufen Sie dann apply_plan(dry_run_token=…) auf, um genau diesen Plan anzuwenden. Idempotente configure_*-Merges haben kein automatisches Invers und werden von rollback als unsupported gemeldet. Wenn CX_REQUIRE_DRY_RUN_TOKEN=true gesetzt ist, wird ein direkter Apply (apply=true) über invoke_tool verweigert — Aufrufer müssen den Pfad Vorschau→apply_plan durchlaufen.

3. Installation (macOS / Linux / Windows)

Voraussetzungen

• Docker und Docker Compose v2 (docker compose …).

  • macOS / Windows: Docker Desktop.

  • Linux: Docker Engine + das Compose-Plugin.

• Netzwerkerreichbarkeit vom Docker-Host zu den Verwaltungs-IPs der Switches (HTTPS/443 für REST, TCP/22 für SSH).

• REST-Zugriff muss auf den Zielgeräten und im richtigen VRF konfiguriert sein: im Lese-Schreib-Modus für Lese- und Schreibzugriff und im Nur-Lese-Modus für reinen Lesezugriff.

• SSH-Zugriff muss ebenfalls auf den Zielgeräten konfiguriert sein für die Werkzeuge, die ihn benötigen.

Konfiguration (erster Lauf)

Geheimnisse und bereitstellungsspezifische Einstellungen befinden sich außerhalb von docker-compose.yml, in Dateien, die git-ignoriert sind, sodass sie nie eingecheckt werden. Zwei Vorlagen werden mitgeliefert — kopieren Sie jede und füllen Sie sie aus:

cd cx-mcp

# 1) Credentials & external source tokens  →  .env  (git-ignored)
cp .env.example .env
#    then edit .env and set at least ARUBA_DEFAULT_PASSWORD

# 2) Device inventory  →  inventory/inventory.yaml  (git-ignored)
cp inventory/inventory.example.yaml inventory/inventory.yaml
#    then edit it: list your switches, their IPs and per-device access_mode

.env wird über env_file: in docker-compose.yml in den Container injiziert. Mindestinhalt (siehe .env.example für die vollständige Liste):

ARUBA_DEFAULT_USERNAME=admin
ARUBA_DEFAULT_PASSWORD=your-switch-password
ARUBA_API_VERSION=latest
# Optional external sources of truth (leave empty if unused):
NETBOX_URL=
NETBOX_TOKEN=
INFRAHUB_URL=
INFRAHUB_TOKEN=

Committen Sie niemals .env oder inventory/inventory.yaml — sie enthalten echte Anmeldeinformationen und Geräte-IPs. Nur die *.example-Vorlagen werden von git verfolgt.

Erstellen und Starten (alle Plattformen)

cd cx-mcp
docker compose up -d --build

Der Server lauscht auf http://<host>:8002/mcp (Host-Port 8002 → Container- Port 8000, siehe docker-compose.yml). Das Image wird als hpe-cx-mcp:latest erstellt und läuft als Container hpe-cx-mcp.

Prüfen Sie, ob es läuft:

docker compose logs -f hpe-cx-mcp
# look for, in order:
#   "Uvicorn running on http://0.0.0.0:8000"
#   "✅ hpe-cx-mcp server is up and running on http://0.0.0.0:8000 — if your agent
#    already has an open MCP connection, reset it (MCP: Disconnect → Connect) …"

Die Zeile ✅ … server is up and running wird ausgegeben, sobald der Listener bereit ist. Wenn der Start stattdessen fehlschlägt, protokolliert der Server ❌ hpe-cx-mcp server failed to start gefolgt von der vollständigen Traceback (und beendet sich dann mit einem Nicht-Null-Exit-Code).

Hinweis: Jedes docker compose up -d --build baut das Image neu auf und startet den Server neu, wodurch eine bestehende MCP-Sitzung ungültig wird. Nach einem Neubau müssen Sie Ihren Client erneut verbinden (MCP: Disconnect → Connect), um die aktuellen Werkzeuge zu übernehmen.

Plattformhinweise

Linux

• Bind-Mount-Ordner gehören Ihrem Host-Benutzer. Der Container läuft als uid 1000; wenn Ihr Host-Benutzer nicht uid 1000 ist, machen Sie die beschreibbaren Ordner für uid 1000 lesbar/beschreibbar:

  mkdir -p logs secrets
  sudo chown -R 1000:1000 logs secrets
  chmod 700 secrets

• Um Switches im lokalen L2-Netz des Hosts zu erreichen, können Sie network_mode: host in docker-compose.yml auskommentieren (nur Linux).

macOS (Docker Desktop)

• Dateifreigabe wird von der VM übernommen; Bind-Mounts funktionieren sofort und die uid-Zuordnung erfolgt automatisch — in den meisten Fällen ist kein manuelles chown nötig.

• network_mode: host wird nicht auf die gleiche Weise wie unter Linux unterstützt; behalten Sie die Standard-ports:-Zuordnung (8002:8000) bei.

Windows (Docker Desktop + WSL2)

• Führen Sie die Befehle aus einer WSL2-Shell oder PowerShell aus. Es wird dringend empfohlen, das Projekt innerhalb des WSL2-Dateisystems zu speichern (z. B. \\wsl$\… / ~/cx-mcp) für korrekte Dateiberechtigungen und Leistung.

• Verwenden Sie in docker-compose.yml-Volumenpfaden Schrägstriche vorwärts (./inventory:/app/inventory:ro).

• network_mode: host ist nicht verfügbar; behalten Sie die ports:-Zuordnung.

4. Datenträger

Drei Host-Ordner werden in den Container eingebunden:

volumes:
  - ./inventory:/app/inventory:ro
  - ./logs:/app/logs
  - ./secrets:/app/secrets

Der Anwendungscode ist im Image eingebacken — nur diese Datenordner werden eingebunden. Wenn Sie eine *.py-Datei ändern, bauen Sie mit docker compose up -d --build neu (ein einfacher Neustart reicht nicht).

Eigentümer (Linux): logs/ und secrets/ müssen für Container-uid 1000 beschreibbar sein. secrets/ sollte 0700 sein, und seine .tokens-Datei wird vom Server selbst mit 0600 geschrieben.

5. Umgebungsvariablen

Geheimnisse und bereitstellungsspezifische Werte (Anmeldeinformationen, Tokens externer Quellen) werden über die git-ignorierte .env-Datei bereitgestellt, die docker-compose.yml über env_file: lädt (kopieren Sie .env.example nach .env, siehe §3). Nicht-geheime Betriebsflags (MCP_*, CX_*, INVENTORY_FILE) werden direkt in docker-compose.yml unter environment: gesetzt. Boolesche Werte akzeptieren true/1/yes/on.

Transport

Geräte-Anmeldedaten & API (in .env gesetzt; pro Gerät in der Inventarliste überschreibbar)

Inventar & externe Quellen

Bearer-Authentifizierung (optional, standardmäßig AUS)

Audit-Logging (optional, standardmäßig AUS)

Progressive Offenlegung, Präfixe & Schreibsicherheit (optional)

6. Inventarverwaltung

Die Inventardatei (inventory/inventory.yaml) deklariert die Geräte und wie sie erreicht werden. Sie ist git-ignoriert (sie enthält echte IPs und Anmeldedaten); erstellen Sie sie einmalig aus der mitgelieferten Vorlage:

cp inventory/inventory.example.yaml inventory/inventory.yaml

Werte in der Datei überschreiben Umgebungsvariablen. Unterstützte Formate: YAML, JSON, TOML.

Minimalbeispiel

defaults:
  username: admin
  password: "secret"
  api_version: latest        # auto-detect the newest REST version
  verify_ssl: false
  timeout: 30
  access_mode: read-only     # writes denied unless overridden per device

devices:
  Spine1:
    host: 192.0.2.21
    description: "Core switch"
    tags: [core, spine]
    site: campus-principal
    access_mode: read-write   # allow configuration changes on this device
  Access-01:
    host: 192.0.2.23
    site: campus-principal

Optionen pro Gerät

host (erforderlich), username, password, api_version, verify_ssl, timeout, tags, description, site, ssh_port, ssh_username, ssh_password, access_mode (read-only | read-write), vault (true, um Anmeldedaten aus Vault abzurufen).

Standorte (Sites)

Das Konzept site ist optional und ermöglicht es Tools, eine Gruppe von Geräten anzusprechen (list_devices(site=…), run_on_site(site, …)). Verwenden Sie entweder ein site:-Feld pro Gerät oder einen sites:-Block auf oberster Ebene, der Geräte gruppiert.

Optionen für Inventarquellen

Es gibt mehrere Möglichkeiten, zu bestimmen, woher die Geräteliste stammt:

1. Nur lokal (Standard) — Geräte aus der Datei:

   source: local        # may be omitted

2. Einzelne externe Quelle — aus einer Quelle der Wahrheit abrufen:

   source: netbox
   sources:
     netbox:
       type: netbox            # netbox | nautobot | infrahub
       url: https://netbox.example.com
       token: "<api-token>"    # or via NETBOX_TOKEN env var
       verify_ssl: false

3. Zusammengeführte Quellen mit Priorität — ein Gerät, das in mehreren Quellen vorhanden ist, wird aus der Quelle mit höherer Priorität übernommen:

   source: [local, netbox]
   source_priority: [local, netbox]   # local wins over netbox

Priorität der Anmeldedaten-Auflösung (höchste zuerst):

1. Gerätespezifische Anmeldedaten, die im Geräteeintrag gesetzt sind.

2. HashiCorp Vault (wenn vault global oder pro Gerät aktiviert ist).

3. Umgebungsvariablen / Inventar-Standardwerte.

Nach dem Bearbeiten des Inventars können Sie Änderungen ohne Neubau über das refresh_inventory-Tool anwenden oder den Container neu starten.

Startvalidierung (Fail-Fast)

Die Inventardatei wird beim Start validiert. Wenn sie nicht geparst werden kann (YAML/JSON/ TOML-Syntaxfehler) oder gegen das erwartete Schema verstößt (z. B. ein falsch eingerückter source:-Schlüssel oder source auf einen Nicht-String/Nicht-Listen-Wert gesetzt), protokolliert der Server einen spezifischen englischen Fehler und weigert sich zu starten, anstatt still mit einem leeren oder unvollständigen Inventar zu laufen:

❌ Inventory file '/app/inventory/inventory.yaml' failed validation — the server will NOT start.
   YAML syntax error: expected '<document start>', but found '<block mapping start>'
     in "<unicode string>", line 22, column 1
   Fix the inventory file, then restart the container.

Der Container beendet sich mit einem Exit-Code ungleich Null (sichtbar in docker logs / docker compose ps). Beheben Sie die gemeldete Zeile und starten Sie neu. Hinweise:

• Eine fehlende Inventardatei ist nur eine Warnung (sie kann später eingehängt werden) — der Server startet trotzdem.

• Die Erreichbarkeit externer Quellen (NetBox / Nautobot / Infrahub nicht verfügbar) ist nicht fatal: Das geparste lokale Inventar bleibt nutzbar und die dynamische Zusammenführung degradiert elegant.

• Das Laufzeit-Tool refresh_inventory wendet dieselbe Validierung an, stürzt aber nie einen laufenden Server ab: Bei einer fehlerhaften Datei gibt es einen Fehler zurück und behält das zuvor geladene Inventar.

7. Sicherheit: Bearer-Auth & Audit-Logging

Beide Funktionen sind standardmäßig deaktiviert und vollständig abwärtskompatibel.

• Authentifizierung (CX_AUTH_ENABLED=true): Jede Anfrage an /mcp muss Authorization: Bearer <token> enthalten. Fehlende/ungültige Token erhalten HTTP 401. Der Name des Tokens wird zum im Audit-Log erfassten actor, sodass Sie immer wissen, wer was getan hat. Wenn Auth aktiviert ist, aber noch kein Token existiert, startet der Server trotzdem, aber im LOCKED-Modus: Jede MCP-Anfrage wird mit HTTP 503 abgelehnt (Fail-Closed), sodass die Dienste nicht erreichbar sind. Erstellen Sie das erste Token (siehe §8) und starten Sie den Container neu, um zu entsperren — der Token-Speicher wird einmalig beim Start geladen.

• Audit (CX_AUDIT_ENABLED=true): Eine JSON-Zeile pro Tool-Aufruf in logs/audit.jsonl, einschließlich actor, src_ip, tool, category (read/write), Ziel-device, redigierte arguments, outcome, HTTP- status_code und duration_ms. Geheimnisse (Passwörter/Token) werden maskiert.

Beides aktivieren:

# docker-compose.yml
CX_AUTH_ENABLED:  "true"
CX_AUDIT_ENABLED: "true"

docker compose up -d --build

8. Token-Verwaltung

Token werden in secrets/.tokens gespeichert (Berechtigungen 0600). Verwalten Sie sie innerhalb des laufenden Containers mit dem mitgelieferten CLI:

# Create a named token (prints the secret once — save it)
docker compose exec hpe-cx-mcp python cx_token_manager.py generate --name vscode-dev

# List tokens (names, descriptions, created — secret truncated)
docker compose exec hpe-cx-mcp python cx_token_manager.py list

# Show one token
docker compose exec hpe-cx-mcp python cx_token_manager.py show --name vscode-dev

# Revoke a token
docker compose exec hpe-cx-mcp python cx_token_manager.py revoke --name vscode-dev

Generierte Token haben das Präfix cx_. Verwenden Sie pro Client/Agent ein eigenes Token, um eine Zuordnung pro Akteur im Audit-Log zu erhalten.

Erstes Token: Wenn die Authentifizierung aktiviert ist, startet der Server LOCKED (HTTP 503 bei jeder Anfrage), bis ein Token existiert. Nach dem Erstellen des ersten Tokens können Sie es ohne Neustart per Hot-Reload anwenden (siehe unten):

docker compose exec hpe-cx-mcp python cx_reload.py

(auch docker compose restart hpe-cx-mcp funktioniert).

Hot Reload (kein Neubau / kein Neustart)

Token- und Inventardateien werden beim Start in den Speicher geladen. Nach dem Bearbeiten von secrets/.tokens (über das obige CLI) oder inventory/inventory.yaml wenden Sie die Änderungen auf den laufenden Server an, indem Sie ihm ein Reload-Signal senden:

docker compose exec hpe-cx-mcp python cx_reload.py

Dies lädt sowohl die Token als auch das Inventar direkt neu — das Hinzufügen/Widerrufen eines Tokens oder das Hinzufügen/Aktualisieren eines Geräts wird bei der nächsten Anfrage wirksam. Der Befehl sendet nur das Signal; das Ergebnis (Anzahl, Fehler) wird in die Logs geschrieben:

docker compose logs --tail=20 hpe-cx-mcp

Das Neuladen erfolgt manuell und explizit — es gibt keine automatische Dateiüberwachung.

Wenn Clients über ein gemeinsames Relay verbunden sind, erscheinen alle Aufrufe unter dem einzelnen Token des Relays; für eine Zuordnung pro Agent verbinden Sie sich direkt mit hpe-cx-mcp mit eigenen Token.

9. Verbinden eines MCP-Clients

Richten Sie Ihren MCP-Client auf den Streamable-HTTP-Endpunkt aus:

URL:  http://<docker-host>:8002/mcp

Wenn die Authentifizierung aktiviert ist, fügen Sie den Header hinzu:

Authorization: Bearer cx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Beispiel (VS Code mcp.json-Stil):

{
  "servers": {
    "hpe-cx-mcp": {
      "type": "http",
      "url": "http://localhost:8002/mcp",
      "headers": { "Authorization": "Bearer cx_xxxxxxxxxxxxxxxxxxxx" }
    }
  }
}