IBM/mcp Is a Catalogue, Not a Codebase: What the Repository Actually Ships
A collection of Model Context Protocol (MCP) servers, clients and developer tools by IBM.
At a glance
- What is it?
- IBM's MCP repository indexes MCP servers for IBM MQ, FileNet, watsonx.data, ODM, OpenPages and others, but the servers live in separate repositories. Here is what the index gives you, how each server is launched, and where the trail runs out.
- Who is it for?
- Adopt IBM/mcp as a discovery layer if your agents already talk to IBM MQ, FileNet, watsonx.data, OpenPages, ODM or Business Automation Workflow and you need to know which MCP servers exist and how they boot. Do not adopt it if you wanted a single installable package or a monorepo you can vendor and patch; the servers sit in separate repositories, several of which this index does not link at all.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap This Repository Fills Is Discovery, Not Code
The README opens by describing the project as "a collection of Model Context Protocol (MCP) servers, MCP Clients and Developer Tools by IBM", and its stated goal is to "Connect your IBM products to any AI Agent or AI application". That wording matters. The repository is an index. The tables under Automation, Business Automation and Data & Analytics point outward, to ibm-messaging/mq-mcp-server, ibmbpm/ibm-baw-mcp-server, ibm-ecm/ibm-content-services-mcp-server, IBM/ibm-openpages-mcp-server, IBM/ibm-watsonxdata-mcp-server and others. None of those server implementations appear to live here. The audience is therefore narrow and specific: an engineer whose agents already need to reach IBM MQ queue managers, FileNet content repositories, watsonx.data, OpenPages GRC or a decision service, and who wants to know which servers exist before writing glue code. If you have no IBM product in the loop, the index has nothing for you.
Three Categories, Two Launch Patterns, One Missing Repository
The catalogue is organised into three groups. Automation covers IBM MQ (queue manager health checks and MQSC commands) and the K* Planner, described as a containerized deployment of Top-K and Top-Q planners exposed as tools. Business Automation covers Business Automation Workflow, Core Content Services for FileNet, Decision Intelligence, ODM, Process Mining and Workflow Runtime. Data & Analytics covers OpenPages, DataStax Astra DB, Docling and watsonx.data. Two launch patterns recur in the install links: Python-based servers run through uvx with a git source, as in uvx --from git+https://github.com/ibmbpm/ibm-baw-mcp-server ibm-baw-mcp-server, while Node-based servers run through npx, as in npx -y di-mcp-server or npx -y @datastax/astra-db-mcp-server. Note the asymmetry: several rows, including IBM MQ, K* Planner, Process Mining and Workflow Runtime, carry no install link at all and say only "see link for instructions". The README as supplied is also truncated mid-sentence inside the watsonx.data row, so the Data & Analytics table cannot be read as complete.
What the Install Links Actually Configure
The install badges encode a full server definition, which is the most concrete material in the repository. The Business Automation Workflow entry, for example, declares type stdio, command uvx, args ["--from", "git+https://github.com/ibmbpm/ibm-baw-mcp-server", "ibm-baw-mcp-server"] and three environment variables: ENDPOINT, USERID and PASSWORD, pre-filled with placeholders YOUR_WORKFLOW_ENDPOINT, YOUR_WORKFLOW_USERNAME and YOUR_WORKFLOW_PASWORD. That last placeholder is misspelled in the source, which is cosmetic but worth knowing if you copy it literally. The Core Content Services entry follows the same shape but points at a GraphQL endpoint, with SERVER_URL, OBJECT_STORE, USERNAME and PASSWORD. The Decision Intelligence entry switches to npx and uses APIKEY and URL, with the URL template pointing at a tenant-specific decision.saas.ibm.com host. The ODM entry passes no environment block at all. So the pattern is consistent but not uniform: stdio transport throughout the linked examples, credentials always via environment variables, and no example of the remote HTTP mode that the OpenPages row mentions.
Transport, Authentication and the Gap Between Rows
Every linked install definition uses stdio, meaning the server runs as a local child process of the MCP client. The OpenPages row is the exception in the text, stating that it "Supports both remote (HTTP) and local (stdio) modes for flexible deployment", but the index does not show what a remote configuration looks like. Authentication is similarly uneven. The Workflow Runtime row claims "enterprise-grade OAuth security", while the Workflow and Content Services entries use plain USERNAME and PASSWORD variables and Decision Intelligence uses an API key. Anyone planning a deployment that spans several of these servers will be reconciling three different credential models, and the index gives no guidance on doing so. A second gap is maintenance: the repository carries no releases, and because it holds no server code, there is nothing here to patch when a server changes. Your upgrade path always runs through the individual linked repositories.
Where an Index Stops Being Enough
The wrong tool for the job is a team that wants one artefact to install. There is no package to pin, no version to lock, no changelog to read in this repository. If a linked server breaks, the fix lands in its own repository, and the index will not tell you that anything changed. The truncated README compounds the problem: the Data & Analytics table cuts off inside the watsonx.data description, so a reader cannot confirm from this material whether the list is exhaustive. The K* Planner row also deserves a second look before adoption, because it describes a containerized planner deployment rather than a thin protocol adapter, and its usage column says only "see link for instructions". Treat every row as a pointer, not as a validated integration.
How This Differs From a Single-Vendor MCP Server
The obvious comparison is a standalone MCP server published by one vendor for one product, such as the DataStax Astra DB server that this index also lists. That project is one repository, one package, one README, and its install link here is a complete npx command with its two environment variables. IBM/mcp takes the opposite approach: breadth across a product portfolio, with depth pushed into sibling repositories. The trade-off is legibility. With a single-vendor server you can read the whole thing in an afternoon. With this index you get a map of roughly a dozen servers, three credential conventions and two runtimes, and you must visit each destination separately to learn its transport, its licence and its failure behaviour. The index is faster for scanning and slower for deciding.
Licence, Upgrades and What the Index Does Not Cover
The repository is Apache-2.0. That covers the index itself, which is documentation and link metadata. It does not tell you the licence of any linked server, and several of those servers are hosted under different GitHub organisations (ibm-messaging, ibmbpm, ibm-ecm, DecisionsDev, datastax, docling-project), so each must be checked on its own before you redistribute or embed it. Apache-2.0 here carries the usual patent grant and attribution conditions, but this is not legal advice and the per-server licences are the ones that will govern a deployment. On upgrade cost: the index needs no upgrades because it runs nothing. The real cost sits in the servers, where the Python ones are pulled fresh from git via uvx and the Node ones resolve through npx, so a rebuild can pick up upstream changes without any version pin in this repository recording what moved.
Who Should Keep This Tab Open
Keep IBM/mcp bookmarked if you are evaluating agent access to IBM middleware and want the shortest path to the right server repository. Skip it if you need a single dependency, a pinned version, or a support contract, because it offers none of those. Before wiring anything up, confirm that the specific server you need is linked from the index rather than merely implied by a product name, then open that repository and check its transport mode, its authentication scheme and its licence. The index is a starting point with a clear boundary: it tells you what exists and roughly how it boots, and it stops there.
Editorial conclusion
Adopt IBM/mcp as a discovery layer if your agents already talk to IBM MQ, FileNet, watsonx.data, OpenPages, ODM or Business Automation Workflow and you need to know which MCP servers exist and how they boot. Do not adopt it if you wanted a single installable package or a monorepo you can vendor and patch; the servers sit in separate repositories, several of which this index does not link at all. Verify first that every server you intend to run is actually linked from the index, then read its own README for transport mode, authentication and licence, because the index carries none of those details.
Community notes