Modern AI tools can generate code and explain logic. Real mainframe work requires more than code. A developer must read datasets, submit jobs, trigger builds, and check logs across systems.

Large language models (LLMs) can plan tasks, but they cannot access real systems on their own. The Model Context Protocol (MCP) provides a standard way to connect AI tools to data sources and services. MCP allows an AI system to discover tools, call them, and work with live data instead of static files.

This article shows how IBM Bob uses MCP to move from code analysis to real system execution. You start with a local workspace, enable MCP, and then run workflows on a live IBM z/OS system. The examples show how Bob connects to z/OS system resources and completes tasks in a single flow.

How Bob connects reasoning to z/OS system actions

The following diagram shows how Bob connects planning, communication, and execution when MCP is active. It explains how a request moves from natural language input to real actions on a z/OS system.

LLM, Protocol, and MCP architecture connecting AI reasoning to IBM Z system actions

The LLM acts as the reasoning system. The LLM analyzes the request, creates a plan, and decides which steps are required. The protocol layer carries instructions between the LLM and system tools. The MCP defines how Bob sends requests and receives results. This layer ensures consistent communication across tools and services.

Then, MCP tools execute actions on the z/OS system. These tools access datasets, submit JCL jobs, run builds, and retrieve job output. The diagram shows examples such as dataset access, build execution, and job monitoring. These actions connect directly to the IBM Z environment and return results to Bob.

Why this matters for mainframe teams

Most enterprise mainframe work involves multiple steps across tools and systems. watsonx Code Assistant for Z helps with each task in isolation. Bob, with MCP, connects those tasks and runs the workflow from start to finish.

Both tools use AI, but they support different ways of working. watsonx Code Assistant for Z helps with individual coding tasks. Bob completes full workflows across the z/OS system.

Before MCP: Limited z/OS access

Most users begin with a workspace where MCP is not active. The Bob IDE includes the IBM Z Open Editor extension, and the .vscode folder contains an mcp.json file. The MCP server is not running, so Bob does not yet have access to the z/OS system.

Explore the IBM Z Open Editor GitHub repository for prerequisites and feature list.

Example: asking Bob to list Zowe profiles

To see this limitation, enter a simple request such as list the Zowe profiles in the Bob IDE chat panel.

User typing list the zowe profiles in the Bob IDE chat input panel with mcp.json open in the editor

Bob returns an error. The message indicates that the MCP server is not running or cannot be reached. Bob cannot retrieve Zowe profiles because the MCP server is not active. This is the expected behavior before MCP is started.

Bob error message indicating MCP server is not running or unreachable

Limitations

Without MCP, Bob can work only with local files. Bob cannot access live z/OS resources. Bob cannot read datasets, submit jobs, access Zowe profiles, retrieve job output, use live system data.

All actions are limited to source code in the local workspace. This behavior confirms that the connection to the z/OS system is not active.

Set up MCP for z/OS system access

MCP setup connects Bob to the z/OS system. The setup requires two configuration files and one running server process.

Enable MCP in Bob IDE Settings under IBM Z Open Editor -> Extensions. The checkbox activates the MCP server and requires a .vscode/mcp.json file in the workspace.

For complete MCP server setup details, see the IBM Z Open Editor advanced capabilities documentation.

Add the required MCP configuration to the settings.json file in Bob IDE with zopeneditor.mcp.enabled: true and the chat.mcp.serverSampling block referencing the zopeneditor-local server.

 {
     "zopeneditor.mcp.enabled": true,
     "chat.mcp.serverSampling": {
         "zopeneditor-mcp-demo/.vscode/mcp.json: zopeneditor-local": {
             "allowedModels": []
         }
     }
 }

Bob IDE settings.json showing zopeneditor.mcp.enabled set to true with OUTPUT panel

Create an mcp.json file in the .vscode folder in your workspace and register the zopeneditor-local MCP server at localhost:63299. This file defines the MCP server connection details for Bob.
```
 {
   "servers": {
     "zopeneditor-local": {
       "url": "http://localhost:63299/mcp"
     }
   }
 }
```
Start the Z Open Editor MCP server. Bob requires a running MCP server to connect to the z/OS system. If the server is not running, Bob returns a connection error. The server process must be started before the connection activates.
Start the MCP server and run a test request. Ask Bob to list Zowe profiles. The request should succeed.

You can also check the mcp.json file header. A successful connection shows Running | 62 tools, which indicates that Bob has full access to the z/OS ecosystem profile.

These 62 MCP tools support common z/OS tasks, including:
- Dataset access
- Job submission
- Job output retrieval
- Build execution
- System interaction
  
  The following screen shows the 62 MCP tools are loaded from zopeneditor-local, including DBB builds, RSE API, Wazi Deploy, ZCodeScan, job management, and Zowe profile operations.

Verify live z/OS access after MCP setup

After MCP setup, Bob connects to a live z/OS system. Bob no longer works only with local files. Bob can access system resources and run real tasks, similar to a developer using Zowe tools.

Example: asking Bob to list Zowe profiles

