Every IBM i shop has the same uncomfortable secret: your most valuable business rules are not in your database. They are buried deep inside decades of RPG programs, CL procedures, and hand-rolled SQL - held together by tribal knowledge, cryptic field names, and a few developers who remember why CSTFLG means something completely different depending on which library you call it from. Hand an AI just a table schema and ask it to write a meaningful SQL view, and you will get a technically valid but operationally useless result. Blueprint Sitemule changes that equation.

Blueprint is the newest module in the Sitemule suite - a platform purpose-built for IBM i innovation. Where the rest of the Sitemule family focuses on modernizing interfaces and deploying microservices, Blueprint is explicitly designed to provide instant system insight, accurate documentation, and AI-powered guidance by surfacing what the system actually knows: both the data structures and the business logic that governs them.

What is the Blueprint MCP Server?

The Model Context Protocol (MCP) is an open standard developed by Anthropic that defines a universal interface between AI assistants and external tools. Instead of custom integrations for each data source, MCP standardizes how an AI model invokes tools - reading files, querying APIs, and calling databases - all within a single conversation.

Blueprint's MCP server plugs directly into this standard. When you connect Claude, GitHub Copilot, or any other MCP-capable AI assistant to Blueprint, the assistant gains access to a set of tools that expose the living knowledge of your IBM i system: table definitions, field descriptions, inter-program call trees, RPG and SQL source code, and the semantic relationships between them.

"Blueprint provides the insight required to understand, maintain, and evolve decades-old applications in hours - not months.

This is not a simple database introspection plugin. Blueprint exposes metadata that has been enriched over time: field-level descriptions, domain constraints, validation rules, and the call dependencies that link a Db2 table to the RPG programs that read and write it. In practical terms, this means an AI assistant working through Blueprint understands not just what columns exist, but what they mean and how the business transforms them.

The Pitfalls of Metadata Alone

To appreciate what Blueprint adds, it helps to understand precisely what goes wrong when you give an AI only the database schema. This is the scenario most teams face when they connect a general-purpose SQL assistant to their Db2 for IBM i system

Cryptic field names with no semantic meaning

Legacy IBM i files were designed for 10-character field names on punched cards. A field called ORDST might mean order status, or it might mean "original district" in another table. Without the RPG source that populates it, the AI cannot tell the difference - and will confidently guess wrong.

Implicit business rules encoded in programs, not constraints

IBM i systems rarely use database-level CHECK constraints or triggers for business logic. Instead, an RPG program validates and transforms data before writing it. A customer balance field might look like a simple DECIMAL - but a program enforces that it is always calculated net of pending credits from a separate ledger. The schema alone will never reveal this.

Multi-step calculations spread across call trees

A pricing engine might chain five RPG service programs together before arriving at a final price. Ask an AI for a "current customer price" SQL view, and it will produce a direct read of the price table - missing discounts, surcharges, and contract overrides that live four levels deep in the call tree.

Status flags and codes with undocumented enumeration

A single-character field might have 12 possible values, each triggering different downstream behavior. Without the program source that interprets those values, the AI treats them as opaque strings and produces queries that silently omit entire categories of records.

Library-qualified context that changes meaning

IBM i's library list means that a file in PRODLIB and the same file in TESTLIB may have different data, field overrides, and program behavior. A schema-only connection cannot distinguish these contexts.

The consequence is an AI output that compiles without errors but answers a different question than the one you asked. In a banking context, this is not an inconvenience - it is a compliance risk. In a manufacturing or logistics environment, it means reporting that looks authoritative but is subtly and systematically wrong.

What Blueprint Exposes Through the MCP Server

Blueprint's MCP tools give an AI assistant a qualitatively different view of the system. Rather than reading raw system catalog tables, the AI calls structured Blueprint tools that return curated, enriched metadata.

Table definitions with human-readable descriptions

Blueprint surfaces Db2 table and field definitions enriched with the annotations that Sitemule Architect has accumulated over time - business names, field purposes, domain values, and relationships. The AI sees not just CSTFLG CHAR(1) but a field described as "Customer credit hold flag: A = active hold, R = released pending review, blank = no hold."

Program source and logic

The MCP server can retrieve the actual RPG, CL, or SQL source of a named program. This means an AI assistant writing a query can first inspect the program that calculates a derived value, understand the logic, and replicate or call it correctly, rather than reading raw data that bypasses the calculation.

Call trees - top-down and bottom-up

Blueprint exposes which programs call a given program (callers, bottom-up), and which programs a given program calls recursively (callees, top-down). This allows an AI to trace exactly which business logic touches a given table, giving it the complete picture of how data flows through the application before it writes a single line of SQL.

