Building Agentic Workflows with the MAS MCP Server: A Practical Integration Guide

The IBM Maximo Application Suite has always been a powerful platform for asset management, but until recently, interacting with its data required either the web UI, REST APIs, or custom integration middleware. That changed with the introduction of the Model Context Protocol (MCP) Server in MAS 9.2. The MCP Server exposes Maximo data and operations through a standardized protocol that AI agents can consume directly, opening the door to agentic workflows where autonomous AI systems query, reason about, and act on asset management data without human intermediation.

This shift matters because it changes the fundamental integration model. Instead of building point-to-point integrations between Maximo and every external system, you expose Maximo as a set of tools that any MCP-compatible AI agent can discover and use. A maintenance planner could ask a natural language question, and an AI agent could query work orders through MCP, cross-reference asset history, check inventory levels, and draft a plan for review. The planner reviews the plan rather than spending thirty minutes assembling the data themselves. This is not a theoretical capability. MAS 9.2 shipped with the MCP Server as a first-class feature, and early adopters are already building production workflows with it.

In this article, we walk through what the MCP Server is, how it works under the hood, what it exposes, and how to build your first agentic workflow connecting Maximo to an external AI agent. We also cover security considerations, performance characteristics, and practical limitations that the documentation does not always make obvious. Whether you are an integration architect evaluating MCP for production use or a Maximo consultant exploring what agentic AI means for your clients, this guide gives you the technical grounding to move forward with confidence. We assume familiarity with Maximo concepts like work orders, assets, locations, and job plans, as well as basic understanding of REST APIs and JSON.

What the MCP Server Actually Is

The Model Context Protocol, originally introduced by Anthropic in late 2024, is an open standard that defines how AI models interact with external tools and data sources. Think of it as a universal plug that any AI agent can use to connect to any system that implements the protocol. The MAS MCP Server is IBM's implementation of this standard for the Maximo Application Suite, shipping as a feature of MAS 9.2. It is not a standalone product, not an add-on, and not a premium feature requiring additional licensing. If you have MAS 9.2, you have the MCP Server.

At its core, the MCP Server is a service that runs alongside your MAS deployment and exposes a set of tools, resources, and prompts. Tools are functions that an AI agent can call to perform actions or retrieve data from Maximo. Resources are data endpoints that provide context, such as asset records or work order history. Prompts are predefined templates that guide how an AI agent should interact with the data. Together, these three primitives give an AI agent everything it needs to understand and operate within the Maximo environment. The distinction between these three categories is not just academic. It directly affects how you design workflows and how agents behave.

The server communicates over JSON-RPC, the same protocol that MCP defines for all implementations. This means any MCP-compatible client, whether it is Claude, an OpenAI-based agent, a custom LangChain application, or even a simple Python script using the MCP SDK, can connect to the Maximo MCP Server and start interacting with Maximo data. You do not need an IBM-specific client or SDK on the agent side. This interoperability is the key advantage over the traditional Maximo REST API approach, where each integration required bespoke client code tailored to Maximo's API contract. With MCP, the agent discovers the interface at runtime and adapts accordingly.

From an infrastructure perspective, the MCP Server runs as a containerized service within the MAS deployment. It authenticates against MAS using the same identity provider that your MAS instance uses, typically IBM Security Verify or a similar OIDC provider. This means access control is unified with your existing MAS security model. An AI agent connecting through MCP gets the same permissions as the user account it authenticates with. If a technician's account can only see work orders assigned to them, the AI agent using that account's credentials will have the same restriction. This is both a security benefit and a design constraint, as we will discuss later.

How the MCP Server Exposes Maximo Data

The MCP Server exposes Maximo functionality through three categories of primitives, and understanding the distinction between them is essential for building effective agentic workflows. Each category serves a different purpose and requires a different approach from the AI agent.

Tools are the action-oriented primitives. When the MCP Server starts up, it registers a set of tools that correspond to common Maximo operations. These include querying work orders by status, retrieving asset details, searching the asset registry, checking inventory levels, and creating new work orders. Each tool has a defined input schema that tells the AI agent what parameters it accepts, and an output schema that describes what the response looks like. For example, a tool called query_work_orders might accept parameters like status, site, asset_number, and date_range, and return an array of work order objects with fields like wonum, description, status, status_date, asset, and location. The agent reads these schemas at connection time and knows exactly what each tool expects and returns without any pre-programmed knowledge of Maximo.

Resources are the context-oriented primitives. These are read-only data endpoints that provide background information an AI agent might need. Available resources typically include the asset hierarchy, location hierarchy, job plan library, and work order templates. An AI agent can retrieve these resources to build context before performing actions. For instance, before creating a work order, an agent might retrieve the job plan library to find the appropriate job plan for the asset type, then use that job plan when creating the work order through a tool call. Resources are cached on the agent side for the duration of a session, reducing repeated queries for the same reference data.

