MCP Servers and the New Maximo Integration Frontier

The Integration Landscape in MAS 9.2

The Maximo Application Suite has undergone a quiet revolution over the last three releases. What was once a SOAP-centric integration framework that required middleware expertise has evolved into a JSON-first, REST-native platform with multiple integration surfaces. With MAS 9.2, released in June 2026, IBM has added a new layer: the Model Context Protocol (MCP) Server for Maximo Manage APIs.

This addition matters because it bridges two worlds that have been parallel but separate: the operational asset management world of Maximo and the rapidly expanding world of AI agents and large language models. Before MCP, connecting an AI agent to Maximo required building custom REST API wrappers, hardcoding endpoint knowledge, and maintaining brittle glue code that broke every time the API schema changed. With the official MCP Server, an AI agent can discover Maximo tools, understand their parameters, and execute them through a standardized interface that any MCP-compatible host can consume.

The integration surface in MAS 9.2 now consists of six distinct layers, each serving different use cases and audiences. The first is the Maximo Integration Framework (MIF), the traditional pattern built on object structures, publish channels, enterprise services, and endpoints. The second is the Maximo Manage REST API, also called the JSON REST API, which exposes every business object through OpenAPI-style endpoints. The third is OSLC, which provides linked-data semantics on top of the REST surface. The fourth is the MCP Server, new in MAS 9.2, which exposes Maximo operations as tools for AI agents. The fifth is the MAS Admin API, for suite-level administration including workspace management and user provisioning. The sixth is event-driven integration through Kafka topics and outbound webhooks.

Understanding when to use which layer is the most common question integration architects face, and getting it wrong leads to fragile architectures that are expensive to maintain and difficult to extend. The key architectural principle is that these layers are complementary, not competitive. A mature Maximo deployment will use multiple integration patterns simultaneously, and that is healthy. The problem arises when teams use all three primary patterns (MIF, REST, OSLC) to do the same thing, which signals an architecture that needs rationalization.

MCP Architecture and the AI Integration Layer

The Model Context Protocol has emerged as the standard for connecting AI agents to external systems. IBM shipped an official MCP Server for Maximo Manage APIs as part of MAS 9.2, and it fundamentally changes how AI-powered tools interact with Maximo.

The MCP architecture has three components. The MCP Host is the application running the AI model, which could be Claude Desktop, a VS Code extension, or a custom agent framework built on LangChain or similar tooling. The MCP Client manages communication between the model and external services, handling the protocol negotiation and message routing. The MCP Server exposes tools, resources, and capabilities through a standardized interface that any MCP-compatible host can consume.

The Maximo MCP Server exposes Maximo Manage APIs as MCP tools. An AI agent can discover available tools such as creating work orders, querying assets, updating inventory, and retrieving labor records. The agent understands the parameters for each tool and can execute them without needing to know the underlying REST API details. This abstraction is powerful because it separates the agent's intent from the API mechanics.

# Example: AI agent interacting with Maximo via MCP
# The agent discovers tools and calls them through the MCP abstraction layer

# 1. Agent discovers available Maximo tools
tools = mcp_client.list_tools()
# Returns: ["create_workorder", "query_assets", "update_inventory",
#           "get_labor_records", "create_inspections",
#           "update_asset_status", "search_workorders", ...]

# 2. Agent queries assets with natural language intent
result = mcp_client.call_tool("query_assets", {
    "siteid": "BEDFORD",
    "filter": "status = 'ACTIVE' and criticality = 'HIGH'"
})
# Returns structured JSON with asset records

# 3. Agent creates a work order based on conversation context
wo_result = mcp_client.call_tool("create_workorder", {
    "siteid": "BEDFORD",
    "description": "Pump P-101 abnormal vibration detected",
    "worktype": "CM",
    "assetnum": "P-101",
    "priority": 1,
    "longdesc": "Condition monitoring system detected "
                "vibration above 0.45 IPS at 10:30 AM CDT. "
                "Recommend immediate inspection of bearing housing."
})

