Db2 for i MCP server: IBM's or the read-only one for analysts?

Someone in finance has seen a demo of Claude answering questions in plain English, and now they want it pointed at the ERP. On IBM i the plumbing for that is a Db2 for i MCP server, and there are now two serious open-source choices: IBM’s ibmi-mcp-server and Roni Ström’s read-only mcp-server-db2i. Which one you pick changes the setup work and the guardrails. It changes less about the risk than either README suggests, because the control that holds is the IBM i user profile you hand the server.

We read both projects’ documentation and security notes as of October 19, 2026. We did not run either against a live partition, so treat the setup details below as what each project says it does.

The two servers in one paragraph each

IBM ibmi-mcp-server (@ibm/ibmi-mcp-server, version 0.6.2 on npm, Apache 2.0). IBM’s project, spearheaded by Jesse Gorzinski, according to IT Jungle. Its core idea is curated tools: you write SQL statements in YAML files, give them typed parameters, and the model can only call those tools and fill in the parameters. It ships toolsets for performance, security, system administration and developer object statistics, agent examples for Agno, LangChain and Google ADK, and a sibling ibmi CLI that runs the same YAML. It talks to Db2 for i through Mapepire, which has to be running on the IBM i. It is also the route we recommended over screen-driving in Copilot computer use on IBM i.

mcp-server-db2i (version 3.8.1 on npm, MIT). Ström built it in January because, as he wrote in a blog post IT Jungle quoted, “‘the model promised not to’ isn’t a control.” Its core idea is ad hoc querying that cannot write: the model can browse schemas, describe tables and run its own SELECT statements, and everything else is refused. It has grown fast, with 20 tools in the README, OAuth sign-in for claude.ai custom connectors, column masking, an audit log, YAML business tools of its own, and three drivers: IBM i Access ODBC by default, JT400 JDBC, or Mapepire over SSH.

Both speak MCP over stdio and HTTP, and both work with Claude Desktop, Claude Code and Cursor. Ström’s README lists IBM’s server as the official option, and he has said where it fits better than his own, which is a good sign about both projects.

What “read-only” means in each Db2 for i MCP server

This is where the two differ most, and where reading only the README headlines will mislead you.

	mcp-server-db2i	IBM ibmi-mcp-server
Free-form SQL tool	`execute_query`, on by default	`execute_sql`, off by default (`IBMI_ENABLE_EXECUTE_SQL=false`)
Write statements	Always refused	Refused while `IBMI_EXECUTE_SQL_READONLY=true` (the default); allowed if set to false
Statement check	Parser, then a text scan, then `QSYS2.PARSE_STATEMENT` on the IBM i	`PARSE_STATEMENT` validation on `execute_sql`, per the config docs
Connection	Opened read-only (JDBC `access=read only`, ODBC `CONNTYPE=2`)	Not documented as read-only
Curated tools	YAML business tools, same checks as `execute_query`	YAML tools run the SQL the author wrote
Row and time limits	1,000 rows default, 10,000 max, 120-second cancel on the IBM i	Per-tool row fetch settings, 30,000-row pagination ceiling

mcp-server-db2i stacks four layers. A parser rejects anything that is not a query. A text scan rejects a second statement after a semicolon, data-change shapes such as INSERT INTO buried in a subquery, QCMDEXC, and the IBM i services that send data off the box or write to the IFS, like the HTTP and email functions. IBM i then parses the statement itself with QSYS2.PARSE_STATEMENT, which needs 7.3 with the Db2 PTF group at level 3, or 7.4 and later. And the connection is opened read-only, so the database refuses a write even if all three checks were fooled. The project is candid about the one exception: get_object_ddl and the query-cancel call use a separate connection that is not marked read-only, running only fixed statements.

IBM’s server takes a different position. Its default posture is no free-form SQL at all, only the YAML tools you wrote. That is a strong default, because a model that can only call system_status or an order lookup you wrote can’t wander. But it moves the guardrail into your YAML. If someone writes an UPDATE into a tool definition, the model can call it. And execute_sql, once enabled, is one environment variable away from accepting writes. IBM’s own .env.example says to enable it “only in development or trusted environments.”

