IBM i MCP server options: governed AI access to Db2 for i data

Your orders, inventory and accounts still live on IBM i. The Model Context Protocol (MCP) is how AI clients such as Claude Desktop, Claude Code or your own agent call tools and read data. In Gluesync 2.3, the Core Hub MCP server gives every connected IBM i agent its own read-only database tools, under the caller's own permissions. For heavy or continuous AI workloads, Gluesync journal CDC keeps an AI-facing copy current instead.

This article covers the options IBM i teams have today, and when to use which.

MCP in one paragraph for IBM i teams

MCP is an open protocol. An MCP server publishes tools (list tables, run a query, start a job) and an MCP client, usually an AI assistant, decides when to call them. The server decides what the tools can do and whose identity they run as. For IBM i, that means the important design choices are on the server side: which profile connects, what SQL is allowed, and how much load lands on the production partition.

What exists today: IBM's ibmi-mcp-server and Mapepire

IBM publishes an open-source IBM i MCP Server. It exposes Db2 for i through SQL tools you define in YAML, and executes them through Mapepire, IBM's WebSocket database server for IBM i (yum install mapepire-server, default port 8076). It ships ready tool collections for performance monitoring, security and audit, job management, storage and IFS, and database objects. Because almost everything about IBM i is queryable through SQL services, this is a strong fit for system administration: active jobs, authorities, subsystems, disk usage.

There is also a community server, mcp-server-db2i, with ODBC, jt400 or Mapepire drivers.

If your goal is to let an AI assistant help operate the IBM i box itself, IBM's server is the natural starting point. Gluesync works on the data side: business tables, the pipelines that move them, and the governance around who reads what.

Three questions before an agent touches production

1. Load. An agent asks many short questions. Where do those queries run, and how big can they get?
2. Identity. Does the agent connect as a shared service profile, or as the person who asked?
3. Freshness and reach. Does the agent need live rows from one system, or a current view that joins IBM i with Oracle, SQL Server or a cloud warehouse?

Gluesync answers these with two patterns. Most teams use both.

Pattern B: direct governed reads with Core Hub MCP

Gluesync Core Hub embeds an MCP server inside the Core Hub process, over SSE and streamable HTTP. In Gluesync 2.3 it carries 142 built-in tools, plus tools generated for each connected database. See the Core Hub MCP page for the catalog.

The IBM i source and target agents are SQL-capable in Query Studio. In Gluesync 2.3, each IBM i agent the caller can see gets four dynamic MCP tools:

• list_schemas
• list_tables
• describe_table
• execute_sql

These dynamic database tools are on by default in 2.3 (GLUESYNC_MCP_DYNAMIC_DB_TOOLS=false turns them off).

How a read reaches IBM i:

• It uses IBM jt400 JDBC on one dedicated, on-demand connection per query, separate from the CDC connection pool.
• The connection closes when the query finishes, and shows up on IBM i with application name Gluesync, so operators can see it.
• Read-only is enforced twice: a statement validator, then a JDBC read-only connection.
• Each query is capped at 10,000 rows (GLUESYNC_QUERY_STUDIO_MAX_ROWS) with a 5-minute timeout.
• The MCP client presents a Core Hub session token or Personal API Token, and every call runs with that caller's role and Query Studio data-access rules. Read-only tokens cannot call write tools.

One Db2 for i specific: EXPLAIN through Query Studio is not supported on Db2 for i. Use Visual Explain in IBM i Access Client Solutions for access plans.

The same agent path backs Query Forge, which exposes IBM i as a JDBC schema. That is how a BI tool, or AI as SQL, can join IBM i tables with other agents in place.

Direct reads fit ad hoc questions: "which open orders for this item shipped late last week", "describe the columns in this file", "draft the SQL for a margin report and show me a sample". The caps keep each question bounded, and the answer is as fresh as the source.

Pattern A: journal CDC into an AI-facing copy

Some AI workloads are not a question. They are a stream: embedding refreshes for a RAG store, agents that scan whole tables every hour, dashboards that many users hit at once. For those, read from a copy.

Gluesync IBM i CDC reads journal entries through IBM's native APIs and delivers committed changes continuously to targets such as PostgreSQL, Snowflake, Google BigQuery, Apache Kafka, MongoDB, Couchbase and Elasticsearch/OpenSearch, as well as SQL Server, Oracle, Databricks, Microsoft Fabric Open Mirroring and Redis Streams. The background on journaling choices is in system journaling versus RPG triggers and real-time replication with native CDC APIs.

The AI side then works against the target. Point a vector pipeline at it, or let Core Hub MCP db_ tools query the target agent with the same governance. The heavy reads land on infrastructure sized for them, and the copy stays current with each committed change on IBM i.

Governance on both paths

• Calls run as the caller, with the same RBAC as the Gluesync Web UI.
• Read-only deployments hide every write tool with one setting, and tool exposure can be limited to an allow-list.
• Pipeline-changing tools are confirmation-gated: the first call creates a pending action that runs only after explicit confirmation.
• AI Studio Spark agents use the same Core Hub MCP tools with a per-agent allow-list, and every tool call leaves a trace.
• IBM i tables are indexed into the Enterprise brain with their columns and keys, so agents can search for the right file by name and column. Schema graph links come from foreign keys in the source catalogue, which is not read for Db2 for i, so IBM i tables appear in 2.3 without foreign-key relationships. Teams can add business context about IBM i tables as Enterprise brain memories, free-text knowledge agents use to answer questions; memories do not create links in the schema graph.

More on the legacy angle: AI on legacy databases.

When to use which

Need	Good fit
AI help operating the IBM i system (jobs, authorities, storage)	IBM ibmi-mcp-server with Mapepire
Ad hoc business questions on live Db2 for i rows, under each user's role	Gluesync Core Hub MCP db_ tools (Pattern B)
RAG, full-table scans, many concurrent AI users	Gluesync journal CDC into an AI-facing target (Pattern A)
Joining IBM i with other databases in one query	Query Forge, or MCP on a CDC target
Managing the pipelines themselves from an AI client	Core Hub MCP built-in tools

Running IBM's server for system work next to Gluesync for business data is a sensible combination. Each does its own job well.

If you are weighing Gluesync against other IBM i replication tools, see Gluesync vs Fivetran HVR on IBM i.

Getting started

Connect an IBM i agent to Core Hub 2.3, point your MCP client at https://<core-hub-host>:1717/mcp/http (1717 is the default Core Hub port; omit it behind a reverse proxy) with a Personal API Token with the MCP scope, and ask it to list your schemas. For read-only access, use a token with the MCP read-only scope. Then decide which workloads stay direct and which move to a CDC copy.

Request a free 30-day trial and bring your IBM i data into your AI workflows.