Cloud ALM MCP

Node.js- und TypeScript-Grundgerüst für einen SAP Cloud A LM Model Context Protocol server.

Dieses Repository ist derzeit Mock-first. Es kann ohne Anmeldedaten für SAP Cloud ALM, Konfiguration des BTP Destination Service und OAuth-Einrichtung instaliert, erstellt, getestet und gestartet werden.

Ziel-Architektur

• Laufzeit: Node.js auf SAP BTP Cloud Foundry.

• Produktions-MCP-Transport: MCP Streamble HTTP über das offizie "MCP-TypeScrip-SDK".

• STR-158 verwendet für das PoC zustandsloses Streamable HTTP, einem kein Sitzungs-ID-Generator festgelegt wird.

• Lokaler Fallback TRANSPORT: stdio, nur für die lokale Entgedanung gedact.

• Zukünftiger Zugriffspfad für Cloud ALM: BTP Destination Service.

• Zukünftiges Authentifizierungsmodell: OAuth2 Client Credentials über eine konfigurierte Destination.

Die echte Verbindung zu SAP Cloud ALM ist in STR-158 bewusst nicht enthalten.

Die Anforderungen an Sitzung und Zustand müssen vor der produktiven Nutzung durch Agenten überprüft werden, falls spätere Tool-Abläufe einen persistenten MCP-Sitzungszustand erfordern. STR-158 führt bewusst keinen Sitzungs-Speicher ein.

Related MCP server: cloud-alm-itsm-mcp

Lokale Entwicklung

npm install
npm run build
npm test
npm start

Standardmäßig führt npm start den Mock-//Modus über HTTP aus und stellt Folgendes bereit:

** MCP-Endpunkt: POST /mcp ** Health-Endpunkt: GET /health

So:

curl http://localhost:3000/health

Verwenden Sie .env.example als Liste der unterstützten Platzhalter. Fügen Sie keine echten Cloud-ALM-Geheimnisse in lokale Dateien, die per git committet werden.

Konfiguration

Die zentralen Umgebungsvariablen:

• RUNTIME_MODE=mock|destination

• MCP_TRANSPORT=http|stdio

• PORT=3000

• READ_CAPABILITY_ABLED=true|false

• WRITE_CAPABILITY_RABLED=true|false

• ALLOWED_DESTINATIONS=cloud-alm-dev

• EXTETERNAL_CALS_ENABLED=false|true

Die lokalen Standardwerte sind bewusst sicher: Mock-Laufzeit, HTTP-Transport, Lesen aktiviert, Schreiben deaktviert und externe Aufrufe deaktviert.

Der Destination-Modus in diesem Grundgerüst ist derzeit nur ein Platzhalter. Er fällgt solange(zetimeout) geschlossen (Fall closed), bis der BTP-Destination-Service-Lookup und der OAuth-Token-Fluss in späteren Aufgaben implementiert werden.

Sicherheitsgrenze

Die Policy Guard wird vor Calls an Cloud-ALM-Clients per Code erzwungen. Sie validiert:

• nur zulässige Opperationsname

• Trennung von Lese-/Schreibfähigkeits(ls)

• Ablehnung von Löschoperationen

• Ablehnung von Massenoperationen

• Ablehnung unbekannter Operationen

• keine Destinations/uses oder keine Kundenauswahl, die vom Agenten übermittelt Ist

• Fail-closed-Verhalten bei mehrdeutiger Konfiguration

This ist bewusst keine rein prompt-basierte Durchsetzung. Die Kunden-Trennzähigkeit und dauerhafte gonfeste Audoging müssen in zukünftiger Architekturarbeit gelöst werden, wobei die Modul-Grenze bereits vorhanden sind.

Audit-Ereignisse reservieren bereits optionenelder für die spätere Nachverfolgbarkeit: Akteur, Kundendat en, Ressourcetyp/-ID oder Korrelations-ID. Das Grundgerüst erfindint keine echten Akteur- oder Kundenwerte und loggt keinerne Request-Payloads, Tokens, Autorisierung-Header, Client-Secrets oder sensitiven Antwortdaten.