MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Using MCP to allow AI agents to interact with IBM MQ

By MATTHEW LEMING posted 11 hours ago

  

In the MQ department we spend a lot of time talking, thinking, and playing about with agentic AI. You may have spotted a recent blog where we shared a POC demoing how asynchronous messaging can be used to allow agents to reliably and scalably communicate with each other.

As well as being able to communicate with each other, agents need to be able to interact with other systems, such as databases, file systems and REST APIs. After all, an HR agent wouldn’t be much use if it couldn’t get access to information about the employee using it. For a long time agents have only been able to interact with other systems via bespoke integrations which tend to be hard to discover and reuse, slowing down innovation, and duplicating effort.

MCP - Model Context Protocol - was introduced last year by Anthropic as a standardized way of allowing agents, and LLMs to interact with other systems, making reuse of integrations trivial. For this reason MCP is often described as the equivalent of a USB-C port for AI applications. There are a number of concepts that make up MCP, and you can read in detail about them elsewhere, but I am going to cover just three: servers, clients, and tools.

server: an MCP server exposes the capabilities of an external system via the MCP protocol

client: an MCP client connects to an MCP server, and allows AI agents to discover the capabilities of the server, and to invoke them

tool: MCP servers can provide tools which allow AI agents to execute actions against external systems. These actions might be read-only, or could change the state of the external system

So, how does all this apply to MQ? I wanted to understand whether having an LLM interface to MQ could allow new users to easily get to grips with their MQ real-estate using natural language, without having to keep referring to IBM documentation for the detail of each individual MQSC command. This would even provide benefits to those who have years of experience, let's face it who remembers all the details of every available command? I specifically didn't want to expose each MQSC command as an individual tool, I was hoping that just two tools would be enough:

dspmq list available queue managers and whether they are running or not

runqmsc run any MQSC command against a specific queue manager

You might recognise these, as you probably use them every day. The question was whether an LLM could also use them. I was hoping they could, after all there is a lot of MQSC out there which can be used for training data. To implement an IBM MQ MCP server I followed this quick-start and tested out the resulting code using an internally available IBM MCP client. The first thing I realised was that creating MCP servers is quick and easy, it took less than an hour or two to get something that did everything I needed.

Below you can see a diagram of the MCP server I created. The source code for running it is available in the IBM messaging github org. The server is just over 100 lines of Python and exposes the dspmq and runmqsc tools. If you look at the code you will see that each tool provides some descriptive text about what the tool does, the parameters it accepts and the data it returns. That text is provided to MCP clients as meta-data and allows the agent using that client to decide when and how to invoke the tool, and how to interpret the results. In particular for the runmqsc tool, it is up to the agent to generate the MQSC command and parse the results before displaying them to the user.

The two tools are backed by the MQ Administrative REST API and can discover and interact with any distributed queue managers that are in the same installation as the mqweb server. The server could easily be extended for use with z/OS queue managers, and I will do that in future.

Once I had my MCP server running I connected it to an internal IBM only LLM (which is why I can’t share screen shots) and had a play to see what I could do. I started off by asking which queue managers were available, and then progressed onto showing things like all queues which have more than 100 messages. Because there is a lot of MQSC data, most LLMs are capable of generating the correct MQSC command to achieve this either using the WHERE clause, or by listing the CURDEPTH of all queues and then manually filtering the results.

Depending on the exact model that I used I also had some success in getting the LLM to wire a pair of queue managers together from scratch. In this case it looked like it followed the instructions from the IBM MQ docs.

If this sounds interesting then please try out the MQ MCP server and try connecting it to your LLM of choice. One of the benefits of MCP is that it should just work! If you have access to IBM watsonx Orchestrate you could try using that, and there are a wide range of other MCP clients available. Please contact me at lemingma@uk.ibm.com to let me know how you get on!

0 comments
4 views

Permalink