The MCP Server handles authentication, authorization, and translation between the MCP protocol and the Maximo REST API. It uses OAuth 2.0 by default, with API key support for backward compatibility. The server runs as a containerized service alongside the Maximo application, and it can be deployed in the same Kubernetes cluster or externally depending on your network architecture and security requirements.

What makes MCP fundamentally different from simply wrapping the REST API in a function library is the discovery mechanism. A general-purpose AI agent that has never seen Maximo before can connect to the MCP Server, enumerate the available tools, read their parameter schemas, and start executing meaningful operations. The agent does not need a pre-built Maximo integration module. It does not need hardcoded endpoint URLs. It does not need a developer to write a Python wrapper for each Maximo business object. The MCP Server is the wrapper, and any MCP-compatible agent can use it.

For organizations building internal AI tools, such as a maintenance copilot that helps planners prioritize work orders or a safety assistant that surfaces relevant inspection history, MCP eliminates the integration code that previously consumed weeks of development effort. The agent connects to the MCP Server, and the Maximo integration is complete. The development effort shifts from building API plumbing to designing the agent's reasoning, prompts, and workflow logic.

The security model deserves attention. The MCP Server inherits the Maximo security framework, which means the AI agent operates within the permissions of the authenticated user. If the connected service account has read-only access to work orders, the agent cannot create or modify them. This is important for deployments where AI agents are used for analysis and recommendation but should not execute changes without human approval. The MCP Server supports both interactive OAuth flows for human-facing agents and service-to-service OAuth for automated agents.

MIF: When the Framework Still Earns Its Keep

The Maximo Integration Framework remains the umbrella term for the traditional integration pattern built on object structures, publish channels, enterprise services, and endpoints. While REST has become the default for new integrations, MIF still earns its place in specific scenarios that REST handles poorly or not at all.

MIF's strength is in complex inbound transformations and outbound publish patterns. When you need to receive a file from an external system, apply conditional logic to determine which Maximo objects to update, transform field values through processing classes, and trigger workflow on the resulting records, MIF provides a configuration-driven approach that requires no custom code. The REST API can handle the data ingestion, but the conditional logic and transformation pipeline are MIF's domain.

Publish channels remain the preferred pattern for outbound event notification. When a work order status changes in Maximo and you need to notify three downstream systems simultaneously, a publish channel with conditional routing rules is more maintainable than building three separate REST callouts. The publish channel processes the event once, generates the message, and delivers it to all configured endpoints. If one endpoint is unavailable, the retry logic is handled by the MIF framework, not by custom code in each downstream system.

<!-- Example: MIF publish channel configuration for work order status changes -->
<!-- Object Structure: MXWO (Work Order) -->
<!-- Publish Channel: MXWOInterface -->
<!-- End Point: HTTP (REST), JMS (Queue), or Flat File -->

<PublishChannel>
  <name>MXWOInterface</name>
  <objectStructure>MXWO</objectStructure>
  <eventName>WORKORDER.STATUSCHANGE</eventName>
  <conditionalProcessing>
    <rule name="HighPriorityOnly">
      <condition>STATUS in ('APPR','COMP') and PRIORITY <= 2</condition>
      <action>publishToEndPoint</action>
      <endPoint>WO_STATUS_HTTP</endPoint>
    </rule>
    <rule name="AllChanges">
      <condition>true</condition>
      <action>publishToJMSQueue</action>
      <endPoint>WO_STATUS_JMS</endPoint>
    </rule>
  </conditionalProcessing>
</PublishChannel>

The four core MIF components work together to define the integration contract. Object Structures define the data schema that Maximo exposes externally, controlling which fields are included, which are required, and which business rules apply when data enters through the integration layer. Publish Channels define outbound flows, generating messages when qualifying events occur. Enterprise Services define inbound flows, processing messages from external systems and creating or updating Maximo records with full business rule enforcement. End Points define the external destinations, supporting HTTP, JMS queues, and flat file delivery.