Prompts are the guidance-oriented primitives. These are predefined templates that help structure how an AI agent interacts with Maximo. A prompt might define how to format a work order summary for a maintenance planner, or how to structure an asset health report based on condition monitoring data. These prompts are not mandatory for the AI agent to follow, but they provide a consistent framework that helps ensure outputs are well-structured and aligned with Maximo conventions. You can customize prompts for your organization, incorporating your specific naming conventions, workflow rules, and reporting formats. This customization capability is powerful because it lets you encode institutional knowledge into the agent interaction layer without modifying the agent itself.

The practical implication is that an AI agent connecting to the MCP Server gets a self-describing interface to Maximo. It does not need to be pre-programmed with knowledge of Maximo's data model or API structure. Instead, it discovers the available tools, reads their schemas, and decides which ones to call based on the user's request. This is a fundamentally different paradigm from traditional integrations, where a developer must hard-code the API calls and data transformations in advance. The discovery-based approach means new tools added to the MCP Server in future updates are automatically available to existing agents without code changes.

Building Your First Agentic Workflow

Let us walk through a practical example: an agentic workflow that helps maintenance planners prepare for morning huddles. The workflow should retrieve all high-priority work orders created in the last 24 hours, group them by asset and location, check whether required parts are in stock, and produce a summary that the planner can review in five minutes instead of spending twenty minutes pulling reports.

We will use Python with the MCP SDK and a simple agent loop. The first step is connecting to the MCP Server. You need the server endpoint URL, which is available in your MAS deployment configuration, and authentication credentials for a service account with appropriate permissions. The service account should have access to work order data, asset data, and inventory data in the sites the workflow will cover. This is a read-heavy workflow, so the service account only needs query permissions, not creation or modification rights.

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def connect_to_maximo_mcp():
    # Connection parameters for MAS MCP Server
    server_params = StdioServerParameters(
        command="npx",
        args=["-y", "@ibm-maximo/mcp-server"],
        env={
            "MAS_ENDPOINT": "https://your-mas-instance.example.com",
            "MAS_API_KEY": "your-service-account-key",
            "MAS_SITE_ID": "BEDFORD"
        }
    )
    
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # Initialize the connection
            await session.initialize()
            
            # List available tools
            tools = await session.list_tools()
            for tool in tools:
                print(f"Tool: {tool.name} - {tool.description}")
            
            return session

Once connected, the agent can start making tool calls. The key is structuring the workflow so the agent makes intelligent decisions about which tools to call and in what order. For the morning huddle workflow, the agent should first query high-priority work orders, then for each work order, check the associated asset's condition and inventory availability for required parts. The workflow should also handle the case where no high-priority work orders exist, and where inventory data is incomplete or unavailable.

async def morning_huddle_workflow(session):
    # Step 1: Query high-priority WO from last 24 hours
    wo_result = await session.call_tool(
        "query_work_orders",
        arguments={
            "where": "status in ('WAPPR','APPR') and wopriority <= 2 "
                     "and statusdate >= sysdate-1",
            "select": "wonum,description,wopriority,status,assetnum,"
                      "location,siteid,reportedby"
        }
    )
    work_orders = parse_wo_results(wo_result)
    
    if not work_orders:
        return "No high-priority work orders in the last 24 hours."
    
    # Step 2: Group by asset and location
    grouped = group_work_orders(work_orders, key=['assetnum', 'location'])
    
    # Step 3: Check inventory for each asset's required parts
    for asset_num, wos in grouped.items():
        inv_result = await session.call_tool(
            "check_inventory",
            arguments={"assetnum": asset_num, "siteid": wos[0]['siteid']}
        )
        # Attach inventory data to the group
        grouped[asset_num]['inventory'] = parse_inventory(inv_result)
    
    # Step 4: Generate summary
    summary = format_huddle_report(grouped)
    return summary

This is a simplified example, but it illustrates the pattern. The agent orchestrates multiple tool calls, processes the results, and produces a synthesized output. In a production implementation, you would add error handling, retry logic, and more sophisticated grouping and analysis. You might also incorporate an LLM layer to generate natural language summaries from the structured data, making the report more readable for the planner. Consider adding a human review step where the planner sees the summary and can approve, modify, or reject it before any actions are taken. This human-in-the-loop pattern is critical for building trust in agentic workflows, especially in their early stages.

Another pattern worth considering is the multi-agent approach. Instead of one agent doing everything, you might have a coordinator agent that receives the planner's request, delegates sub-tasks to specialized agents (one for work order queries, one for inventory, one for asset history), and then synthesizes their results. The MCP Server supports concurrent connections, so multiple agents can work in parallel. This can significantly reduce latency for complex workflows that involve many independent queries.

Security and Access Control Considerations

The MCP Server inherits MAS's security model, which is both a strength and a constraint. On the positive side, you do not need to build a separate access control system. Whatever roles and permissions your MAS users have, the MCP Server enforces them automatically. An AI agent authenticating as a planner sees what a planner sees. An agent authenticating as a technician sees what a technician sees. This eliminates an entire class of security bugs that plague custom integrations, where access control logic is implemented separately and often inconsistently with the core system.

However, this also means you need to think carefully about service account design. Creating a dedicated service account for AI workflows is essential, and that account should have the minimum permissions necessary for the workflows it supports. Do not use an administrator account for AI agents, even for testing. The principle of least privilege applies here with extra force because AI agents can make autonomous decisions about what data to access and what actions to take. An agent with administrator credentials could inadvertently delete records, change statuses on critical work orders, or modify security groups. These are not hypothetical risks. They are the natural consequence of giving an autonomous system more access than it needs.

