IBM Code Engine MCP server

IBM Code Engine MCP Server

MCP server for IBM Code Engine — build, push, and deploy containers from Cursor, Copilot, Claude, and Cline using natural language.

Current release: v1.7.8 — 28 tools instead of 112 (one tool per resource with an action field, same capability, old names still work), a shared local HTTP server for the VS Code extension, a web admin UI with a Remote client tab (test tools, logging, users and API keys, events), MCP Remote Config inside VS Code, and a check that the server you point at really is a code-engine MCP server. See CHANGELOG.md and the tool reference.

Search terms: code-engine-mcp · ibm-code-engine · ibm-cloud · ibm-container-registry · mcp-server · model-context-protocol · cursor · github-copilot · claude-desktop · cline · docker · podman · serverless · container-deployment · typescript · npx · ai-agents · devops · cloud-native · watsonx-orchestrate

---

Author: Markus van Kempen | markus.van.kempen@gmail.com · markusvankempen.github.io No bug too small, no syntax too weird.

---

How It Works

flowchart TD
    A([AI Assistant\nCopilot / Claude / Cline / Bob]) -->|MCP JSON-RPC| B[Code Engine MCP Server]

    B --> C{Tool Category}

    C -->|Container Tools| D[Docker / Podman]
    C -->|Registry Tools| E[IBM Container Registry\nus.icr.io]
    C -->|Code Engine Tools| F[IBM Code Engine\nREST API]
    C -->|Procedures| G[Multi-step Workflows]

    D -->|build / push / validate| E
    E -->|image reference| F

    G -->|proc_build_push_deploy| D
    G -->|proc_apply_manifest| F

    F --> H[(Projects\nApps\nBuilds\nJobs\nSecrets\nDomains)]

    H -->|ready| I([Live App\nhttps://app.region.codeengine.appdomain.cloud])

    style A fill:#1261FE,color:#fff
    style B fill:#0f3460,color:#fff
    style G fill:#7b2d8b,color:#fff
    style I fill:#198038,color:#fff

✨ What You Get

• 28 tools, one per resource. ce_app, ce_job, ce_secret, … each take an action (list, get, create, delete, …). Every earlier capability is still there; see the tool reference.
• Container workflow tools for Docker or Podman (local_container, dockerfile)
• IBM Container Registry (icr) and the whole Code Engine surface: projects, apps, jobs, builds, secrets, config maps, domains, bindings, functions, fleets
• Multi-step procedures: build, push and deploy in one call (proc_build_push_deploy), custom domains, declarative manifests
• One server, many clients. Run it over stdio, or as an HTTP server that your IDE, assistants, the web UI and the VS Code extension all share
• Web admin UI (/admin): overview, activity, users, API keys, runtime settings, and a Remote client tab that tests the tools and configures the server (logging, users and keys, events)
• MCP-ready setup for GitHub Copilot, Cursor, Cline, Bob, Windsurf, Antigravity, Claude Desktop, and the VS Code extension in vscode-extension/ (including MCP Remote Config)
• MCP Activity Dashboard — live timeline of tool calls, session grouping, deploy outcome highlights, and a Deployments inventory tab
• Live activity logging — optional JSONL event stream for every MCP tool call (MCP_ACTIVITY_* env vars)

🚀 Quick Start

# 1) Install dependencies
npm install

# 2) Build the server
npm run build

# 3) Run once to verify
node build/index.js

Then configure your MCP client using one of the examples in the Configuration section below.

🤖 The Agentic Experience (No Docker/Code Engine Lingo Needed)

The true power of this MCP server is that you don't need to know Docker or Code Engine commands. You can simply state your goal, and the LLM will discover the environment, run the pipeline, and fix issues autonomously.

Here is an example interaction from a real session:

User:

"I have an app in the developer-splash folder. Deploy it to my Code Engine project."

Assistant's Autonomous Thought Process:

1. Discovery: "Let me check what projects and namespaces exist... Found project my-project and namespace my-namespace."
2. Prerequisites: "No pull secret in this project yet. I'll get the API key from the .env file and create the secret icr-pull-secret."
3. Execution: "Now I'll run the full pipeline: build → push → deploy → wait."
4. Validation: "It's deployed but stuck at 'deploying'. Let me check the logs... The container is running but the readiness probe is failing."
5. Self-Correction: "Ah, the sed pattern in the Dockerfile didn't match nginx alpine's default config format for port 80. I'll fix the Dockerfile with a regex-safe sed and rebuild."
6. Completion: "App is live! 🎉 Status: ready."

Assistant Response to User:

"Your app is deployed and live at: https://developer-splash.<subdomain>.<region>.codeengine.appdomain.cloud. I had to fix a minor port configuration issue in your Dockerfile, but it is successfully running now!"

With this MCP server, the AI acts as an expert DevOps engineer pairing with you.

📊 MCP Activity Dashboard (v1.4.0)

See what your AI assistant is doing in real time — tool calls, idle gaps between steps, deploy outcomes, and live app URLs.

flowchart LR
    A[MCP tool call] -->|MCP_ACTIVITY_ENABLED| B[events.jsonl]
    B --> C{Dashboard}
    C -->|VS Code extension| D[Activity tab]
    C -->|Browser| E[localhost:8767]
    D --> F[Deployments tab\ninventory + actions]

Activity logging (on by default)

Since v1.6.0 the server logs every tool start/finish to ~/.code-engine-mcp/activity/events.jsonl — input summaries, pipeline sub-steps (proc_build_push_deploy), result highlights, and optional HTTP smoke-test labels. API keys, passwords, TLS keys, env var values, and secret payloads are redacted. The file rotates at 5 MB.

Optional env in your MCP client config:

"MCP_ACTIVITY_ENABLED": "false",
"MCP_ACTIVITY_EVENTS_PATH": "/custom/path/events.jsonl",
"MCP_ACTIVITY_SESSION_ID": "session:my-chat-001",
"MCP_ACTIVITY_CHAT_LABEL": "Deploy Star Wars splash"

In the VS Code extension, turn logging off with codeEngineMcp.activityEnabled. Restart the MCP server after changing env.

See .env.example for all MCP_ACTIVITY_* variables.

Open the dashboard

Method	How
VS Code extension	Command Palette → IBM Code Engine MCP: Open MCP Activity Dashboard
Browser (dev repo)	npm run dashboard → http://localhost:8767/
Live refresh	On by default in the browser; toggle in-panel or set codeEngineMcp.activityLiveRefresh (extension)

The Activity tab shows a session timeline with tool duration, idle gaps, and a task-outcome banner (status, image, live URL). The Deployments tab lists projects and apps from Code Engine and supports get-details, redeploy, and delete via MCP tools.

Example chat prompt:

"I have a Star Wars splash page in examples/starwars-splash. Deploy it to Code Engine using only MCP tools — build for linux/amd64, push to my ICR namespace, and deploy to my Code Engine project. Show me the live URL when ready."

Open the Activity Dashboard while the assistant runs to watch proc_build_push_deploy progress step by step.

Deploy Your First App

This walks through deploying the included Star Wars splash page example — a static nginx container — entirely through the MCP server.

Apple Silicon users: always build with --platform linux/amd64. Code Engine runs amd64 only.

Step 1 — Build and push the image

cd examples/starwars-splash
podman build --platform linux/amd64 -t us.icr.io/<your-namespace>/starwars-splash:v1.0.0 .
podman push us.icr.io/<your-namespace>/starwars-splash:v1.0.0

Or ask your assistant:

Build examples/starwars-splash as us.icr.io/my-namespace/starwars-splash:v1.0.0 for linux/amd64 and push it

MCP response — build_container_image:

{
  "success": true,
  "command": "podman build --platform linux/amd64 -t us.icr.io/my-namespace/starwars-splash:v1.0.0 ...",
  "build_output": "STEP 1/5: FROM nginx:alpine\nSTEP 2/5: COPY index.html /usr/share/nginx/html/index.html\nSTEP 3/5: RUN sed -i 's/listen  80;/listen 8080;/g' /etc/nginx/conf.d/default.conf\nSTEP 4/5: EXPOSE 8080\nSTEP 5/5: CMD [\"nginx\", \"-g\", \"daemon off;\"]\nSuccessfully tagged us.icr.io/my-namespace/starwars-splash:v1.0.0"
}

Note: Container runtimes (Podman/Docker) write build progress to stderr. The build_output field combines stdout and stderr so you see the full build log.

MCP response — push_container_image:

{
  "success": true,
  "command": "podman push us.icr.io/my-namespace/starwars-splash:v1.0.0",
  "output": "Getting image source signatures\nCopying blobs...\nWriting manifest to image destination"
}

Step 2 — Create a registry pull secret

Ask your assistant (once per project):

Create a registry secret called icr-pull-secret in project <project-id> for us.icr.io using my IBM Cloud API key

Or use the ce_create_secret tool directly:

{
  "project_id": "<your-project-id>",
  "name": "icr-pull-secret",
  "format": "registry",
  "data": {
    "username": "iamapikey",
    "password": "<your-ibm-cloud-api-key>",
    "server": "us.icr.io",
    "email": "user@example.com"
  }
}

MCP response — ce_create_secret:

{
  "name": "icr-pull-secret",
  "format": "registry",
  "resource_type": "secret_registry_v2",
  "created_at": "2026-05-08T22:10:00Z",
  "project_id": "<your-project-id>"
}

Step 3 — Deploy the application

Ask your assistant:

Deploy us.icr.io/my-namespace/starwars-splash:v1.0.0 to Code Engine project <project-id>
as app "starwars-splash" using pull secret icr-pull-secret, min 1 instance

Or use the ce_create_application tool:

{
  "project_id": "<your-project-id>",
  "name": "starwars-splash",
  "image": "us.icr.io/<your-namespace>/starwars-splash:v1.0.0",
  "image_secret": "icr-pull-secret",
  "scale_min_instances": 1,
  "scale_max_instances": 3
}

MCP response — ce_create_application:

{
  "name": "starwars-splash",
  "resource_type": "app_v2",
  "status": "deploying",
  "image_reference": "us.icr.io/my-namespace/starwars-splash:v1.0.0",
  "image_secret": "icr-pull-secret",
  "image_port": 8080,
  "scale_min_instances": 1,
  "scale_max_instances": 3,
  "scale_cpu_limit": "1",
  "scale_memory_limit": "4G",
  "endpoint": "https://starwars-splash.<subdomain>.us-south.codeengine.appdomain.cloud",
  "status_details": {
    "latest_created_revision": "starwars-splash-00001",
    "latest_ready_revision": null
  }
}

Step 4 — Check deployment status

Get details for the starwars-splash app in project <project-id>

This calls ce_get_application and returns the public URL once the app reaches ready status.

List the running instances of starwars-splash in project <project-id>

This calls ce_list_app_instances (pass instance_name for one instance; ce_get_app_instance still works) and shows:

• Instance name and revision
• Container status (running / pending / failed)
• Restart count
• Started-at timestamp
• CPU and memory allocation

MCP response — ce_get_application (once ready):

{
  "name": "starwars-splash",
  "status": "ready",
  "image_reference": "us.icr.io/my-namespace/starwars-splash:v1.0.0",
  "image_port": 8080,
  "scale_min_instances": 1,
  "scale_max_instances": 3,
  "scale_cpu_limit": "0.5",
  "scale_memory_limit": "1G",
  "region": "us-south",
  "endpoint": "https://starwars-splash.<subdomain>.us-south.codeengine.appdomain.cloud",
  "status_details": {
    "latest_created_revision": "starwars-splash-00001",
    "latest_ready_revision": "starwars-splash-00001"
  }
}

Step 5 — Map a custom domain (optional)

To serve the app at your own domain (e.g. myapp.example.com) you need a TLS certificate. The IBM Code Engine REST API always requires a real certificate — IBM's Console "Platform managed" option is not available via the API.

5a — Get a Let's Encrypt certificate (certbot)

# Install once
brew install certbot

# Request cert — certbot will print a DNS TXT challenge value
mkdir -p ~/certbot/{config,work,logs}
/opt/homebrew/bin/certbot certonly --manual --preferred-challenges dns \
  -d <your-domain> --agree-tos --no-eff-email --email you@example.com \
  --config-dir ~/certbot/config --work-dir ~/certbot/work --logs-dir ~/certbot/logs

Certbot will pause and ask you to add a TXT record:

Add TXT record: _acme-challenge.<your-domain> = <challenge-value>

Verify propagation, then press Enter. Certbot writes:

• ~/certbot/config/live/<your-domain>/fullchain.pem
• ~/certbot/config/live/<your-domain>/privkey.pem

5b — Create the TLS secret in Code Engine

Ask your assistant:

Create a TLS secret called starwars-tls in project <project-id>
using cert ~/certbot/config/live/myapp.example.com/fullchain.pem
and key ~/certbot/config/live/myapp.example.com/privkey.pem

This calls ce_create_tls_secret_from_pem — reads the PEM files from disk and stores them as a Code Engine tls secret.

MCP response — ce_create_tls_secret_from_pem:

{
  "name": "my-tls",
  "format": "tls",
  "resource_type": "secret_tls_v2",
  "created_at": "2026-05-08T22:30:00Z",
  "project_id": "<your-project-id>"
}

5c — Create the domain mapping

Ask your assistant:

Map domain myapp.example.com to app my-app
in project <project-id> using TLS secret my-tls

This calls ce_create_domain_mapping and returns the cname_target.

MCP response — ce_create_domain_mapping:

{
  "name": "myapp.example.com",
  "status": "ready",
  "cname_target": "custom.<subdomain>.us-south.codeengine.appdomain.cloud",
  "component": {
    "resource_type": "app_v2",
    "name": "my-app"
  },
  "tls_secret": "my-tls",
  "region": "us-south"
}

5d — Update your CNAME

In your DNS provider, set:

myapp.example.com CNAME custom.<subdomain>.us-south.codeengine.appdomain.cloud

Use the cname_target value returned in 5c (it uses the custom. prefix, not the app name).

Once DNS propagates, https://<your-domain> serves the app with a valid TLS certificate.

Certificate renewal: Let's Encrypt certs expire after 90 days. Re-run certbot to get updated PEM files, then ask Copilot to run ce_create_tls_secret_from_pem with mode renew — it patches the existing secret in-place so your domain mapping continues working without any changes. ce_renew_tls_secret_from_pem still works if called directly.

Full one-shot prompt

I have a Star Wars splash page in examples/starwars-splash.
Build it for linux/amd64 as us.icr.io/my-namespace/starwars-splash:v1.0.0,
push it, then deploy it to Code Engine project <project-id> with pull secret icr-pull-secret.
Tell me the public URL and confirm the instance is running.

---

🔒 Security & Transport Model

Two kinds of credential

• IBM Cloud API key (IBMCLOUD_API_KEY): how the server talks to IBM Cloud. It stays on the server process. Callers never receive it.

• MCP caller credentials: who may call a tool on this server. They are never sent to IBM Cloud.

  • the web admin session (/admin, built-in user admin with ADMIN_PASSWORD),
  • a user, sent as Authorization: Basic user:password (server_users),
  • an MCP API key, sent as Authorization: Bearer cemcp_… (server_api_keys; the secret is shown once).

  Each credential has the scopes read, write, admin. Over stdio there are no headers; set MCP_API_KEY, or MCP_USERNAME and MCP_PASSWORD, in the server environment. Details: Tool scope and authentication.

Transports

Mode	How to start	Endpoints
stdio (default)	the MCP client spawns node build/index.js	none; the client owns stdin and stdout
HTTP	MCP_MODE=http PORT=8787 HOST=127.0.0.1 node build/index.js	POST/GET/DELETE /mcp (Streamable HTTP), GET /sse and POST /messages (legacy SSE), /health, /admin, /test, /tools, /log, /docs

One server is better than several. A stdio server is started by each client, so every IDE window gets its own process with its own memory. Its audit trace, rate limits, sessions and runtime settings are not visible to the web UI of another process. Run one HTTP server and point every client at it when you want the trace, logging, users, keys and settings to line up. The VS Code extension does exactly that by default.

Local server hardening

• Bind to 127.0.0.1 unless the server is meant to be remote. On a public bind (HOST=0.0.0.0, a container) the built-in admin is disabled until ADMIN_PASSWORD is set.
• MCP_LOCAL_ONLY=true makes the server answer only requests whose Host is localhost, 127.0.0.1 or [::1], so a web page that rebinds its own name to 127.0.0.1 cannot reach it. The VS Code extension sets it for the server it starts. Leave it off behind a reverse proxy.
• The admin cookie is HttpOnly and SameSite=Strict; five failed sign-ins lock an address out for ten minutes; the settings export leaves secrets out.

---

🌐 Host Any MCP Server on Code Engine

You can use this MCP server to deploy another MCP server to Code Engine — no CLI, no Dockerfile, no YAML. The key ingredient is supergateway: a tiny bridge that wraps any STDIO-based MCP server as an HTTP + SSE endpoint, making it accessible to any remote client.

Credit: Jeremias Werner & Enrico Regge — IBM Cloud Code Engine

Your AI Assistant
    │  MCP JSON-RPC (STDIO, local)
    ▼
code-engine-mcp-server  ──► ce_create_application
                                     │
                                     ▼
                         Code Engine App
                         image: docker.io/supercorp/supergateway
                         args:  --stdio "npx -y <any-mcp-server>"
                                --outputTransport sse
                                     │  HTTPS + SSE  (public URL)
                                     ▼
                         Any remote MCP client
                         (Claude Desktop, Cursor, VS Code, …)

Any STDIO MCP server becomes a remotely accessible, auto-scaling cloud service — with no custom infrastructure.

This example deploys @tokenizin/mcp-npx-fetch, an MCP server that lets an AI assistant fetch content from public URLs.

The example files live in examples/mcp-server-supergateway/.

Step 1 — Deploy the hosted MCP server

Ask your assistant:

Deploy a hosted MCP fetch server to my Code Engine project <project-id>.
Use image docker.io/supercorp/supergateway on port 8000.
Startup args: --stdio "npx -y @tokenizin/mcp-npx-fetch" --outputTransport sse
Name it "mcp-fetch-server". No pull secret needed.

This calls ce_create_application:

{
  "project_id": "<your-project-id>",
  "name": "mcp-fetch-server",
  "image": "docker.io/supercorp/supergateway",
  "port": 8000,
  "run_args": ["--stdio", "npx -y @tokenizin/mcp-npx-fetch", "--outputTransport", "sse"]
}

MCP response — ce_create_application:

{
  "name": "mcp-fetch-server",
  "resource_type": "app_v2",
  "status": "deploying",
  "image_reference": "docker.io/supercorp/supergateway",
  "image_port": 8000,
  "scale_min_instances": 0,
  "scale_max_instances": 10,
  "endpoint": "https://mcp-fetch-server.<subdomain>.<region>.codeengine.appdomain.cloud",
  "status_details": {
    "latest_created_revision": "mcp-fetch-server-00001",
    "latest_ready_revision": null
  }
}

No pull secret is needed — docker.io/supercorp/supergateway is a public image. Code Engine scales to zero when idle; you pay only for actual requests.

Step 2 — Wait for the app to be ready

Ask your assistant:

Wait for mcp-fetch-server in project <project-id> to be ready

This calls ce_wait_for_app_ready:

{
  "project_id": "<your-project-id>",
  "app_name": "mcp-fetch-server",
  "timeout_seconds": 120
}

MCP response — ce_wait_for_app_ready:

{
  "app_name": "mcp-fetch-server",
  "status": "ready",
  "endpoint": "https://mcp-fetch-server.<subdomain>.<region>.codeengine.appdomain.cloud",
  "elapsed_seconds": 34,
  "poll_history": [
    { "attempt": 1, "status": "deploying", "elapsed_seconds": 10 },
    { "attempt": 2, "status": "deploying", "elapsed_seconds": 20 },
    { "attempt": 3, "status": "ready",     "elapsed_seconds": 34 }
  ]
}

Step 3 — Verify the running instance

Ask your assistant:

List the running instances of mcp-fetch-server in project <project-id>

This calls ce_list_app_instances:

MCP response — ce_list_app_instances:

{
  "instances": [
    {
      "name": "mcp-fetch-server-00001-deployment-abc123",
      "revision": "mcp-fetch-server-00001",
      "status": "running",
      "restart_count": 0,
      "started_at": "2026-05-09T12:01:44Z"
    }
  ]
}