Two deploy paths ship with the app: an MTA build (recommended) and a quick
cf push. Both use the cds.mcp config from package.json — see
Configuration.
Target your CF org and space first (subaccount region ap20 in this example):
cf target -o <org> -s <space>Before you deploy: make sure the BTP destination the app forwards to (default
pm4-bp-ssl, or the value configured inpackage.json) exists in the subaccount. Without it, requests fail at the proxy step. See BTP / backend setup for the destination properties (and a Basic-auth option for a first test).
npm install -g mbt # if needed
mbt build # produces mta_archives/mcp-router_1.0.0.mtar
cf deploy mta_archives/mcp-router_1.0.0.mtarThe MTA build captures the git commit/branch automatically, so /config and
/health report an accurate build stamp (see
Operations).
cf create-service destination lite mcp-router-destination
cf create-service connectivity lite mcp-router-connectivity
cf create-service identity application mcp-router-identity
cf create-service application-logs lite mcp-router-logs
cf pushOn a plain
cf pushthe buildpack does not upload.git, so the build stamp'scommit/buildTime/repomay be empty. SetGIT_COMMIT/BUILD_TIME/GIT_REPO_URLinmanifest.ymlenv, or use the MTA path (which captures git automatically).
After deployment, the identity binding auto-creates an Application in your
IAS tenant. See ../IAS-SETUP.md for the step-by-step admin
console configuration (Entra federation, redirect URIs, grant types, token
audience, and the email claim required for principal propagation).
npm install
npm run watch # or: npx cds serve- Auth uses the mocked kind; requests to
/mcpwithout a token are accepted and a mock principal is taken from thex-dev-emailheader. - Without a
destination/connectivitybinding the proxy returns a clean502 destination_error— expected locally.
curl http://localhost:4004/health
curl -X POST http://localhost:4004/mcp -H 'content-type: application/json' \
-H 'x-dev-email: me@corp.com' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'