AssetOpsBench: An MCP-Based Agent Framework for Industrial Maintenance

The gap AssetOpsBench is aimed at

Maintenance and reliability work is multi-step by nature. A question like whether a chiller is degrading requires sensor history, a failure mode reference, a forecast, and eventually a work order. Each of those lives in a different system, and each has its own vocabulary. The README frames AssetOpsBench as a unified framework for developing, orchestrating and evaluating domain-specific agents in exactly this setting, built for maintenance engineers, reliability specialists, facility planners and Industry 4.0 researchers. The problem it addresses is not that LLMs cannot reason about maintenance. It is that there is no shared tool interface or shared scenario set to reason against, so every team reinvents the plumbing and no two results are comparable. AssetOpsBench answers with a fixed set of MCP servers and a scenario corpus. The At a Glance table lists 9 asset classes, 141+ scenarios, 5 domain agents plus one utility server, and 2 orchestration frameworks. The repository description claims 460+ scenarios, which does not match the 141+ in the README table. Treat the scenario count as something to confirm from the dataset card rather than from either number.

Five domain MCP servers and what each one exposes

The architecture is a set of Model Context Protocol servers, each owning one slice of the maintenance domain. The IoT server covers the physical estate: sites, asset_ids, asset_detail, assets, find_assets_by_sensors, installed_sensors, measured_sensors, latest_reading, history and sensor_stats. The FMSR server handles failure mode and effects records through get_failure_modes, generate_failure_modes and add_failure_modes. The WO server is the work order system, and it is the largest surface: nine read tools (list_workorders, get_workorder, get_workorder_tasks, get_workorder_costs, get_workorder_actuals_vs_planned, get_workorder_kpis, get_schedule_calendar, get_my_assigned_workorders, get_failure_codes) and six write tools (generate_work_order, update_workorder, approve_workorder, assign_technician, close_workorder, cancel_workorder). The Vibration server does signal work: get_vibration_data, list_vibration_sensors, compute_fft_spectrum, compute_envelope_spectrum, assess_vibration_severity, calculate_bearing_frequencies, diagnose_vibration. The TSFM server is the odd one out in size. The README states its full surface contains 41 tools, split across task and evidence tools (list_tasks, profile_series, characterize_series, data_quality), a model catalog (list_models, search_models, find_models, resolve_model, model_template, register_model, register_finetuned, hf_stats), a feature catalog (list_features, search_features, extract_features, select_features) and a run and evaluation ledger (recipe_template, run_recipe, run_tabular_recipe, run_plan, evaluate, list_runs, list_results). That breadth is a design choice worth noting: the TSFM server is not a forecaster, it is a registry and execution layer that lets an agent discover models, register fine-tuned ones and record runs. The agent still has to pick and invoke a recipe.

The Utilities server and why a shared catalog matters

Alongside the five domain servers there is one shared utility server, listed separately in the table. It exposes json_reader, get_sensor_catalog, get_asset_catalog, get_failure_mode_catalog, current_date_time and current_time_english. Two of those are unglamorous and load-bearing. get_asset_catalog and get_sensor_catalog give an agent a way to resolve names before it queries, which is the difference between a tool call that returns a chiller and one that returns an empty list because the site string was wrong. current_date_time matters for any agent reasoning about schedules, work order ageing or forecast horizons, since without it the model falls back on a training cutoff. Putting these in a utility server rather than duplicating them per domain is the right call, and it is the part of the design most likely to be copied by teams building their own MCP stacks. The README points to docs/mcp-servers.md for the full arguments, categories and backing services of every server. That document is where the actual contracts live, and it is the first thing to read before writing any agent code against these tools.

MetaAgent and AgentHive: two orchestration blueprints

The repository description names two multi-agent orchestration blueprints, MetaAgent and AgentHive, running over MCP. The README confirms the count of two orchestration frameworks but does not describe either one's control flow in the material available here. What can be said from the structure is that the split is deliberate: the domain servers are stateless tool providers, and orchestration is a separate concern layered on top. That means you can swap the orchestrator without touching the tool definitions, which is the main practical benefit of building on MCP rather than on a bespoke function-calling schema. It also means the framework does not tell you which orchestrator to use. If you are evaluating AssetOpsBench as an orchestration library, the honest position is that the README gives you the names and the count and defers the mechanics to the code and the papers. Anyone choosing between MetaAgent and AgentHive should read the implementation, not the badge list.

Getting it running, and the caveat in the quick-start block

