For utilities, grid operators and manufacturers running IBM Maximo

Maximo integration for AI agents: an MCP server that runs as the planner, not as a superuser key

Maximo integration for AI agents is an MCP server on the Maximo REST API that exposes named operations, such as asset failure history or open work orders, runs in the security context of the person asking, and is read-only by default. As of 19 September 2026 IBM ships no Maximo MCP server. Pexon builds one inside your network.

The starting point

The Integration Framework was built for systems. An agent asks on behalf of people.

IBM describes the Maximo Integration Framework as secure data sharing between Maximo Manage and an external system, over web services, JMS, Kafka or HTTP, and it requires API keys for all machine-to-machine integrations. That is the right design for an ERP interface. It is the wrong starting point for an agent, because IBM's own REST documentation says an API key effectively works in the context of the user it was created for. One key behind an agent means every planner, contractor and reliability engineer who asks it gets that user's security groups.

The community Maximo MCP server we read most closely is configured with one API key, and two of the servers we found ship write tools, one of them including delete. The work is not the protocol. It is deciding whose rights each call runs under, and which operations exist at all.

Your options, honestly

Four ways to put an agent on Maximo, and what each does better than us

  • IBM Maximo Assistant (MAS 9.x)

    It is part of MAS 9.x, sits inside the application next to Work Order Intelligence, and IBM maintains it through its own upgrades. No integration project to start.

    Does it answer the questions that need data from outside Maximo, such as a historian trend or a PLM revision?

  • Makini

    Breadth: one MCP endpoint across Maximo Monitor APM and many other industrial products, a token scoped to each login, every call logged, with EU in-region and self-hosted options.

    Are four generic tools, search, get, create and update, the interface you want your planners to reason through?

  • Community MCP servers

    Free and readable. One ships nine tools including three write tools and tells you plainly to use a read-only API key while exploring.

    Who keeps it working after your next MAS upgrade, and what stops a write tool you did not mean to enable?

  • A server built for your process

    Operations named after your maintenance work, the person's own security context, no write path at all, deployed in your network and handed over as your code.

    Can you wait two weeks for a blueprint before anything runs against your Maximo?

A realistic first tool list

Five operations, and the guard that travels with each

ToolWhat it reads or returnsGuard
get_asset_historyOne asset with its work orders and failure history, through the asset object structure (MXAPIASSET)Read-only; only sites the person's security groups cover
search_open_work_ordersWork orders by site, asset and status, returned as records the answer can citeRead-only; no status change, no assignment
propose_failure_codeA suggested failure code from the free-text description and past work orders on similar assetsSuggestion only; the planner sets the code in Maximo
draft_job_planA draft job plan or PM interval from the manual and the asset's historyDraft only; approval stays in Maximo with the person who signs it
draft_service_requestA prefilled service request from an operator's descriptionReturned to the person, who submits it in Maximo under their own name

The three tools that draft are where most of the value in maintenance sits, and they are also where a write path would be most tempting. None of them has one.

What we build

Three parts, deployed inside your network

Electricity, gas and district heating operators fall under Annex I of the NIS2 directive, and a maintenance system is part of the estate a regulator will ask about. That is why the default here is self-hosted and read-only, and why the audit log is designed before the first tool.

  1. 01

    An identity layer in front of Maximo

    Each call runs in the security context of the person asking: through SAML where your MAS setup supports it, or through per-person API keys managed and rotated by the server. Where neither is possible, we narrow one key to what may be shared across a team and write that subset down before the build.

    • MAS SAML
    • per-person API keys
    • security groups respected
  2. 02

    Named operations on fixed object structures

    Each tool is bound to one object structure and a fixed field list, so the agent reads what the tool promises and nothing adjacent. No generic query tool, no free OSLC filter passed through from the model, no endpoint that takes an arbitrary object structure name.

    • Maximo REST/OSLC API
    • typed tool schema
    • no raw queries
  3. 03

    Audit, tests and a runbook

    Every call is logged with the person, the tool and the object structure it touched, in a store your security team already reads. A test suite runs the tool list against a copy of your data before each MAS upgrade, and the handover includes the runbook, so the server outlives the pilot team and us.

    • audit log
    • upgrade tests
    • your repository

Rules that hold across all three

  • No tool closes, approves, changes status or deletes
  • Anything that would write returns a draft a person completes in Maximo
  • Condition data comes from a historian or DMZ copy, never from a control system

For an energy company the question is not whether an agent can write to Maximo. It is whether anything that can should exist at all. Our default answer is no.

Start with the Readiness Blueprint.

We have not built a Maximo connector for a named customer, so the first step is proving that yours can be built this way. Two weeks, €4,900 fixed: one maintenance use case, the tool list agreed with your planners and your Maximo administrator, a test of the identity model against your security groups, and a costed build plan you keep whoever builds it. All prices are net and exclude VAT.

Related

Questions about Maximo and AI agents

Does IBM ship an MCP server for Maximo?

No, as of 19 September 2026 we found none. IBM uses watsonx Orchestrate as its hub for MCP servers of other products, and Maximo Application Suite 9.x has its own Maximo Assistant inside the application. Community servers exist, the largest with 175 tools including delete, and Makini offers a commercial MCP server for Maximo Monitor APM. The more useful question than whether a server exists is whose identity it runs under.

Can the agent run on a single Maximo API key?

It can, and for anything beyond a pilot it should not. IBM documents that an API key effectively works in the context of the user it was created for, so one key means everyone who asks the agent gets that user's rights. We give each person their own security context where your MAS setup allows it, and where it does not, we narrow the key to what may be shared and write down which subset that is.

What does a Maximo integration for an agent cost?

The two-week Readiness Blueprint is fixed at €4,900: one maintenance use case, the agreed tool list, a test of the identity model against your security groups, and a costed build plan. A first production server is typically a use-case pilot from €15,000. Whether API access consumes licence points under your MAS contract is a question for IBM; check with them before the build. All prices are net and exclude VAT.

Why not use Makini instead?

Use Makini if generic tools fit your use case. It is a real option: one MCP endpoint across many industrial systems, a token scoped to each login, EU hosting and a self-hosted variant. We build when the agent needs operations named after your maintenance process rather than search, get, create and update, when writes must be impossible rather than configured off, and when the server has to be your code, in your repository, with the tool list your security team signed.

What will the agent not do in Maximo?

It will not close, approve, change the status of or delete anything. Every tool reads, or returns a draft that a person completes in Maximo under their own name. It will not touch a control system either: condition data comes from a historian or a DMZ copy, never from SCADA. And we have not yet built a Maximo connector for a named customer, which is why the first step is a two-week blueprint, not a build.

Next step

Not a sales call. An architecture call.

Thirty minutes with the engineer who would build the server: your MAS version, the maintenance question your planners ask most, and whether per-person identity is realistic in your setup.