calmcp 1.0: Der CALM MCP Server ist stabil

calmcp 1.0.0 ist erschienen. Der Open-Source CALM MCP Server für SAP Cloud ALM ist damit stabil. Stabil ist ein Versprechen, und bevor wir es abgeben, haben wir alles geändert, was wir später nicht mehr ändern wollen. Dazu kommen Verknüpfungen zwischen bestehenden Objekten, Transports zu Features und eine gründliche Sicherheitsrunde.

Was „stabil“ bedeutet

Ab 1.0 folgt calmcp Semantic Versioning. Eine inkompatible Änderung an der öffentlichen Schnittstelle wartet auf die nächste Hauptversion. Zur Schnittstelle gehören:

• Tool-Namen, Parameternamen und ihre Bedeutung sowie die Namen der Ressourcen und Analytics Provider
• Fehlercodes und die Form einer Fehlerantwort (error, retryable, status, message, hint)
• das Ergebnis von Zählungen (total, groups, complete, stoppedBy …) und die Antworten von calm_create und calm_update
• Umgebungsvariablen, Kommandozeilen-Optionen, XSUAA-Scopes und die Namen der Rollensammlungen

Nicht dazu gehören die Texte von Beschreibungen, Hinweisen und Meldungen. Die stimmen wir auf die Sprachmodelle ab, und sie dürfen sich in jedem Release ändern. Ausgenommen sind außerdem Ressourcen, die SAP als Beta kennzeichnet (Test Plans), und Änderungen, die SAP an Cloud ALM selbst vornimmt. Für Teams, die calmcp in Prompts, Rezepten oder Copilot Studio Aktionen verbauen, heißt das: Was heute funktioniert, funktioniert auch nach dem nächsten Minor-Update.

Vorher aufgeräumt: einheitliche Parameter

Bisher hing es vom Cloud ALM Service ab, wie man blättert: limit und offset bei REST-Ressourcen, top und skip bei OData. In 1.0 gibt es ein Paar für alles, calmcp übersetzt für jeden Service. Drei Namen haben sich geändert:

0.9	1.0	Wofür
limit, offset	top, skip	Blättern in jeder Ressource; nextPage ist immer { skip }
filters	rest_filters	Query-Parameter von Landscape Objects, Access Control Lists und BSM-Events
count	with_count	Gesamtzahl zusätzlich zu den Datensätzen

calmcp rät dabei nicht. Ein Aufruf mit einem alten Namen wird abgelehnt, bevor irgendetwas an Cloud ALM geht, und die Meldung nennt den neuen Namen: „'limit' is now 'top'“. Ein Modell korrigiert sich damit im nächsten Schritt selbst.

Lieber ablehnen als raten

Diese Regel steht hinter dem ganzen Release. Eine KI-Antwort, die falsch ist, aber richtig klingt, ist schlimmer als eine Fehlermeldung. calmcp lehnt deshalb ab, was es nicht einhalten kann:

• Unbekannte Parameter und Filter werden abgewiesen, nicht stillschweigend verworfen. Das gilt jetzt auch für Paging-Parameter neben count_only oder group_by und für IDs, die weder UUID noch Display ID sind.
• Zählungen mit Zeitbudget: Nach 40 Sekunden hört calmcp auf und meldet complete: false mit stoppedBy: "time", statt in das Timeout des Clients zu laufen oder eine Teilsumme als Gesamtzahl auszugeben.
• Volle Seiten werden angekündigt: Eine Liste ohne top holt 500 Datensätze und sagt mit nextPage, dass es weitergeht. Vorher kam etwa bei Landscape-Objekten der Service-Standard von 100 zurück, ohne Hinweis auf mehr. calm_analytics liefert nextPage jetzt ebenso.
• Seltsame Antworten sind Fehler: Eine Cloud ALM Seite in unbekanntem Format ist UPSTREAM_ERROR, statt als leer gelesen zu werden. Antworten über 8 MB sind RESPONSE_TOO_LARGE.

Neu: Verknüpfungen zwischen bestehenden Objekten

Bisher konnte calmcp Objekte anlegen, seit 0.9.4 auch Tasks (User Stories, Defects, Requirements, Risks) und Comments. Was fehlte, war der Zusammenhang. calm_create verknüpft in 1.0 bestehende Objekte:

• Tasks mit Features, Documents und Hierarchy Nodes
• Tasks mit anderen Tasks (Beziehungen) und mit URL-Referenzen
• URL-Referenzen an Features
• manuelle Test Cases mit User Stories und anderen Tasks

Features, Documents, Hierarchy Nodes und Test Cases nennen Sie dabei mit der Display ID, die Sie in Cloud ALM sehen, etwa 6-123 oder bei Test Cases dreiteilig wie 8-1-1. Ein Auftrag wie „Lege eine User Story für den XML-Export an und verknüpfe sie mit Feature 6-123 und dem Process Rechnungsbuchung“ wird so zu drei sauberen Aufrufen. Die Auflösung der Display ID ist für calm_get, calm_create und calm_update dieselbe und lehnt ab, wenn Cloud ALM ein anderes Objekt zurückgibt als gefragt.

