What MCP Means for IBM i: Connecting AI Assistants to Db2 for i Safely
Roni Ström, maintainer of an open-source Db2 for i MCP server, compares the ways to connect AI assistants to IBM i and the controls to put in place before production
For two years, AI assistants have had one common way of reaching business systems: the Model Context Protocol (MCP). Anthropic published it in November 2024, and chat assistants (Claude, ChatGPT) and coding assistants (Cursor, GitHub Copilot, Claude Code, OpenAI’s Codex, IBM Bob) all speak it. In December 2025, it passed to the Linux Foundation’s Agentic AI Foundation, so it is no longer one vendor’s interface.
IBM i shops are starting to try it, and the community has several ways to do it, but little neutral guidance on the choices. This article gives IBM i managers and technical leads a way to judge them. I maintain one of the two open-source servers discussed here, so I have tried to describe both fairly and highlight the trade-offs.
What an MCP Server Does
MCP is a client-server protocol. The client is the assistant application: a chat assistant on the desktop (Claude, ChatGPT), a coding assistant (Cursor, GitHub Copilot, Claude Code, Codex, IBM Bob), or a hosted assistant such as claude.ai that reaches the server over the network. The server is a small program that exposes tools: named operations with a description and a typed input, such as list tables, describe table or run a query. The client gives the tool list to the language model. When the model decides a tool would help, the client sends the call to the server, the server runs it, and the result goes into the model’s context as text.
A few things follow from this that are easy to miss. The model never holds a database connection or a password. The server does, and the model only ever sees what the tools return. The tool list is therefore the attack surface. A server that offers list and describe tools exposes metadata and nothing more, while a server with a free-form SQL tool exposes whatever that tool lets through. Whatever a tool returns is sent to the assistant’s provider. With a hosted assistant, the query rows leave your network, so writes are not the only concern. What the assistant may read, and who gets to see the answer, matters as much.
MCP servers run in two ways. A local client can start the server as a child process on the same machine, which is how most developers use it: one server per laptop, credentials in the developer’s environment. Or one server runs as an HTTP service, and many clients connect to it, which is what hosted assistants need and what lets a team share one deployment.
Two Architectures, and a Third Approach
For Db2 for i, there are two actively maintained open-source servers, and they start from different places (Figure 1).
IBM’s IBM i MCP Server (github.com/IBM/ibmi-mcp-server, Apache 2.0) connects through Mapepire, IBM’s open-source database server for IBM i. Mapepire runs as a daemon on IBM i itself, installed with yum and started with Service Commander, and listens on port 8076 for WebSocket connections over TLS. The MCP server runs off the system, with Node.js or in a container, and talks to that daemon. Its tools are defined in YAML: a SQL statement with named parameters becomes a tool. IBM ships collections for performance, jobs, security, storage and the database catalog, most of them built on the QSYS2 services, and seven built-in tools add a text-to-SQL workflow behind startup flags.
The project also includes a command-line tool that runs the same YAML tools from a terminal and agent examples for Agno, LangChain and Google ADK. What it needs: Mapepire installed and kept running on each IBM i, a certificate for it and port 8076 open from wherever the MCP server runs.
mcp-server-db2i (github.com/Strom-Capital/mcp-server-db2i, MIT), the project I maintain, installs nothing on the IBM i. It runs on a laptop, a server or in a container and connects through the database host servers the system already runs, using the IBM i Access ODBC driver or the JT400 JDBC driver. That is the same path Access Client Solutions and most Windows reporting tools use. Where only SSH is open, it logs in over SSH and starts Mapepire inside that session as the signed-in user, so there is no daemon and no new port.
Its tools cover the catalog (tables, columns, indexes, routines, DDL and dependencies) and a read-only query tool, plus business SQL tools loaded from YAML in the same way as IBM’s. It enforces read-only access and cannot be configured otherwise. What it needs: a machine to run Node.js, a user profile and network access to the host server ports or to SSH.
The two projects have converged on several ideas. Both load curated SQL from YAML, both validate statements with the IBM i parser and both can sign users in as themselves. The real difference is where the connection lands: a new gateway service on the IBM i or the host servers that are already there.
The third option is a 5250 session. A few MCP servers wrap a terminal emulator, so the assistant reads the screen, types into fields and presses function keys the way a person would. Whatever the user profile can do at a green screen, the assistant can do too, including running commands and updating data, and nothing checks what it types. That is useful for testing an interactive program. It is not the way to query production data.
Table 1 sums up what each approach asks of you.
| IBM i MCP Server (IBM) | mcp-server-db2i | 5250 session servers | |
| Installed on the IBM i | Mapepire daemon (yum, Service Commander), a TLS certificate | Nothing | Nothing |
| Connection path | WebSocket over TLS to port 8076 | ODBC or JDBC database host servers, or SSH on port 22 | TN5250 over Telnet: plain (port 23), TLS (port 992) or tunneled through SSH |
| Tools | YAML SQL tool sets for performance, jobs, security, storage and the catalog; built-in text-to-SQL tools behind flags; a CLI | Catalog tools, a read-only query tool, business SQL tools from YAML, exports | Read the screen, send keys |
| Writes | Off for free-form SQL by default; a setting allows them | Not possible | Whatever the profile can do |
| Per-user sign-in | IBM i authentication mode with encrypted credentials and tokens; external OAuth or a gateway | Built-in OAuth 2.1 sign-in with the user’s IBM i profile | The sign-on screen |
| Runs on | Node.js or a container, off the IBM i | Node.js or a container, off the IBM i | Off the IBM i |
| License | Apache 2.0 | MIT | Varies |
Table 1. What each approach asks of an IBM i shop, as documented by the projects in October 2026.
The Controls That Matter Before Production
An assistant told “only run SELECT statements” will usually comply. That is a prompt, not a control. Before anyone connects an assistant to a production library (schema), the server should enforce the following (Figure 2).
Read-only, enforced in layers. Both servers allow only SELECT statements in free-form SQL by default, but they get there differently. IBM’s execute tool stays off until the server is started with a flag, and an administrator can change a setting to let it run updates as well. mcp-server-db2i has no such setting. Its validator parses each statement and rejects anything that is not a query. It then asks IBM i’s own parser, QSYS2.PARSE_STATEMENT, to confirm the statement type. The database connection itself is opened read-only, so even a statement that got past both checks would fail in the driver. The same validator rejects QCMDEXC, a second statement after a semicolon and the SQL services that send data off the system over HTTP or write to the IFS.
A library allowlist. Object authority is the control that holds, but a profile that can read fifty libraries over ODBC should not expose all fifty to a chat. In mcp-server-db2i, a schema allowlist is checked against the names the IBM i parser returns for each statement, and in IBM’s server the curated YAML tools name their libraries. Use both the list and a user profile with authority to only those libraries.
Validation that catches mistakes, not only abuse. A model will invent a column name now and then. A validation tool that checks tables, columns and routines against the catalog without running the statement saves a failed query, and both servers have one.
Query timeouts. A row limit only caps what comes back. It does nothing about the work the IBM i does to produce those rows. A SELECT that joins two large files on columns without an index can hold a processor for a long time whether it returns 10 rows or 10,000, and the IBM i keeps running the statement after the client has given up on it. The server should cancel such a statement on the IBM i itself, not just stop waiting for it. The ODBC driver can do that with SQLCancel. Over JDBC or Mapepire, it calls QSYS2.CANCEL_SQL, and the profile that makes the call needs *JOBCTL or the QIBM_DB_SQLADM function usage.
Column masking. Db2 row and column access control (RCAC) is the control that holds. A mask in the MCP server changes what the assistant receives, not what the profile can read with another client. It still earns its place, because it keeps an email address or an account number out of a chat transcript. Make sure the server also rejects UPPER(EMAIL) and column aliases, or the mask is decorative.
An audit log. One line per tool call: who, which tool, which system, a hash of the SQL, how many rows and whether it succeeded or which check refused it. Hash the SQL by default, because a statement often contains customer values and the audit file should not become a second copy of the data. Record sign-ins too, failed ones included.
Rate limits. Per user, on tool calls and on the sign-in endpoint.
Identity: A Shared Profile, or Each User as Themselves
The first MCP setup is usually one developer, a local server and that developer’s own profile. It rarely stays that way, because the users are no longer only developers. People in sales, purchasing, service, manufacturing and finance ask the same assistants about the same data, and they cannot be expected to install a server, keep a driver current or set a library allowlist. The IBM i team sets up the server once and shares it. That is where the identity question arrives (Figure 3).
The simplest way to share a server is one service profile, with its password in the server’s configuration, so every query from every user runs under that profile. It works, and it has a price. The profile must be authorized for everything anyone might ask about, which usually means more authority than any one person has. On the IBM i, the audit journal sees a single user for everything the assistant does. Only the server’s own log can tell people apart, and only if it records who made each call.
The alternative is for each person to sign in with their own IBM i profile, so object authority applies exactly as it does in a 5250 session. Both servers support this over HTTP. IBM’s server has an IBM i authentication mode: The client encrypts the user’s credentials to the server’s RSA key, and the server checks them against the IBM i. It returns a token tied to that user’s own connection pool, with a one-hour default lifetime. mcp-server-db2i includes an OAuth 2.1 authorization server: The user’s browser opens a sign-in page for an IBM i profile and password, and the token the client receives is bound to those credentials and the chosen system. Each refresh re-checks the password, so a disabled profile ends the session.
How the token is obtained matters for hosted assistants. A connector in claude.ai or ChatGPT cannot send a static header or call a custom login endpoint. It only knows the OAuth flow from the MCP specification. So it needs either a server that is its own OAuth authorization server, or an OAuth provider and a gateway in front of the server. IBM documents the gateway route with its MCP Context Forge and an external OAuth issuer.
Hosted assistants also change the network picture. The assistant reaches your MCP server over the internet, so the server needs HTTPS, an allowlist of the assistant’s outbound address ranges, and a private path to the IBM i. Neither the host server ports nor port 8076 should ever be reachable from the internet.
Where It Helps Today, and Where It Does Not
Developers get the most out of it today. Without leaving the editor, someone writing SQL or RPG with Cursor, Copilot or IBM Bob can ask for a table’s columns, the DDL, the programs that depend on a file or the indexes the optimizer has been asking for; the assistant no longer has to guess column names.
Business users are the other group I see picking this up, and their questions are usually the ones nobody has written a report for. A sales manager wants to know how many open orders a customer has. Purchasing wants to see which suppliers delivered late this month. The YAML tools on both servers make this reasonable. Someone on the IBM i team writes each query once, with the status codes and the deleted-row filter that the existing reports already use, and the assistant calls that tool rather than writing the SQL itself.
Administrators have IBM’s tool sets, which put questions about jobs, storage, security and performance to QSYS2 in plain language.
It does not replace governed reporting. A conversation is not a reconciled report: The answer depends on how the question was worded and on which rows the model chose to exclude; the month-end numbers still come from the finance system. Treat the assistant as a way to explore and to draft, and its figures as something to confirm.
Start small—a test system, one library, a metadata-only mode with the query tool disabled, and a low-privilege profile. Widen from there, one library at a time, after reading the audit log.
Five Questions to Ask Any MCP Server for IBM i
- What has to be installed, opened and maintained on the IBM i?
- Does the server enforce read-only access, and can an administrator turn it off?
- Which libraries can it reach, and how is that limited beyond object authority?
- Does each user sign in with their own IBM i profile, and what does the audit log record?
- What stops a runaway query, and where does the data go when a tool returns it?
Both open-source servers answer these questions in their documentation. The answers differ, and so will the right choice from one shop to the next.
This article was produced with the assistance of AI tools and reviewed and edited by TechChannel staff.