Cross-referenced search

The search_source tool lets the AI scan the entire source repository for any text pattern - useful for finding every place a particular field, constant, or business rule appears across the codebase. This is how the AI locates all programs that interpret a status code before generating a view that categorizes the status code.

From Metadata to a Precise SQL View

The practical payoff is that you can now ask an AI assistant to produce SQL views that faithfully incorporate business logic - not just schema. A typical interaction looks like this:

-- The AI, working through Blueprint MCP tools, first retrieves:
-- 1. Table definition for ORDHEAD (order header)
-- 2. Source of CALCPRC (pricing program) to understand surcharge logic
-- 3. Call tree showing CALCPRC calls, CNTRTPRC for contract pricing
-- Then produces:

CREATE OR REPLACE VIEW QGPL.V_ACTIVE_ORDERS AS
SELECT O.ORDNO AS order_number, O.CUSNO AS customer_number, O.ORDDT AS order_date,
-- ORDST = 'O' open, 'H' on hold, 'S'shipped, 'C' canceled
CASE O.ORDST
  WHEN 'O' THEN 'Open'
  WHEN 'H' THEN 'OnHold'
  WHEN 'S' THEN 'Shipped'
  WHEN 'C' THEN 'Canceled'
END AS order_status, 
-- Net price = list price minus contract discount (from CNTRTPRC logic)
O.LISTPR - COALESCE (C.CNTDSC, 0) AS net_price,
-- Credit hold flag sourced from customer master, not order
CASE CU.CSTFLG
  WHEN 'A' THEN 'Credit Hold'
  ELSE 'OK' 

END AS credit_status
FROM ORDHEAD O JOIN CUSTMAS CU
ON CU.CUSNO =O.CUSNO LEFT JOIN
CNTRTHDR C ON C.CUSNO = O.CUSNO AND C.CNTSTS = 'A'
--active contracts only
WHERE O.ORDST NOT IN ('C','X');
-- exclude canceled and purged

Notice what would have gone wrong without Blueprint. The AI would not have known that CSTFLG lives on the customer master, not the order. It would not have known that ORDST = 'X' is a purged status distinct from canceled. It would not have known to join CNTRTHDR for contract discounts - that join only makes sense once you have read the pricing program source. Schema-only, you get four missing pieces. With Blueprint, you get the right answer on the first attempt.

The Architectural Advantage on IBM i

This matters especially on IBM i for reasons that go beyond the cryptic field names. IBM i's strength - and its challenge - is that it encapsulates decades of proven, correct business logic inside RPG programs and CL procedures. Those programs are not a liability. They are the most reliable specification of how the business actually works, written in executable form over thirty or forty years of edge cases and corrections.

Blueprint treats those programs as first-class documentation. Rather than asking developers to re-document everything before AI can help, Blueprint reads the programs themselves. This means an AI assistant connected to Blueprint inherits the accumulated institutional knowledge of the IBM i system, not just its data structure. 

Why this matters in practice

itemule Architect integrates tightly with Blueprint, leveraging detailed architectural information to enable domain segregation and the logical division of existing databases into smaller, more manageable domains. The same enriched metadata that powers the MCP server also powers visual system documentation - meaning the investment in Blueprint annotations pays dividends in both AI tooling and human documentation.

Teams using the platform can configure MCP connections to analyze RPG business logic, query production data, and generate modern APIs from existing programs - tasks that would now take weeks to do manually take hours, with AI that actually understands the system it is working with.

Getting Started

Blueprint is the newest engine in the Sitemule suite, available as part of the Sitemule platform for IBM i. The MCP server connects to Claude, GitHub Copilot (VS Code Agent Mode), and any other MCP-compatible AI assistant. Configuration follows the standard MCP pattern - define the server endpoint and credentials in your mcp.json, and the Blueprint tools become available automatically in agent-mode conversations.

For teams already running Sitemule Architect, the metadata enrichment you have already invested in - field descriptions, domain values, relationship definitions - is immediately available through the MCP server at no additional annotation cost. For teams starting fresh, Blueprint's system scanning builds the initial inventory automatically from live system objects.

The fundamental insight behind Blueprint is simple but consequential: an AI assistant is only as precise as the context it receives. On IBM i, the context that matters most has always lived in the programs, not the schema. Blueprint finally makes that context machine-readable - and the difference between a query that looks right and a query that is right has never been easier to close.

Blueprint is part of the Sitemule platform for IBM i. More information at sitemule.com. The Blueprint MCP tools referenced in this article include get_source_info, get_used_programs, get_callers, and search_source.