Consider implementing audit logging for MCP tool calls. While MAS logs all API activity, you should maintain a separate log of which AI workflows called which tools, with what parameters, and what results they received. This audit trail is invaluable for debugging, compliance, and security review. If an AI agent creates a work order that looks wrong, you need to be able to trace back exactly what tool calls led to that creation and what context the agent had at the time. Store these logs in a separate system, not just in MAS's own log files, so they survive even if the MAS instance is rebuilt.

Network security is another consideration. The MCP Server should not be exposed to the public internet. It should be accessible only within your corporate network or through a VPN. If you need to connect external AI agents, use a secure gateway or API management layer that handles authentication and rate limiting. The MCP protocol supports OAuth 2.0 for client authentication, and you should take advantage of this rather than using static API keys for production deployments. Static keys are convenient for development but create a significant risk if they leak, since they grant the same access as the associated service account.

Performance Characteristics and Limitations

The MCP Server adds a layer of abstraction between AI agents and Maximo data, and that layer has performance implications. In testing, simple tool calls like querying a single work order by number complete in under 200 milliseconds on a well-configured MAS deployment. More complex queries, such as searching work orders across multiple sites with filtering and sorting, can take 500 milliseconds to 2 seconds depending on the dataset size. These latencies are acceptable for interactive workflows but become significant when an agent needs to make dozens of calls in sequence.

Batch operations are where performance becomes critical. If your AI workflow needs to check inventory for fifty assets, making fifty individual tool calls is slow and inefficient. The MCP Server supports batch queries for some operations, but not all. You may need to implement client-side batching logic, where you collect multiple requests and submit them in groups. Alternatively, you can fall back to the Maximo REST API for bulk operations and use MCP only for the interactive, agent-driven portions of the workflow. This hybrid approach gives you the best of both worlds: the flexibility of MCP for agent-driven interactions and the performance of direct API calls for bulk data operations.

There are also rate limiting considerations. MAS enforces API rate limits, and MCP Server requests count against those limits. If you have multiple AI workflows running concurrently, they share the same rate limit pool as your other integrations. Monitor your API usage and adjust workflow timing to avoid hitting rate limits during peak hours. Consider implementing exponential backoff in your agent code so that transient rate limit errors do not cause the entire workflow to fail. The MCP SDK includes retry helpers, but you should configure them based on your specific MAS rate limit settings rather than relying on defaults.

The MCP Server does not currently support real-time event streaming. If your workflow needs to react to new work orders or status changes in real time, you will need to supplement MCP with MAS's event notification system or periodic polling. This is a known limitation, and IBM has indicated that event streaming support is on the roadmap for a future release. For now, design your workflows with polling intervals that balance responsiveness with API load. A 30-second polling interval is a reasonable starting point for near-real-time workflows, while less time-sensitive workflows can poll every few minutes.

Practical Implications

For integration architects, the MCP Server represents a significant shift in how Maximo integrations should be designed. The traditional approach of building custom REST API integrations for each consuming system is giving way to a model where Maximo exposes its capabilities as tools that any MCP-compatible agent can discover and use. This reduces integration development time and maintenance burden, but it also shifts complexity from the integration layer to the AI agent layer. Your AI agents need to be smart enough to use the tools correctly, which means investing in agent design and testing. Plan for a testing phase where agents are evaluated against realistic scenarios before being deployed to production. Include edge cases like missing data, permission errors, and timeout scenarios in your test suite.

For Maximo administrators, the MCP Server is an enabler for new use cases that were previously impractical. Natural language querying of work order data, automated work order creation from incident reports, and cross-system asset health summaries are all achievable with MCP and a capable AI agent. Start with read-only workflows to build confidence, then gradually introduce write operations with human-in-the-loop approval steps. Document each workflow thoroughly, including the service account it uses, the tools it calls, and the business logic it implements. This documentation becomes essential when troubleshooting issues or onboarding new team members.

For organizations still on Maximo 7.6 or MAS 8.x, the MCP Server is another reason to plan your migration to 9.2. It is not available as a standalone add-on for older versions. The agentic AI capabilities that MCP enables are becoming a competitive differentiator, and organizations that adopt early will have a head start in building the workflows and expertise that deliver value. The migration path from 7.6 directly to 9.2 is well-established, and the MCP Server is one of several 9.2 features that justify the upgrade effort.

Bottom Line

The MAS MCP Server is the most significant integration capability added to Maximo in years. It transforms Maximo from a system that requires purpose-built integrations into a platform that any AI agent can interact with through a standard protocol. For teams building agentic workflows, the MCP Server eliminates the integration development layer and lets you focus on agent design and workflow logic. The technology is new and has limitations, particularly around batch operations and real-time events, but the foundation is solid and the roadmap is promising. If you are running MAS 9.2, start building proof-of-concept agentic workflows now. The integration model is changing, and early movers will have a significant advantage in the next wave of asset management innovation.