IBM i DevOps TechTalk #29
AI – PART 2
by the experts at ARCAD
In this episode, Ray Bernardi welcomes Alan Ashley for the second part of their conversation about AI on IBM i. Together, they explore how MCP servers work, why they can be viewed as a toolbox connecting AI assistants to trusted application data, and how ARCAD MCP Server uses structured metadata to provide accurate context without exposing source code.
They also discuss the importance of governance and security, including controlled access, API keys, audit capabilities, and restrictions on sensitive actions. Finally, they explain how ARCAD’s deterministic tools can reduce token consumption, improve the reliability of AI-generated answers, and help organizations control the growing costs associated with AI models.
Missed the beginning of the conversation? Listen to the first episode to discover why AI is becoming essential for IBM i teams, along with practical use cases and the importance of trusted context for successful AI adoption.
The Story Behind the Mic: Podcast Transcription
Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. Today we’ll be doing part two of our AI discussion with Alan Ashley, a senior solutions architect here at ARCAD software. So Alan, in our last discussion on AI and ARCAD, we talked about some of the features, some of the things you could do with it, like learning about your programs and finding out where a field gets used and so on.
But I’d kind of like to get more into the architecture of things like what is in ARCAD MCP Server? How does it relate to what’s going on in the AI world? And why is it so powerful? What can it do for us?
Alan Ashley – I think before we go to the ARCAD MCP Server, let’s take a half a step back and see where that MCP Server really kind of fits into things at a general level, because you have these LLMs, you have the Claude, the Open AI, the Gemini’s, you have all these LLMs, these great AI assistants that have such memory and can process information so quickly and really provide some useful assistance.
One of the problems is they kind of need guidance on how to access data and particularly your data. So in within your ARCAD environment. So this is where an MCP comes in. Think of an MCP basically as like your Home Depot or your Lowe’s. It’s a big store. But what’s inside the store? It’s a bunch of tools.
These tools each have a unique function. Hammer, screwdrivers, Phillips heads, you name it. They have tools for a function. Within an MCP, you design tools for a function. So for example, within the ARCAD MCP, we have one that looks like some cross-reference information. We have another one that looks at your application information. And so what we do is we’re pulling this against the ARCAD API’s to extract this data, to feed it to the LLM.
Then the LLM goes, oh now I understand what you’re asking because we fed information up from the ARCAD metadata into the LLM through the MCP. And now it goes, oh, I understand how that field is being used within this table and the key here is you haven’t exposed any source to the AI engine. That’s key. We’re just telling the LLM all the pertinent information. It’s very deterministic that way because it doesn’t get a chance to kind of go. I think this is the correct answer for that. So then general is an MCP. Now MCPs come in all kinds of different shapes and sizes and functions and features. I know just as to help me understand, I created an MCP to look at different things. On the IBM i, there’s been dozens of people that I’ve seen out there that have created MCPs that run locally on their PC to do different things. I use one MCP to read my text messages on my MacBook air, and it can respond to in particular during political season I had it, send automatic stop every time one of them came in.
I had my LLM do that for me to save me from having to go stop, delete, report, spam. So that’s what you can do with it.
R.B. – So basically, the MCP server is nothing but a toolbox.
A.A. – Yes, it’s basically a big toolbox.
R.B. – And you’re putting tools in there. So you just said you made an MCP Server. You made tools. You put them in a toolbox, you’re accessing data on an IBM i. That’s kind of scaring me about security and access to the IBM i metadata and things like that. What kind of governance is there? What kind of security is in place?
A.A. – So the MCP that was originally kind of the framework of the MCP release, really didn’t have a lot of built in security per sec. It was just kind of a concept of, hey, here’s how to make things talk to each other. It’s up to the creator of the MCP to build in their security. Funny story: I was building mine. I was testing something. Guess what I did? I wrote it into production data because I forgot to secure it through the MCP, saying don’t write to these places. Very simple to do, I overlooked it. So we get to the ARCAD MCP and one of the discussions was is hey, should we create tools around writing and executing different functions?
And my first response was yes, it must be yes, because we can control and maintain the access, meaning we can force it to follow the rules that are already in place within ARCAD on who can do what. So that was one of the features like, yes, we need to control that access versus somebody creating their own.
And messing themselves up for lack of a better term. So we had this MCP. We now have these tools. One of the things that is coming in 2026, one that I’m really excited about, is how we’re securing this. So every user that’s going to use our MCP is going to get an API key? that’s theirs. We can restrict that key to a tool set, a number of tools. We can also have it expire. We can also go in and see which users issued which tools. So if we are going through and we’re doing an audit to say, okay, this person did a display cross ref, this one did a program ref. Oh, this one executed a macro. Which brings up a good point within ARCAD we had these macros. These are powerful, powerful tools. We created a blacklist of tools, our blacklist that you can add macros to. Meaning these cannot be executed by an LLM agent. If an LLM tries to execute it and it’s on the list, it’s not going to do it. It’s going to fail. Because there are so many things you can do within the macro world, within ARCAD, that could be detrimental when run out of sequence.
And you don’t want the LLM to accidentally run something out of sequence. So there’s going to be a blacklist of different macros that you can do. Now there’s good macros out there, like building a list, that’s pretty good. And those are very powerful within ARCAD. So we’re adjusting those types of functions. And like I said starting we can control that if it’s not us, then who.
And we are much better and much better. We have more knowledge over that aspect. Then a user or another company around how it’s getting access to your data, we understand it.
R.B. – All right. So it seems that there’s a lot of governance. There’s a lot of security features that can be used to make sure that things don’t get out of hand with AI. I just want to make sure that I understand this completely. You just said you can make an MCP server. You can make it do things against the IBM i and so on. But I’m trying to figure out where ARCAD actual value comes in here. Now, without ARCAD, you have to make this thing look at just the source code. But with ARCAD and the metadata repository, you’re giving it application context. Is that correct?
A.A. – Correct. It’s giving it the application context. Now you can have it, look at the source. And there are some that do. And that’s fine. The one thing I will say is if you’re using a personal account, it’s probably going to be training off of your source code.So you want to have an enterprise or a teams account where you can turn training off and protect your source code.
R.B. – It would make the costs higher. If it’s looking just at source code and figuring it out that way?
A.A. – Well, if it’s just looking at source code, it might guess. It can look through and see the calls and it can see fields that are being updated. So yes. And it can build some context around that on how those relationships play in. But there’s not a 100% guarantee that it’s going to get those relationships 100% correct 100% of the time.
R.B. – Yes. But you’re always talking about token and coins and whatnot. If it’s just looking at source code, figuring it out versus the ARCAD metadata, which I already knows is not going to cost more.
A.A. – It is going to go through and it’s going to eat up what’s called the context window, meaning you’re feeding information into this window, which cost tokens. And every time you do something, it’s going to have to read the source and then follow the source trail on and on and on every time. So with the MCP, we’re telling it saying, hey, go here. And then the MCP does some work and feed some context back. And then the MCP does some work and feed some context back. So in the end there should be some control savings which in turn saves tokens in the long run. One of the key ones is one of the tools that we have is convert to fully free.
And what this does is it actually kicks off if you have the license to the transformer RPG product. It actually will use transformer RPG to convert your code to fully free versus the LLM doing it and eating all your tokens. And that’s where it’s really valuable. And, I’ll close it out with this.
We’re actually kind of in the middle of a shift within the LLM world. It started off as everything was a subscription, $20. You got this month’s a $60. You got this much? $100. You got this much. What is slowly starting to happen? It is all becoming more API based, meaning it’s no longer going to be a subscription. It’s actually going to be a cost for every character, basically.
And you can look at the cost of some of these things, like a word might cost 0.00000001. But think of a book. Think of a novel. If you’re typing out a paragraph on how to do something, that might be a nickel, you put a whole bunch of nickels together. Next thing you know, you’re 100 bucks in.
So those that’s where we’re shifting to. So MCPs are going to become more valuable because you’re being able to process information away from the LLM. You’re also going to see localized LLMs, meaning you’ll have a what’s called a frontier model. This is your Claude, your open AI, your Gemini’s. Those are the frontier models. You will have it where it will hand off to a local LLM that may not be as fully trained, but it’s capable of doing what you need it to do.
And so you’re not eating your tokens there. But that’s a story for another day. That’s a know localized LLM or a story for another day.
R.B. – We’ve already hit a time limit on this one. But it looks like we’re going to be doing a third part on ARCAD and AI, doesn’t it?
A.A. – Yes. Sure it does.
R.B. – All right. Thanks, Alan. Really appreciate your time today.
So as you can hear, there’s a lot going on with ARCAD and AI and I hope you’re understanding that one of the takeaways here is that ARCAD is trying to roll out AI in a very responsible way. Governance and security matter. And as you heard, we will be doing a part three on this topic. Talk to you then. And as always, thanks for listening.
Our Hosts

Ray Bernardi
Senior Consultant, ARCAD Software
Ray is a 30-year IT veteran and currently a Pre/Post Sales technical Support Specialist for ARCAD Software, international ISV and IBM Business Partner. He has been involved with the development and sales of many cutting edge software products throughout his career, with specialist knowledge in Application Lifecycle Management (ALM) products from ARCAD Software covering a broad range of functional areas including enterprise IBM i modernization and DevOps.

Alan Ashley
Solution Architect, ARCAD Software
Alan has been in support and promotion of the IBM i platform for over 30 years and is the Presales Consultant for DevOps on IBM i role with ARCAD Software. Prior to joining ARCAD Software, he spent many years in multiple roles within IBM from supporting customers through HA to DR to Application promotion to migrations of the IBM i to the cloud. In those roles, he saw first hand the pains many have with Application Lifecycle Management, modernization, and data protection. His passion in those areas fits right in with the ARCAD suite of products.











