BPM, Workflow, and Case

Come for answers. Stay for best practices. All we’re missing is you.

View Only

Back to Blog List

Deploying and operating Workflow Runtime MCP Server: Architecture patterns, install and configuration considerations

By Bhagyashree Arer posted 07/29/26 08:00 AM

Overview

The Model Context Protocol (MCP) gives AI assistants and agents a standard way to talk to external tools and services. Before MCP, every new AI tool required its own custom connection to every system it needed — time-consuming to build and costly to maintain. With MCP, you define the integration once, and any compatible AI client, whether it's Claude, Cursor, watsonx Orchestrate, or something new, can connect to it immediately.

IBM Business Automation Workflow 26.0.0 introduces the Workflow Runtime MCP Server — a new optional component available in both IBM Cloud Pak for Business Automation 26.0.0 (CP4BA) and IBM Business Automation Workflow (BAW) on containers 26.0.0.0 onwards.

This blog covers deployment architectures, installation, and production-ready features considerations for production environments.

New to Workflow Runtime MCP Server? This is a deployment and operations guide. If you haven't already, start with the conceptual introduction first Managing work with Workflow Runtime MCP Server.

High-level architecture

The Workflow Runtime MCP Server architecture integrates seamlessly with your IBM Business Automation Workflow deployment, acting as a bridge between AI assistants and your workflow environment.

Deployed as cloud-native Kubernetes pods within your Kubernetes cluster, the Workflow Runtime MCP Server translates AI tool requests into authenticated API calls to your workflow systems.

The architecture follows a topology-aware design that adapts to your deployment pattern. Each MCP Server instance runs as a cloud-native Kubernetes pod maintaining connections to either workflow runtime systems or IBM Process Federation Server (PFS).

IBM Process Federation Server (PFS) creates a unified process environment where business users access all their tasks, process instances, case instances, and launchable workflows from a single point — regardless of the backend system storing them and the number of workflow instances.

Deployment scenarios

BAW supports several deployment scenarios — with or without Process Federation Server, or with a workflow authoring environment. The number of MCP Server instances you deploy maps directly to these scenarios. Understanding your deployment topology upfront is key to planning endpoint configuration for your AI clients.

Scenario 1: PFS enabled environment

In environments where Process Federation Server (PFS) is enabled and all Business Automation Workflow(BAW)/Workflow Process Service(WfPS) Runtime instances are federated behind a single PFS endpoint. Here, a single Workflow Runtime MCP Server instance connects to PFS, which in turn fans out queries across all federated runtimes.
PFS does not have to federate every BAW or WfPS runtime in your environment. When only some runtimes are federated, you end up with a hybrid topology: one MCP Server instance connects to PFS to cover the federated runtimes, plus one additional Workflow Runtime MCP Server instance per non-federated runtime connecting directly to each. For example, if `bawins1` and `bawins2` are federated via PFS but `bawins3` is standalone, operator would deploy two Workflow Runtime MCP Server instances — one pointing at PFS and one pointing at `bawins3` — giving your AI clients two endpoint sets to configure. This is the most common real-world topology in large enterprises where not all environments have been onboarded to federation.

Scenario 2: PFS disabled environments

When PFS is not in use, each BAW or WfPS runtime instance operates independently. In this topology, one Workflow Runtime MCP Server instance is deployed per BAW or WfPS runtime — each instance connects directly to its corresponding runtime and provides isolated access scoped to that environment. If you have two BAW instances (`bawins1`, `bawins2`), you will have two MCP Server instances and two sets of endpoints. This aligns with environment boundaries and is common in deployments where runtime isolation is a requirement.
Business Automation Workflow Authoring and Workflow Process Service Authoring will have single Workflow Runtime MCP Server deployed providing the required tools enabling AI Agents to interact with workflows.

Benefits of Workflow Runtime MCP Server