Run the same request to list Zowe profiles. This time, Bob lists all configured Zowe profiles directly from z/OS via the zopeneditor-local MCP server. Example profiles include:

zosmf_ecosystem
zosmf_telum
zosmf_dallas
zosmf
rse
zOpenDebug
ssh
global_base

Bob successfully listing Zowe profiles from the live z/OS environment via MCP

Example: asking Bob to list dataset members

This next step shows deeper system access. Ask Bob to list members in the dataset MOHSYED.COBOL using the zosmf_ecosystem profile. Bob retrieves dataset members directly from z/OS via the zopeneditor-local MCP server. The MOHSYED.COBOL dataset in the zosmf_ecosystem profile contains the following dataset members: DBGSMPL, HELLO, and LGICDB01.

Bob retrieving dataset members DBGSMPL HELLO LGICDB01 from MOHSYED.COBOL in the zosmf_ecosystem profile via MCP

After MCP: Full z/OS workflow automation

With MCP active, Bob can work directly with live z/OS data. Bob can browse datasets, access dataset members, submit jobs, retrieve spool output, and trigger builds

All actions use natural language input. No separate terminal or tool is required. The z/OS system becomes part of the same workflow.

Why MCP changes how you work with the z/OS system

The impact of MCP becomes clear when Bob runs the /init command. This command analyzes the full workspace in one step and creates an AGENTS.md file. The file captures project structure, coding patterns, and deployment rules without step-by-step input from the developer.

Bob can complete all 10 /init subtasks and create AGENTS.md for the GenApp IBM Z CICS/Db2 codebase. The file captures program naming conventions, Db2 integration requirements, CICS resources, MVS deployment rules, and screen map definitions.

IBM Bob completing all 10 init tasks and creating AGENTS.md for the GenApp IBM Z codebase

The result shows the scope of Bob analysis. In a single run, Bob:

Identifies the workspace type, such as an IBM Enterprise COBOL for z/OS project with CICS and Db2.
Detects the application, such as the GenApp insurance system.
Analyzes naming conventions.
Documents CICS and Db2 integration requirements.
Captures MVS deployment rules, including PDSE file transfer requirements.

The AGENTS.md file becomes a shared project reference. Bob uses this file to guide future tasks, decisions, and workflows across the codebase.

Run an end-to-end agent z/OS system workflow with Bob

Bob can run a full workflow from a single request. For example, enter: run ZCodeScan and complete the scan, fix, build, and run sequence. Bob breaks this request into multiple tasks and executes them in order. Bob pauses only at key decision points that require developer input.

Watch the video demonstration of Bob MCP integration for z/OS.

Steps 1 and 2: Scan and review results

Bob runs ZCodeScan on the program SAM1.cbl. Bob presents the results in a structured table for review.

The scan identifies eight issues across two rule categories:

AcceptDateTimeRule violations
EvaluateNotIfRule violations

Bob does not apply fixes automatically. Bob presents the findings and asks which severity levels to address. This step keeps control with the developer while Bob handles analysis and prepares the next actions.

Bob displaying ZCodeScan findings table with 8 issues and offering fix options by severity level

Steps 3 to 5: Fix, format, and build

After the developer selects HIGH severity fixes (H1 to H3), Bob applies the changes automatically. Bob updates the COBOL program and reformats the code to match project standards.

Bob then starts an IBM Dependency Based Build (DBB) through MCP. The userbuild-run-user-build MCP tool runs the build for SAM1.cbl. The tool uploads required copybooks to the z/OS system and streams the build log to the Bob IDE output panel.

Bob monitors the build process. If the build fails, Bob identifies the error in the log and suggests a corrective action.

Bob at step 5 of 7 running IBM DBB user build via MCP with build log streaming in the OUTPUT panel

Steps 6 and 7: Submit JCL and verify execution

The final steps complete the workflow on the z/OS system.

Bob submits the run JCL using the zowe-submit-dataset MCP tool. The JCL member PHAUMER.SAMPLE.JCL(RUN) runs as job SAMRUN and receives a job ID.

After execution, Bob calls the zowe-get-all-job-spools-output MCP tool. Bob retrieves all spool output and checks the results to confirm that the job was completed successfully.

Bob requests developer approval before submitting the job. This step ensures that the developer controls all actions that run on the mainframe system.

Bob submitting JCL via Zowe MCP and retrieving job spool output with Approve button

Summary

Mainframe expertise is limited and shrinking. Bob includes this expertise in daily work. Bob understands CICS, DB2, MQ, naming rules, and deployment patterns for a specific application. This embedded knowledge helps teams work at scale.

Bob with MCP serves a different role. Bob acts as an execution partner. It takes a workflow goal and completes analysis, build, and job submission. Bob pauses for human approval at key steps and applies built-in z/OS expertise.

Start with a read-only MCP setup and run the /init command on an existing COBOL codebase. The generated AGENTS.md file provides a clear artifact to review Bob analysis before any code changes.

watsonx Code Assistant for Z helps with individual tasks. Bob runs complete workflows across the system.

Automate IBM Z workflows with Bob and MCP

Automate IBM Z workflows with Bob and MCP