MIF is also the foundation for the Maximo ERP Integration add-on, which provides pre-built integrations with SAP, Oracle, and other ERP systems. If your organization uses the ERP Integration add-on, you are using MIF under the hood, and that integration is not going to be rewritten as a REST API integration anytime soon. The ERP Integration add-on includes pre-configured object structures, enterprise services, and processing rules that handle the complexity of ERP data models, chart of accounts mapping, and purchase order synchronization. Rebuilding this in REST would be a multi-year project with no business justification.

The practical guidance is to keep MIF for existing integrations that work, for complex publish patterns that require routing logic, and for ERP integrations that depend on the add-on. For everything new, start with the REST API. And if you are migrating from Maximo 7.6 to MAS 9.x, evaluate each MIF integration individually. Simple CRUD integrations that use MIF only because REST was not available in 7.6 should be rewritten as REST API integrations. Complex integrations that leverage MIF processing classes and conditional logic should be migrated as-is initially, with REST rewrites evaluated after the migration is stable.

The JSON REST API: The Default Choice

The Maximo Manage REST API, also called the JSON REST API or the OSLC-flavored REST API, is the primary integration surface for MAS 9.x. Every Maximo business object is accessible through consistent, OpenAPI-style endpoints that use standard HTTP methods and return JSON responses. The API was completely rewritten for MAS, sharing the same code base as the OSLC REST APIs that Maximo Anywhere and Maximo Mobile use internally.

The base URL pattern follows the object hierarchy and uses standard HTTP methods:

# Base URL pattern
https://{mas-host}/maximo/oslc/os/{objectname}

# Retrieve work orders with filtering
GET /maximo/oslc/os/mxwo?oslc.where=siteid="BEDFORD" and status="APPR"

# Create a new work order
POST /maximo/oslc/os/mxwo
Content-Type: application/json
{
  "siteid": "BEDFORD",
  "description": "Quarterly pump inspection",
  "worktype": "PM",
  "assetnum": "P-101",
  "priority": 3
}

# Update specific fields on an existing work order
PATCH /maximo/oslc/os/mxwo/{id}
Content-Type: application/json
{ "status": "APPR", "schedstart": "2026-08-15T08:00:00-05:00" }

# Retrieve a single record by ID
GET /maximo/oslc/os/mxwo/{id}

Authentication uses OAuth 2.0 with API keys. Clients obtain an OAuth token by posting credentials to the token endpoint, then include the bearer token in subsequent API calls. API keys are still supported but are increasingly treated as a legacy authentication method as of MAS 9.2, where OAuth became the default recommendation.

The REST API supports several advanced features that make it suitable for production integrations. Lean mode strips metadata from list responses, reducing payload size by 40-60 percent for large queries. The batch endpoint supports bulk operations, allowing you to create or update multiple records in a single request. Dynamic query views let you define custom field sets per integration, so different consumers see only the fields they need. Group by queries support aggregation operations. And custom JSON elements can be appended to the object structure JSON for extension fields that are not part of the standard Maximo schema.

# Example: Python integration using Maximo REST API
import requests
import json