Neither approach is wrong. They answer different questions. Ström’s server assumes the model will write its own SQL and makes that safe. IBM’s assumes you’d rather the model didn’t write SQL at all.

Setup: what each Db2 for i MCP server installs, and where

The practical difference most shops will feel first is on the IBM i side.

IBM’s server needs Mapepire on the box. That is yum install mapepire-server, yum install service-commander, then sc start mapepire, plus an inbound firewall rule for port 8076. On the client or server host you need Node.js 18 or later. In a lot of IBM i shops, a new listening port on production is a change-control ticket, and Mapepire is new enough that IT Jungle notes most people don’t have it installed yet. Note that the quickstart sets DB2i_IGNORE_UNAUTHORIZED=true, which skips TLS certificate checks. IBM’s own production example sets it to false. Do the same.

mcp-server-db2i needs nothing new on the IBM i with its default driver. It uses the IBM i Access ODBC driver on the machine running the server (Node.js 22 or later, plus unixODBC), which reaches the database host servers your ACS and ODBC users already hit. The JT400 option swaps ODBC for a Java runtime. The Mapepire option is for systems where only SSH is reachable, and it uploads a JAR to the user’s $HOME/.mapepire on first connect, so it does touch the box.

One detail to plan for: the 120-second query cancel in mcp-server-db2i works with any profile on the ODBC driver, but on JT400 and Mapepire it calls QSYS2.CANCEL_SQL, which needs *JOBCTL or the QIBM_DB_SQLADM function usage. A locked-down profile without either gets a timeout error while the query keeps running on the IBM i. If you want a low-privilege profile and a working cancel, stay on ODBC.

Which one fits which job

Pick by what the person asking to connect Claude to the IBM i actually wants to do.

An analyst wants to ask business questions of ERP tables. mcp-server-db2i. Ad hoc SELECT with schema browsing is the job, and its validator, read-only connection, schema allowlist and column masking are built for exactly that.
Operations wants an agent to answer “what’s eating CPU” or “which jobs are in MSGW.” IBM’s server. Its shipped performance and system-admin toolsets are pre-written SQL services queries, which is what you want an operations agent calling.
You’re building a custom agent in LangChain, Agno or Google ADK. IBM’s server, for the examples and the CLI.
You can’t open a new port on production this quarter. mcp-server-db2i on ODBC.
You want claude.ai users to connect without installing anything. mcp-server-db2i’s HTTP mode with OAuth, where each user signs in with their own IBM i profile. IBM’s HTTP authentication is labeled beta.

Running both is reasonable. Plenty of shops will end up with IBM’s server for operations and Ström’s for data questions.

The control that holds: build the profile first

Both projects say this in their own docs, and it is the most important line in either. mcp-server-db2i’s security page states that its schema allowlist “does not replace IBM i object authority,” and that Db2 row and column access control is the masking that actually holds. IBM’s docs say queries run with the authenticated user’s credentials and respect object authority. Translation: the server’s checks are a second layer. The first is the profile.

That matters more on IBM i than people expect, because both servers come in through database interfaces, not 5250 menus. An initial menu, LMTCPB(*YES) and a locked-down green-screen application do nothing to stop SQL from reading a file the profile has authority to. We made the same point about ODBC exposure in AI just killed security through obscurity on IBM i, and an MCP server is one more client on that path.

A minimal profile for an analyst-facing server looks like this:

CRTUSRPRF USRPRF(AIREAD) PASSWORD(...) USRCLS(*USER) SPCAUT(*NONE) +
          GRPPRF(*NONE) INLMNU(*SIGNOFF) LMTCPB(*YES) +
          TEXT('MCP read-only service profile')