Neu: Transports zu Features

Mit den Ressourcen feature_transports und feature_transport_references beantwortet calmcp, welche Transports zu einem Feature gehören. Damit reicht der Blick des Assistenten vom Requirement über User Story und Feature bis zum Transport: „Welche Transports gehören zu Feature 6-123, und sind die zugehörigen Defects geschlossen?“

Schreiben bleibt eng und ehrlich

calmcp ist per Default rein lesend. Ein Betreiber kann das Anlegen (CALM_WRITE_ENABLED) und das Ändern von Feature-Feldern (CALM_UPDATE_ENABLED) getrennt erlauben. Gelöscht wird nie. Neu in 1.0:

• Unklarer Ausgang wird benannt: Läuft ein Anlegen oder Ändern in ein Timeout, einen 408 oder einen 5xx, antwortet calmcp mit retryable: false und sagt, dass die Änderung vielleicht angekommen ist. Der Eintrag im Audit-Log trägt outcome: "unknown". Wiederholt wird nie, denn sonst entstünde womöglich ein Duplikat.
• Klare Fehler beim Schalter: Ist Schreiben ausgeschaltet, antworten calm_create und calm_update mit CONFIG statt INVALID_ARGUMENT.
• Eine Grenze von Cloud ALM: Enthält die Beschreibung eines Features Bilder, lässt sie sich über die API nicht ändern, weil der Bildservice von Cloud ALM den technischen Benutzer abweist. calmcp sagt das, statt die Bilder zu verlieren.

Sicherheit: eine vollständige Prüfrunde

• Rich Text per Allowlist: Statt verbotene Elemente aufzuzählen, prüft calmcp HTML gegen eine Liste erlaubter Elemente, Attribute und URL-Schemata. HTML aus dem Cloud ALM Editor passt, alles andere wird abgelehnt. Benannte und numerische Entities können keine Hosts oder CSS-Escapes mehr verstecken, und der Scanner läuft in linearer Zeit.
• OAuth nur für bekannte Clients: Dynamic Client Registration und der eingebaute Client akzeptieren nur die Redirect-URIs bekannter MCP-Clients wie Claude, ChatGPT, Cursor, VS Code, Mistral und Copilot Studio. Weitere lassen sich mit CALM_OAUTH_REDIRECT_PATTERNS ergänzen.
• HTTP gehärtet: Antworten werden gestreamt und bei 8 MB gedeckelt, Token-Abrufe laufen nur einmal gleichzeitig und werden geprüft, Fehler am /mcp-Endpunkt kommen als JSON-RPC-Fehler ohne Stacktrace.
• Lieferkette: GitHub Actions sind auf Commits gepinnt, das Release-Token gibt es nur im Upload-Schritt, und lokale Notizen und Skripte bleiben aus jedem Paket heraus.

Dazu kommt eine SECURITY.md mit dem Weg, Sicherheitslücken vertraulich zu melden.

Kleiner, schneller, genauer

• Tool-Ergebnisse sind kompaktes JSON ohne Einrückung und damit etwa ein Drittel kleiner. Das spart Kontext im Modell.
• group_by kommt mit Feldern zurecht, die Cloud ALM auf der ersten Seite weglässt, und holt bei OData nur die gruppierten Felder.
• calm_resources nennt Analytics Provider, die einen Filter brauchen (ServiceLevels, MonitoringEvents), und 403-Hinweise nennen den fehlenden Scope.
• Eine Folge von 401-Antworten verwirft kein frisch geholtes Token mehr, und im BTP-Destination-Modus holt calmcp nach einem 401 ein neues.

Upgrade von 0.9

• In gespeicherten Prompts, Rezepten und Copilot Studio Aktionen limit/offset in top/skip, filters in rest_filters und count in with_count umbenennen. Vergessene Stellen meldet calmcp mit dem neuen Namen.
• Für Verknüpfungen mit Test Cases der Cloud ALM API Instanz den Scope calm-api.testcases.write geben.
• An XSUAA und der Destination ändert sich nichts. Meldet sich ein anderer MCP-Client als die oben genannten über OAuth an, dessen Redirect-URI mit CALM_OAUTH_REDIRECT_PATTERNS freigeben.
• Auf SAP BTP: mbt build und cf deploy mta_archives/calmcp_1.0.0.mtar. In Claude Desktop die neue .mcpb von den GitHub Releases installieren.

calmcp läuft lokal über stdio, als Claude Desktop Extension oder zentral auf SAP BTP für Claude, ChatGPT, Copilot Studio, Cursor und VS Code. Alle Änderungen im Detail stehen im Changelog.

Installation, Konfiguration und alle Funktionen: auf der Produktseite calmcp – der CALM MCP Server und im GitHub-Repository.