The Quick Start section gives three commands. Clone the repository, change into it, and install in editable mode: git clone https://github.com/IBM/AssetOpsBench.git, then cd AssetOpsBench, then pip install -e . The third line runs a scenario: python -m assetopsbench.run --scenario "List all sensors of Chiller 6 in MAIN site". That command carries an inline comment reading (to be enabled). This is the single most important thing to notice in the README. The documented entry point is not described as working. If you follow the quick start literally, you may get an error rather than a sensor list, and you should plan for that. The alternatives the README offers are a Colab notebook described as an illustration of an LLM Agent, a Hugging Face Space playground, and INSTRUCTIONS.md, which the README says covers full setup, MCP servers and the plan-execute runner. INSTRUCTIONS.md is the real setup path. The README also notes that active development is on main, while the codebase used for publication venues is maintained on separate branches, with ACL 2026 work on IndustryAssetEQA and prior experimental work on main-0.x. The Colab link points at main-0.x, not main, so the notebook and the branch you clone by default are not the same code.

Branch sprawl and the maintenance cost it implies

There are no retrieved releases, so installation means tracking a branch. Three are named: main for active development, main-0.x for prior experimental work, and IndustryAssetEQA for the ACL 2026 codebase, with the README saying other publication venues continue to be maintained on separate branches. Each accepted paper listed in the badges (KDD 2026, IJCAI 2026, EMNLP 2025, NeurIPS 2025, AAAI 2026, IAAI 2026, ICLR 2026, ACL 2026) is a plausible reason for another branch to exist. For a team adopting this, that is the real cost: pip install -e . installs whatever the checked-out branch contains, and reproducibility across a paper, a notebook and your own experiment depends on which branch each one pins. A benchmark that cannot be pinned to a release is harder to compare against. The Apache-2.0 licence is permissive and imposes no copyleft obligation on your own code; it does include a patent grant and requires you to retain notices and state changes. That is a general description of the licence text, not legal advice, and your counsel should review it if you plan to redistribute a modified copy.

Where this is the wrong tool

AssetOpsBench is a benchmark and evaluation harness with a tool layer attached. It is not a maintenance system. The WO server can generate, approve, assign, close and cancel work orders, and the README does not state what backs those writes in a given deployment. If you point an agent at a live CMMS before establishing that, the failure mode is a fabricated or duplicated work order in a system technicians rely on. The same caution applies to add_failure_modes on the FMSR server and to register_model and register_finetuned on TSFM, all of which mutate state. A second limit is scope. The tool surface is defined by the servers listed, so a workflow that needs procurement, inventory, spare parts or a historian not covered by the IoT tools has no path through this framework without writing a new MCP server. Third, the scenario command being disabled means the out-of-the-box evaluation loop is not something you can run end to end today without reading INSTRUCTIONS.md first. Teams that need a working demo this week should use the Hugging Face playground instead of a local install.

The alternative worth comparing against

The obvious alternative is to skip the framework and write tool functions directly against your own CMMS and historian APIs, wired into whatever agent library you already use. The difference is in the interface layer. Direct function calling ties your tool definitions to one agent library's schema, and every model or library change is a rewrite of the glue. AssetOpsBench puts the tools behind MCP servers, so the same IoT, WO and Vibration surfaces can be consumed by any MCP-capable client, and the orchestrator becomes a swappable component, which is the point of having MetaAgent and AgentHive as two blueprints rather than one. The cost of that choice is an extra process to run and a protocol to debug. If your agent will only ever call three internal endpoints and never be benchmarked against anyone else's results, direct function calling is less machinery. If you want your maintenance agent's behaviour to be comparable to published results, the MCP layer is what makes that possible.

Editorial conclusion

Adopt AssetOpsBench if you are building or benchmarking an agent over industrial maintenance data and want the tool surface already defined: the five domain MCP servers plus the Utilities server give you a concrete interface to code against, and the scenario set gives you something to measure against. Do not adopt it as a production runtime for a live CMMS or sensor fleet yet. The README's own scenario command is annotated as not enabled, the codebase is split across main, main-0.x and venue branches, and the write-side WO tools can generate, approve, assign and close work orders, which is not something to point at real records before you have read docs/mcp-servers.md and confirmed what backs each tool. Verify first: which branch the installable package tracks, whether the MCP servers run against simulated or connected data in your deployment, and what the WO write tools actually mutate.

Official sources

1. IBM/AssetOpsBench on GitHub
2. Issues
3. License: Apache-2.0
4. README