AI-driven workflow automation Business users can interact with workflow systems using natural language through AI tools, reducing the learning curve and making workflow automation more accessible across the organization. Beyond interactive queries, the MCP server also enables AI agents to act autonomously on behalf of users — triggering tasks, retrieving process state etc without human intervention at each turn. This opens the door to fully autonomous workflows where an AI agent monitors conditions and takes action end-to-end, dramatically reducing manual touchpoints in operational processes.
Governance Comprehensive audit logging and OAuth-based authentication ensure that all AI-assisted operations are properly tracked and authorized, supporting your compliance and governance requirements.
Flexible deployment Whether you're running a single workflow environment or a complex federated landscape using Process Federation Server (PFS), the MCP Server adapts to your architecture with dedicated instances for each environment type and purpose.

Installation

Workflow Runtime MCP Server is the optional component provided in the deployments. Installation procedure is in the IBM documentation: Installing Workflow Runtime MCP Server

Security and authentication

User identity propagation: OAuth 2.1 authorization code flow ensures all workflow operations execute under the logged-in user's identity. When you ask "show me all my tasks," the MCP server makes calls as you, leveraging IBM Business Automation Workflow's built-in authorization to return only your tasks.
Secure by default: All communications use SSL/TLS encryption with IBM Automation Foundation's certificate authority, ensuring data protection without additional configuration.
Seamless authentication: The server integrates with IBM Cloud Pak's identity management, providing single sign-on experience for users while maintaining security boundaries.

Production-ready features:

Parameters to configure below features can be found here: Runtime : Workflow Runtime MCP Server configuration parameters and Authoring : Workflow Runtime MCP Server configuration parameters

Health probes: Liveness and readiness checks ensures the operator knows pod health at all times. (Not configurable, mandatory)
High availability: `PodDisruptionBudget` guarantees minimum availability during node maintenance.
Horizontal pod autoscaling: CPU-based auto-scaling keeps latency stable under variable AI tool load.
Rolling updates: Configurable `maxSurge` and `maxUnavailable` parameters for zero-downtime upgrades.
Resource management: Profile-based allocation (Small / Medium / Large) right-sizes CPU and memory per environment.
Audit logging: Optional audit log collection with Filebeat integration for compliance and traceability.
Log level : Configurable console log verbosity (`DEBUG`, `INFO`, `WARN`, `ERROR`).

Monitoring & observability

Instana integration: When Instana is enabled in your cluster, the MCP Server is automatically instrumented for distributed tracing — no manual configuration required. This lets you trace end-to-end request flows from AI client through the MCP Server to the BAW REST APIs. This is also the parameter that can be configured from main Custom Resource.
Access info ConfigMap: Centralized MCP server endpoint information
We have two end point for deployments
→ /process/mcp for process capabilities
→ /case/mcp for case capabilities
Access info can be found in following configmaps:

BAW on containers : bawdeploy-cp4ba-access-info
CP4BA deployments: icp4adeploy-cp4ba-access-info

Authoring:

Process MCP URL: https://cpd-namespace.apps.cluster.com/workflow-runtime-mcp-server-ins1/process/mcp
Case MCP URL: https://cpd-namespace.apps.cluster.com/workflow-runtime-mcp-server-ins1/case/mcp

Runtime with Process Federation Server (PFS):

Process MCP URL: https://cpd-namespace.apps.cluster.com/workflow-runtime-mcp-server-ins1/process/mcp
Case MCP URL: https://cpd-namespace.apps.cluster.com/workflow-runtime-mcp-server-ins1/case/mcp

Runtime without Process Federation Server (PFS) (2 BAW instances: bawins1, bawins2):

After installing the Workflow Runtime MCP Server and configuring the required parameters, you are ready to add the MCP Server to your MCP clients. For detailed instructions, see Getting started with IBM Workflow Runtime MCP Server.

Conclusion

The Workflow Runtime MCP Server in CP4BA 26.0.0 and BAW on containers 26.0.0.0 represents a significant step forward in AI-assisted workflow development and operations. By providing a standardized protocol for AI tools to interact with BAW runtime environments — with OAuth identity propagation, topology-aware deployment, and enterprise-grade security — it is production-ready from day one. Whether your deployment uses Process Federation Server, standalone runtimes, or workflow authoring tools, there is a supported topology that fits your environment.

Acknowledgements:

I would like to express my sincere gratitude to @Ralf Schmauder, @Claudia Zentner and @SUNIL SATTI who provided valuable guidance and feedback throughout the MCP capability and creation of this blog.