GRTOBJAUT OBJ(ERPDTA) OBJTYPE(*LIB) USER(AIREAD) AUT(*USE)
GRTOBJAUT OBJ(ERPDTA/*ALL) OBJTYPE(*FILE) USER(AIREAD) AUT(*USE)

No special authorities, no group profile to inherit from, and a private *USE grant on the one library you mean to expose. A private authority is checked before *PUBLIC, so *USE here holds even if the files are *PUBLIC *CHANGE. The gap is everything else: any library you did not grant privately falls back to its *PUBLIC authority. Check what the profile can reach by default:

SELECT SYSTEM_OBJECT_SCHEMA, SYSTEM_OBJECT_NAME, OBJECT_TYPE, OBJECT_AUTHORITY
  FROM QSYS2.OBJECT_PRIVILEGES
 WHERE AUTHORIZATION_NAME = '*PUBLIC'
   AND OBJECT_TYPE = '*FILE'
   AND OBJECT_AUTHORITY NOT IN ('*EXCLUDE')
   AND SYSTEM_OBJECT_SCHEMA NOT LIKE 'Q%'
 ORDER BY SYSTEM_OBJECT_SCHEMA, SYSTEM_OBJECT_NAME;

Run it from a security officer profile, or one with *ALLOBJ or the QIBM_DB_SECADM function usage. The view only lists objects the caller is allowed to see, so under an ordinary developer profile the list comes back short and the exposure looks smaller than it is.

Every row is a file any profile on the system can read, including this one, unless the library itself excludes *PUBLIC. Payroll and HR files on that list are a problem today, before any AI tool shows up. If you can’t fix *PUBLIC across the board, at least *EXCLUDE the new profile from the sensitive libraries privately. For per-column protection, use Db2 RCAC masks rather than the MCP server’s masking.

Where the rows go, and what to log

The other half of the risk is not on the IBM i. With a hosted assistant like Claude or Cursor, every row a query returns goes back through the MCP client to the model provider. mcp-server-db2i’s documentation says this plainly. So the questions for whoever owns data governance are whether the assistant is on an approved contract for this data, and whether results are capped low enough that one prompt can’t pull a whole customer file into a chat. Its default of 1,000 rows is generous for an analyst conversation. Setting QUERY_DEFAULT_LIMIT to 100 loses very little.

Turn on logging before you hand out access. mcp-server-db2i writes one JSON line per tool call with the SQL hashed by default, the IBM i user, row count and outcome. IBM’s server supports OpenTelemetry tracing. Either way, your existing database exit programs still see the connection, and so does QAUDJRN if object auditing is on for those files. That is the record an auditor will ask for.

If your team is starting to use AI on IBM i more broadly, from documenting RPG to writing SQL against unfamiliar libraries, the IBM i AI Field Guide collects the prompts and workflow we’d use.

Bottom line

For an analyst who wants to ask questions of business data, use mcp-server-db2i on the ODBC driver: nothing to install on the IBM i, and read-only enforced at four layers including the connection itself. For operations agents or anything built on an agent framework, use IBM’s ibmi-mcp-server with YAML tools only and execute_sql left off, and budget the Mapepire install as a real change.

Whichever you choose, build the profile before you build the config. Create a profile with *USE on exactly the libraries in scope, check what *PUBLIC exposes, cap result rows, and turn on the audit log. The server’s validator is a good second layer. If it is your first, then on IBM’s server one environment variable is all that separates “read-only” from “writes allowed.”

Frequently Asked Questions

Is there an official IBM MCP server for Db2 for i?

Yes. IBM’s open-source ibmi-mcp-server, Apache 2.0, runs YAML-defined SQL tools against Db2 for i through Mapepire, which has to be installed and running on the IBM i (port 8076 by default). It is at version 0.6.2 on npm as of October 19, 2026.

Can an MCP server change data on my IBM i?

It depends on the server and its settings. mcp-server-db2i only runs queries and opens its connection read-only. IBM’s execute_sql tool is off by default and read-only by default, but setting IBMI_EXECUTE_SQL_READONLY=false allows INSERT, UPDATE and DELETE, and a YAML tool runs whatever SQL its author wrote. A profile with only *USE authority is the control that holds in every case.

Do I need to install anything on the IBM i to use an MCP server?

For IBM’s server, yes: Mapepire, usually via yum and Service Commander. For mcp-server-db2i, no, with its default ODBC driver or the optional JT400 driver it uses the database host servers that ACS and ODBC clients already use. Its optional Mapepire-over-SSH driver uploads a JAR to the user’s home directory on first use.

No. Both servers connect through database interfaces, not 5250 menus, so initial menus and limited capabilities do not restrict what SQL can read. Object authority on the libraries and files, plus exit programs on the database server, are what limit it.