class MaximoClient:
    def __init__(self, base_url, api_key):
        self.base_url = base_url
        self.session = requests.Session()
        self.session.headers.update({
            "apikey": api_key,
            "Content-Type": "application/json",
            "Accept": "application/json"
        })

    def get_work_orders(self, site_id, status="APPR"):
        """Retrieve approved work orders for a site with lean mode"""
        url = f"{self.base_url}/maximo/oslc/os/mxwo"
        params = {
            "oslc.where": f'siteid="{site_id}" and status="{status}"',
            "oslc.select": "wonum,description,assetnum,priority,"
                          "status,schedstart,craft,estimateddur",
            "_lean": "1"
        }
        resp = self.session.get(url, params=params)
        resp.raise_for_status()
        return resp.json().get("member", [])

    def create_work_order(self, wo_data):
        """Create a new work order with validation"""
        url = f"{self.base_url}/maximo/oslc/os/mxwo"
        payload = {
            "siteid": wo_data["siteid"],
            "description": wo_data["description"],
            "assetnum": wo_data.get("assetnum"),
            "worktype": wo_data.get("worktype", "CM"),
            "priority": wo_data.get("priority", 3),
            "ld_": wo_data.get("long_description", "")
        }
        resp = self.session.post(url, json=payload)
        if resp.status_code == 400:
            raise ValueError(f"Validation error: {resp.json()}")
        resp.raise_for_status()
        return resp.json()

    def bulk_update(self, updates):
        """Batch update multiple work orders in one request"""
        url = f"{self.base_url}/maximo/oslc/os/mxwo/bulk"
        payload = {"member": updates}
        resp = self.session.patch(url, json=payload)
        resp.raise_for_status()
        return resp.json()

The decision to use the REST API is straightforward for new integrations. If you are building a new integration with a modern external system, reading or writing Maximo business objects in real time, building a mobile or web front end that talks to Maximo directly, or calling Maximo from a serverless function or containerized microservice, the REST API is the right choice.

OSLC and Event-Driven Patterns

OSLC (Open Services for Lifecycle Collaboration) provides linked-data semantics on top of the REST surface. It is most useful when integrating Maximo with other IBM tools that expose OSLC endpoints, when modeling cross-system resource relationships, or when you need delegated UI features like the OSLC selection dialog.

OSLC's value proposition is narrow but real. If you need a work order in Maximo linked to a requirement in IBM Engineering Requirements Management DOORS, a test case in Engineering Test Management, and a change record in Engineering Workflow Management, OSLC provides the linked-data vocabulary to express those relationships. Without OSLC, you would build custom glue code to maintain those cross-system references, and the code would be fragile because it would not follow any standard.

For most teams, OSLC is not the primary integration pattern. It is a specific tool for a specific job: cross-system resource linking with IBM ecosystem tools. Use it when the scenario calls for it, and do not use it as a general-purpose integration pattern. Mixing OSLC and REST for the same business object in the same project is a sign that the architecture needs review.

Event-driven integration through Kafka topics is the newest addition to the Maximo integration toolkit. MAS exposes Kafka topics for select event types, allowing downstream systems to subscribe to changes without polling. This is a significant improvement over the cron-based polling patterns that many Maximo integrations have used for years.

# Example: Kafka consumer configuration for Maximo work order events
# Topic: mas-maximo-workorder-events
# Consumer group: downstream-erp-sync

consumer:
  bootstrap.servers: "kafka-cluster:9092"
  group.id: "downstream-erp-sync"
  auto.offset.reset: "latest"
  enable.auto.commit: "false"

topics:
  - mas-maximo-workorder-events

# Sample message payload (JSON):
# {
#   "eventType": "STATUS_CHANGE",
#   "objectStructure": "MXWO",
#   "wonum": "WO12345",
#   "siteid": "BEDFORD",
#   "status": "APPR",
#   "priority": 2,
#   "assetnum": "P-101",
#   "changedfields": ["status", "changedate", "changeby"],
#   "timestamp": "2026-08-04T10:30:00Z",
#   "changedBy": "JSMITH"
# }

# Consumer logic:
# 1. Parse event
# 2. Map Maximo work order fields to ERP fields
# 3. Update ERP system via ERP API
# 4. Commit offset (only after ERP update succeeds)

For organizations that have been polling the Maximo REST API every five minutes to detect status changes, Kafka eliminates the polling overhead and delivers events in near real time. The caveat is that Kafka topics are available for a subset of event types, not all Maximo business events. Check the MAS 9.2 documentation for the current list of supported event topics before committing to this pattern.

