Integrates with SAP Cloud Integration (CPI) tenants, primarily development tenants. Provides tools to log in with a personal SAP account, list packages and iFlows with their runtime status, and pull iFlows into a local workspace; to describe iFlows as a compact model or Mermaid diagram and diff versions at the model level; to make semantic edits to iFlows (inserting/removing steps from a bundled step catalog, adding adapters, changing settings, headers and properties) while keeping SAP's formatting; to validate structure and run XSLT and Groovy scripts locally or on the tenant; to run SAP's design-guideline and model checks; and to push new versions, deploy/undeploy, and send test messages, then inspect message logs and traces down to the failing step by name. Writes are restricted to tenants configured as development tenants, require user confirmation, and are recorded in an audit log.
This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
For development tenants only. Do not connect this server to a production tenant, not even with role: readonly. It is built for developing and testing on development systems: it uploads, deploys and deletes content,
sends test messages, runs scripts, and reads and changes runtime data (data stores, variables, number ranges,
queues). Its safety rules protect a development tenant from mistakes, not a production system from risk.
An MCP server that lets an AI agent develop SAP Cloud Integration (CPI) content: edit iFlows, Groovy scripts and XSLT as local files under git, check them locally, then push, deploy and test them on a development tenant.
Status: public beta (0.9.0-beta). Everything listed as Available was tried against a BTP trial tenant, by the author and by AI agents in test runs. Expect rough edges and report them as issues; names and behaviour may still change before 1.0 (CHANGELOG).
Read packages, iFlows and their status; pull an iFlow into a local folder.
Understand an iFlow without reading BPMN XML: a compact model, a Mermaid diagram, readable message mappings.
Edit iFlows safely: insert steps with correct default settings from a bundled step catalog (catalog), change settings, headers and properties; keep the file formatted like SAP's designer.
Check locally: structure validation, XSLT 1.0–3.0 runs, readable model-level diffs (also for git diff).
Test on the tenant (development tenants only): push, run SAP's design guideline check, deploy, send a test message, read the message log with the failing step by name, run a single Groovy script without deploying.
Related MCP server: SAP CPI MCP Server
Available tools work and were tried against a real tenant; Planned means designed but not built yet.
The agent's own environment (for example Claude Code or VS Code) reads and writes the local files, so the server adds no generic file tools.
Tool | What it does | Status |
| Log in with your own SAP account, so the tenant records you (not a technical client) as the one who changed or deployed content (how to set it up) | Available |
| Configured tenants and what the agent may do on each (read only, or development with writes) | Available |
| List packages; a package can be named by its ID or its display name | Available |
| List the iFlows and script collections of a package with version and runtime status | Available |
| Download an iFlow into the local workspace ( | Available |
| For every pulled iFlow and script collection (or one, or a package's): in sync, modified locally, changed on the tenant, or conflict, with pulled, tenant and deployed versions; with a package also what is not pulled | Available |
| Deployment state and deploy errors, with step IDs translated to step names | Available |
| HTTP endpoint URLs of deployed iFlows | Available |
| Names, types, expiry (days left) and deploy status of keystore entries, user credentials, OAuth2 clients and secure parameters; passwords, secrets, user names, secure values and certificates are never returned | Available |
| Configured values of externalized parameters, compared with the local | Available |
Tool | What it does | Status |
| Compact model of an iFlow (steps, adapters, settings, routes, decoded header tables) instead of BPMN XML; steps numbered | Available |
| Mermaid diagram of an iFlow; PNG later | Available (Mermaid) |
| Model-level changes between two versions: steps added or removed, settings old → new, table rows, rewired flows; ignores layout and IDs the designer regenerates. Also available as a | Available |
| Message mapping as one line per target field, | Available |
| The bundled step and adapter catalog (catalog): 106 variants with default settings | Available |
Tool | What it does | Status |
| Semantic edits in one all-or-nothing batch: insert a step from the catalog (with settings, headers, properties; for XSLT and message mappings the mapping file, for a Filter its XPath, for a script step a script from a script collection), remove a step, add or remove an adapter (sender to a start event or Poll Enrich, receiver from Request Reply, Send, Content Enricher or an end event; the Sender/Receiver box is reused or created, receivers drawn below their step; a box without adapters can be removed), add or remove an exception subprocess (steps go inside like anywhere else), add routers (conditions, default route) and parallel or sequential multicasts with a Join, put steps on their routes, edit or remove them, add or remove local integration processes and call them (Process Call, Looping Process Call with its loop), make the start a timer (run once, every n minutes or hours, or cron; start and end, time zone; always externalized so the schedule can be configured), lay out the iFlow (branches in rows, exception subprocess below, one pool per process), change settings of steps, adapters or the iFlow (unknown keys refused), rename, edit Content Modifier headers and properties. Keeps SAP's formatting, lays out the diagram, refuses edits that would break the iFlow, supports a dry run | Available |
| Declare, change or remove externalized parameters: | Available |
Tool | What it does | Status |
| Structural checks: dangling flows, missing diagram shapes, unreachable steps, missing script or mapping files, undeclared parameters; settings the tenant refuses only at deploy (empty split or Filter expression, key alias or mapping file, a Content Enricher or Request Reply without adapter, sender authorization values, Receiver names with spaces) | Available |
| Run an XSLT (1.0–3.0) locally with headers and properties as parameters, like a CPI XSLT Mapping step; errors with line numbers | Available |
| Run one Groovy script (also from a script collection) on the tenant without deploying (script runner iFlow, development tenants only); Groovy 2.4 or 4 chosen from the script's imports; returns body, headers, properties, console output and what changed | Available |
| Run SAP's design guideline check on the tenant (deploys through the API skip it) | Available |
| Run the tenant's model check ("Check for problems"); | Available |
| Local rules for common mistakes, including those SAP's guideline check flags | Planned |
Changes ask for your confirmation, and every version needs a number and comment you confirm. For letting AI agents test the server on their own there is an unattended test mode: test only, not for real development.
Tool | What it does | Status |
| Upload a local iFlow as a new version: the agent proposes number and one-line comment by the versioning rules, you confirm both in a dialog, and Cloud Integration's version history shows exactly that entry. Refuses when the tenant changed since the pull or the iFlow is open in the designer | Available |
| The versioning rules (default or your own file), the local changes since the last version and a hint (major/minor/patch), so the agent can propose number and comment | Available |
| Record the tenant's current content as a new version with number and comment, for example after work in the designer | Available |
| Create an empty iFlow in an allowed package (as the designer does: Sender and Receiver box, Start → End, version 1.0.0) and pull it; build it with | Available |
| Deploy the current version and wait; SAP's guideline check as an optional gate; errors are reported with step names, one line per problem. A failed deploy also stops the version that was running (Cloud Integration's behaviour), which the confirmation and result point out | Available |
| Remove a deployed iFlow or script collection from the runtime | Available |
| Delete an iFlow with its whole version history (for cleaning up test iFlows); refuses deployed iFlows and always asks for confirmation by default | Available |
| Configure parameter values on the tenant like "Configure" in the designer (no new version; the running iFlow uses them after the next deploy), timer schedules as a schedule object; the local | Available |
Scripts shared by the iFlows of a package. A Groovy or JavaScript step uses one with iflow_edit insert_step
scriptCollection (the collection's Id, settings.script the file name); the iFlow's manifest requirement is written
as the designer does. iflow_validate checks the script against a collection pulled into the same package folder, and
cpi_deploy refuses while a collection the iFlow uses is missing, in another package or not deployed in its latest version.
Tool | What it does | Status |
| Create an empty collection in an allowed package and pull it ( | Available |
| Download a collection; never overwrites local changes unless asked | Available |
| Upload it as a new version: version and comment confirmed by you (hint: a removed script is major, a new one minor); the comment goes to the changelog, since the tenant keeps none for collections | Available |
| Deploy it (before the iFlows that use it); with | Available |
| Delete it with its version history; refuses a deployed collection; always asks by default | Available |
What iFlows keep on the tenant between messages. Reading works on every configured tenant; changing only on
development tenants, for data of iFlows in allowed packages (global data: any development tenant; a JMS queue: every
iFlow using it must be in an allowed package), with your confirmation (runtime_data).
Tool | What it does | Status |
| Data stores (Write steps): all stores with their iFlow or global, entries and overdue entries; with a store, its entries | Available |
| One entry's stored message: body and headers (credential-like values hidden) | Available |
| Delete entries or a whole store, for example to reset test data | Available |
| Variables (Write Variables): all with their iFlow or global; with a name, its value | Available |
| Delete a variable, for example to restart a delta load | Available |
| JMS broker (capacity, queues used of the maximum, warnings) and queues with messages, size, state and the iFlows that read or write them; with a queue, its messages (failed, retries, next retry, message log) | Available |
| Retry failed messages now, move messages to another queue, delete messages, activate or deactivate a queue | Available |
| Number ranges (used by number range steps): min, max, current value, field length, rotate | Available |
| Create, change (for example reset the current value) or delete a number range; values checked before you are asked | Available |
| What was already processed and is skipped when it comes again (idempotent repository: file names of SFTP senders, ids of Idempotent Process Call steps), with expiry | Available |
| Remove such entries so the same file or id is processed again in the next test | Available |
| What the Persist steps of one message stored: entries, and an entry's body and headers | Available |
Tool | What it does | Status |
| Call a deployed iFlow's HTTP endpoint; fetches a CSRF token when the sender adapter requires one (the HTTPS sender default); returns status, response and the message log ID (also for failed calls) | Available |
| Search message processing logs | Available |
| One message log: status, error, and the processing steps by name (at log level INFO, SAP keeps steps for failed messages only) | Available |
| Body, headers and properties as they entered each step of one message. Uses an undocumented SAP endpoint to switch on tracing, so it sits behind an "experimental" setting | Available |
Creating or deleting packages. Packages are set up by people (with their names, vendors and access); the agent works inside existing packages that the configuration allows.
Managing locks. Message and design-time locks are held by the runtime and the designer for running work; the agent does not release them. Tools only report a lock where it blocks something (for example a push to an iFlow open in the designer).
Editing message mappings. Message mappings can be read (mapping_describe) but not changed: edit them in the
designer's mapping editor.
Safety: changes are only allowed on tenants configured as development tenants, in allowed packages that are not
read-only content. A push stops when the iFlow is open in the designer or changed on the tenant since the pull. Create,
delete, push, deploy and undeploy ask you for confirmation through the MCP client (MCP elicitation, showing the actual
changes); clients that cannot ask are refused rather than skipping the question. Every change is written to an audit
log, and credential values are never shown to the agent. With "login": "user", the tenant records your own user
for every change instead of the service key's technical client.
Requires Node.js 22 or later. The server is published on npm as
cpi-saper-dev-mcp: your AI client starts it with npx, which
downloads it on first use. During the beta the examples use cpi-saper-dev-mcp@beta (the newest beta); to pin one
version, write for example cpi-saper-dev-mcp@0.9.0-beta.5.
Create .cpi/config.json in your project folder (docs/CONFIGURATION.md), then connect the
server to your AI client as shown below.
How the server finds your configuration: it asks the client which project folders are open (MCP roots) and
uses the first one that contains .cpi/config.json. Clients that do not report roots get the server's working
folder instead. Without a project, it falls back to ~/.config/cpi-saper-dev-mcp/config.json, or to the file named
in the environment variable CPI_MCP_CONFIG.
From your project folder:
claude mcp add cpi-saper-dev-mcp -- npx -y cpi-saper-dev-mcp@betaAdd the server to your project in .vscode/mcp.json (create the file if it does not exist):
{
"servers": {
"cpi-saper-dev-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "cpi-saper-dev-mcp@beta"],
"cwd": "${workspaceFolder}"
}
}
}VS Code asks you to trust the server the first time it starts it. The tools are then available to Copilot's agent in
Copilot Chat. cwd makes the project folder the server's working folder, so it finds .cpi/config.json even if
roots are not reported.
VS Code also reads a workspace-root .mcp.json in the shared format (the same file Claude Code uses), when the
setting chat.mcp.workspaceRootConfig.enabled is on:
{
"mcpServers": {
"cpi-saper-dev-mcp": {
"command": "npx",
"args": ["-y", "cpi-saper-dev-mcp@beta"]
}
}
}This format has no working-folder setting; the server then relies on the roots VS Code reports.
For all projects at once, add the server to Copilot's user configuration ~/.copilot/mcp-config.json (or
$COPILOT_HOME/mcp-config.json), with the same mcpServers entry as above. Keep a shared configuration in
~/.config/cpi-saper-dev-mcp/config.json (with absolute paths to your service keys); a project's own
.cpi/config.json still takes precedence when the client reports that project as a root.
To run the latest code from this repository instead:
git clone https://github.com/devstylator/cpi-saper-dev-mcp.git
cd cpi-saper-dev-mcp
npm install
npm test # builds and runs the testsand use node /path/to/cpi-saper-dev-mcp/packages/mcp-server/dist/index.js as the command (in place of
npx -y cpi-saper-dev-mcp@beta). npm run pack:check builds the npm package and tries it the way users install it.
git diff of an .iflw file shows BPMN XML and diagram coordinates. With the server as git's diff driver, it shows
the model instead, one fact per line (steps with their settings, adapters, flows; message mappings as
target <- expression), so a change reads as "+ step … / - flow …". In your repository:
printf '*.iflw diff=cpi\n*.mmap diff=cpi\n' >> .gitattributes
git config diff.cpi.textconv "npx -y cpi-saper-dev-mcp@beta textconv"npx looks the package up on every start, which makes diffs of many files slow: for regular use install it once
(npm install -g cpi-saper-dev-mcp@beta) and use cpi-saper-dev-mcp textconv as the textconv command.
git diff --no-textconv still shows the XML. It applies wherever git shows diffs (git diff, git log -p, git show); merges are unchanged.
Node.js 22 or later.
A Cloud Integration tenant (a BTP trial works) and two service keys of the Process Integration Runtime
service: plan api (OData API) and plan integration-flow (calling deployed iFlows).
Optional, for running Groovy scripts on the tenant: the script runner iFlow from devstylator/CPI_Iflow_GroovyScriptExe deployed on a development tenant. Its API is described in docs/script-runner.openapi.yaml. The runner executes any code it receives, so never deploy it on test or production tenants.
docs/CONFIGURATION.md: tenants, roles, service keys and safety settings (planned).
docs/KNOWN_LIMITATIONS.md: where local checks differ from Cloud Integration.
docs/script-runner.openapi.yaml: API of the script runner iFlow.
Apache License 2.0. Created by Damian Kolasa (devstylator). Free to use, change and share, also commercially; copies and modified versions must keep the NOTICE file, which credits the original creator, and mark the files they changed.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
This server cannot be deployed
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Change-aware CI validation and affected-test guidance for coding agents.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
