IBM/mcp: a catalog of IBM MCP servers

What IBM/mcp is, and what it is not

The repository describes itself as "a collection of Model Context Protocol (MCP) servers, MCP Clients and Developer Tools by IBM." That word collection matters. The top level holds CONTRIBUTING.md, LICENSE, README.md and mcp.json. There is no server implementation at the root. What you get is a README organized into tables, and those tables point outward to other repositories, most of them under different GitHub organizations such as ibm-messaging, ibmbpm, ibm-ecm, DecisionsDev and datastax.

The problem it solves is discovery and consistency. If you run IBM MQ, FileNet Content Manager, Business Automation Workflow, OpenPages or watsonx.data and you want an AI agent to reach those systems, you would otherwise have to find the relevant MCP server yourself and work out how it is launched. IBM/mcp gathers those servers in one place, groups them by product family (Automation, Business Automation, Data & Analytics), and for many entries supplies a one-click install link for VS Code. The intended reader is an engineer wiring an agent into existing IBM infrastructure, not someone looking for a general-purpose MCP toolkit.

A word on the name. MCP here means Model Context Protocol, the open protocol for connecting models to tools and resources. It is not the same as IBM i, IBM's midrange operating system, despite the shared letters. Nothing in this repository concerns IBM i.

How the catalog is structured and how install links work

Each table row names a server, gives a one-line description, and then either links to instructions or embeds a VS Code install badge. Those badges are the interesting part. They are not documentation, they are payloads. The badge URL encodes a JSON object describing an MCP server: its name, its transport type, the command that starts it, its arguments, and its environment variables.

Take the IBM Business Automation Workflow entry. Decoded, its badge says the server runs over stdio, is started with uvx, and takes three environment variables: ENDPOINT, USERID and PASSWORD. The IBM Decision Intelligence entry instead uses npx with the arguments -y and di-mcp-server, and expects APIKEY and URL. The IBM Core Content Services entry uses uvx against a git URL and expects SERVER_URL, OBJECT_STORE, USERNAME and PASSWORD. So the launch mechanism varies by server: some ship as Python packages run through uvx, some as npm packages run through npx, and some are cloned from git at launch time.

That variation is the real content of the repository. It tells you that there is no single IBM MCP runtime. Each server is its own project with its own packaging, its own transport, and its own credential model. The catalog's value is that it states those differences in a machine-readable form that an editor can consume directly. The README does not document a shared authentication layer, a common configuration file format, or a gateway that fronts these servers.

Installing an IBM MCP server from the catalog

There is no repository-wide install command. You pick a server and follow its entry. The fastest path is the VS Code badge: clicking it hands the encoded configuration to VS Code, which adds the server to your MCP settings. The IBM Business Automation Workflow entry, for example, decodes to a stdio server launched with uvx from git, with ENDPOINT, USERID and PASSWORD in its environment.

If you would rather configure a client by hand, the badge payload is the specification. The catalog encodes the server's name, type, command, args and env exactly as the badge URL carries them, so you can read the launch configuration straight out of the README rather than installing anything first. Expect the process to start and wait on stdio rather than print a banner. A stdio MCP server that exits immediately usually means a missing or malformed environment variable, so set the credentials the entry names before you wire it into an editor. Two entries in the catalog, IBM MQ and K* Planner, carry no install badge at all; their usage column says to see the linked repository for instructions, and that is where the real setup steps live.

The catalog's weak points: no versions, no rollback, no compatibility matrix

The README gives no version numbers, no release tags and no compatibility matrix. The repository has no retrieved releases. That matters because the install links pin nothing. The Decision Intelligence entry runs npx -y di-mcp-server, which resolves the latest published package at launch time; the Workflow and Content Services entries pull from a git URL, which means the default branch. A change upstream reaches your agent the next time it starts, and the catalog will not tell you it happened.

The README also does not document rollback, nor does it describe how a server behaves when its credentials expire or its endpoint is unreachable. For a stdio server the failure mode is typically a dead process and a silent tool list, which is harder to diagnose than an HTTP error code. Anyone deploying these against production IBM systems should treat the environment variables as secrets and expect to manage their rotation outside this repository.

Finally, the catalog is a snapshot of a moving set of projects. Entries point at repositories in at least five different GitHub organizations. Nothing in the README states a review process for those links, so a linked server's maintenance is independent of this repository's. If a linked server goes quiet, the catalog row will still look fine.

IBM/mcp compared with running a plain MCP server

The obvious alternative is to skip the catalog and install one MCP server directly from its own repository, for example IBM's MQ server from ibm-messaging. The difference is scope, not technology. A direct install gives you one server, its own README, its own issue tracker and its own release cadence, and you read exactly one set of instructions. IBM/mcp gives you a map of the whole IBM surface area, grouped by product family, with machine-readable launch configuration for the entries that carry badges.

That grouping is the reason to start here. If you know you need FileNet, you can go straight to ibm-ecm. If you are scoping what is even possible, the three tables answer that faster than searching GitHub. The trade-off is indirection: every problem you hit belongs to the linked project, and the catalog cannot help you debug it. A second alternative, for teams that want a single endpoint in front of many MCP servers rather than many separate stdio processes, is an MCP gateway. The README does not describe one, and no gateway is listed among the entries.

Maintenance, licence and upgrade cost

The repository is not archived, and its last push was on 2026-09-02, which is recent enough that the catalog itself is being touched. That says nothing about the servers it links to. Each of those has its own last-push date, and those dates are the ones that determine whether the integration you depend on is still moving. Check the linked repository, not this one, before you build on an entry.

The repository is licensed Apache-2.0, per the LICENSE file at the top level. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters when the code touches enterprise products. It does not follow that the linked projects share that licence; each server repository carries its own, and the README does not state them. If your organization has licence review, review the specific server, not the catalog.

Upgrade cost is the practical concern. Because the install links pin no versions, upgrading is implicit: you get whatever the package or default branch contains the next time the server starts. There is no changelog in this repository to read before that happens, and the README does not describe a rollback path. Teams that need reproducible agent behaviour will have to pin versions themselves, outside the catalog.

Editorial conclusion

Adopt IBM/mcp if you already run IBM MQ, FileNet Content Manager, Business Automation Workflow, OpenPages or watsonx.data and want an agent to reach those systems through MCP; the repository is a catalog, so your real work starts in the linked server repositories. Do not adopt it expecting a single installable server or a general-purpose tool: there is no top-level server code here, and the servers it points to live in other organizations. Before committing, open the specific server repository you need, confirm its transport and environment variables, and check whether the install link matches the client you use.

Frequently asked questions

Official sources

1. IBM/mcp on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README