Outbound webhooks are also available for select event types. Webhooks are simpler to consume than Kafka topics because they require only an HTTP endpoint, but they lack the durability guarantees that Kafka provides. If your webhook consumer is down when the event fires, the event is lost unless you build retry logic on the Maximo side. Kafka retains messages, so a consumer that comes back online can replay missed events from the last committed offset. For critical integrations where event loss is unacceptable, Kafka is the right choice. For simple notifications where occasional loss is acceptable, webhooks are sufficient.

Building an Integration Catalog

One of the most valuable things a Maximo integration team can do is maintain an integration catalog. This is a living document that lists every integration point into and out of Maximo, the protocol used, the owner, the frequency, the data flow, and the business purpose.

The catalog serves multiple purposes. It provides visibility into the integration landscape for new team members who would otherwise spend weeks discovering hidden dependencies. It identifies redundant integrations that could be consolidated, such as three systems each polling the same work order data independently. It surfaces dependencies that would be affected by an upgrade or migration. And it gives architects a clear picture of where the technical debt lives.

Building the catalog is a one-time effort of perhaps 20-40 hours for a typical Maximo deployment. Maintaining it is an ongoing responsibility that should be assigned to the integration team lead. The catalog should be reviewed quarterly and updated whenever integrations are added, modified, or retired. Teams that skip this step end up with integration spaghetti that nobody fully understands, and every upgrade becomes an archaeological dig.

Practical Implications

For teams starting new Maximo integration work in 2026, the decision tree is clearer than it has ever been. Start with the JSON REST API for CRUD operations on Maximo business objects. Use the MCP Server if you are connecting AI agents or building AI-powered tools that need to interact with Maximo data. Use MIF for complex publish patterns, legacy integrations that already work, and ERP integrations that depend on the add-on. Use OSLC for cross-system resource linking with IBM ecosystem tools. Use Kafka for event-driven patterns where you need durability and replay capability. Use webhooks for simple event notification where durability is not critical.

Organizations that are mid-migration from Maximo 7.6 to MAS 9.x should prioritize rewriting SOAP integrations as REST API integrations during the migration. The REST API is stable, well-documented, and provides the same business object access that MIF SOAP web services provide. The migration effort is typically straightforward for simple CRUD integrations and more complex for integrations that rely on MIF processing rules and conditional logic. For those, keep MIF running in MAS 9.x until you can rebuild the logic in the consuming system or as automation scripts that run within Maximo.

Teams building AI-powered tools should evaluate the MCP Server before building custom REST API wrappers. The MCP Server eliminates the integration code that previously consumed weeks of development effort, and it provides a standardized interface that works with any MCP-compatible AI agent framework. If the MCP Server does not expose the specific Maximo operations you need, file an enhancement request with IBM and build a thin REST wrapper as a temporary measure. The MCP Server is actively developed, and the roadmap includes expanding the tool set in subsequent releases.

Security teams should pay attention to the OAuth 2.0 transition. MAS 9.2 makes OAuth the default recommendation, and API keys are treated as legacy. New integrations should use OAuth from the start, and existing API key integrations should be added to the migration backlog. Service-to-service OAuth flows are well-documented and supported by the platform, so the migration effort is modest for most integrations.

Bottom Line

The Maximo integration landscape in 2026 is JSON-first, REST-native, and supplemented by MCP for AI agents, Kafka for event-driven patterns, and MIF for legacy and complex publish scenarios. Build new integrations on the REST API by default. Keep MIF for the patterns where it earns its keep. Use the MCP Server for AI agent integration. Reserve OSLC for cross-system resource linking. Treat the legacy maxrest API as historical. And maintain an integration catalog so the next person who joins your team does not have to reverse-engineer the integration architecture from scratch. The teams that get this right will find that Maximo integration in 2026 is simpler, more maintainable, and more capable than it has ever been.