OME MCP v5 — Dell OpenManage Enterprise MCP Server

Version 5.2 | Changelog

A Model Context Protocol (MCP) server that exposes Dell OpenManage Enterprise (OME) management capabilities to AI agents via a Streaming HTTP transport. No direct iDRAC connections are made — all data flows through OME's REST API.

Features

Related MCP server: Redfish MCP Server

Architecture

AI Agent / MCP Client
        │
        │  HTTP POST /mcp  (Streaming HTTP transport)
        ▼
┌─────────────────────┐
│   ome_mcp_v5        │   Docker container (Ubuntu/Python 3.11)
│   FastMCP server    │
│   port 8000         │
└────────┬────────────┘
         │  HTTPS REST API calls
         ▼
┌─────────────────────┐
│  OME Appliance      │   https://192.168.1.145/api
│  (192.168.1.145)    │
└────────┬────────────┘
         │  OME manages iDRAC internally
         ▼
   Dell PowerEdge Servers

No connections are made directly to iDRAC — OME handles that internally.

Prerequisites

• Docker Engine 24+ and Docker Compose v2 on an Ubuntu host

• Network access from the host to https://192.168.1.145 (OME appliance)

• OME admin credentials

Quick Start

1. Clone / copy project files

mkdir -p /opt/ome_mcp_v5
cd /opt/ome_mcp_v5
# Place all project files here

2. Configure credentials

cp .env.example .env
nano .env          # Set OME_USER, OME_PASSWORD

Never commit .env to version control.

3. Build the image

./service_control.sh build

4. Start the server

./service_control.sh start

The MCP endpoint will be available at http://<host>:8000/mcp.

5. Check status

./service_control.sh status
./service_control.sh logs 50

TLS / SSL Toggle

No rebuild is required — just change the env var and restart.

Auto-start with systemd (optional)

# Install systemd unit (auto-updates WorkingDirectory to current path)
sudo ./service_control.sh install-systemd

# Start now
sudo systemctl start ome_mcp_v5

# View logs
sudo journalctl -u ome_mcp_v5 -f

To remove the systemd unit:

sudo ./service_control.sh uninstall-systemd

Connecting an MCP Client

Point any MCP-compatible client at:

http://<host_ip>:8000/mcp

Example with mcp CLI:

mcp call --url http://192.168.1.200:8000/mcp ome_list_devices '{"top":10}'

Example with Python SDK:

from mcp.client.streamable_http import streamablehttp_client
from mcp import ClientSession

async with streamablehttp_client("http://192.168.1.200:8000/mcp") as (r, w, _):
    async with ClientSession(r, w) as session:
        await session.initialize()
        result = await session.call_tool("ome_list_devices", {"top": 5})
        print(result.content)

Pagination

All list tools accept top (page size, default 50) and skip (offset) parameters. Use the returned next_skip value to fetch subsequent pages:

{"top": 25, "skip": 0}   // first page
{"top": 25, "skip": 25}  // second page

OData Filtering

Pass standard OData $filter expressions via the filter parameter:

"Model eq 'PowerEdge R640'"
"Severity eq 'Critical'"
"LastRunStatus/Name eq 'Failed'"
"StatusType eq 'New'"

Security Notes

• Credentials are stored in .env (owner-read-only, not version-controlled).

• The server runs as a non-root user (mcpuser, UID 1000) inside the container.

• Credentials are never logged.

• For production, set OME_VERIFY_SSL=true and use a valid TLS certificate on OME.

• The MCP endpoint itself is plain HTTP on port 8000; place a reverse proxy (nginx/caddy) with TLS in front of it if external exposure is required.

Troubleshooting

Container won't start:

./service_control.sh logs

Authentication errors:

• Verify OME_USER / OME_PASSWORD in .env

• Confirm OME is reachable: curl -k https://192.168.1.145/api/SessionService/Sessions

SSL errors:

• Set OME_VERIFY_SSL=false for self-signed certs

• Restart after changing: ./service_control.sh restart

Tools return empty results:

• Devices may not be discovered yet — use ome_create_discovery_job

• Check OME permissions for the API account

Adding New Tools

1. Add a Pydantic Input model in ome_mcp_v5_server.py

2. Add a function decorated with @mcp.tool(name="ome_your_tool")

3. Call _ome_get / _ome_post as appropriate

4. Rebuild: ./service_control.sh rebuild && ./service_control.sh restart

License

MIT License — see LICENSE file.

Changelog

v5.2.0 — 2026-04-09

Fixed: ome_remediate_firmware_baseline completely rewritten

The tool was non-functional in v5.0/v5.1 due to three root-cause bugs:

1. Wrong endpoint — Code used UpdateService/Actions/UpdateService.UpdateFirmware, which does not exist in OME 4.6+ (UpdateService.Actions is null). Fixed: now POSTs directly to JobService/Jobs.

2. Wrong Targets structure — Old payload used {"Id": id, "Type": {...}}, missing the required Data field. Fixed: {"Id": id, "Data": "<component_sources>", "TargetType": {"Id": 1000, "Name": "DEVICE"}} where Data is a semicolon-joined string of component SourceName values for non-compliant components.

3. Incomplete Params — Old params list was missing required keys. Fixed: full validated param set is repositoryId, catalogId, complianceReportId, operationName, rebootType, signVerify, complianceUpdate, stagingValue.

New execution flow:

1. GET UpdateService/Baselines({id}) → extract RepositoryId, CatalogId

2. GET UpdateService/Baselines({id})/DeviceComplianceReports → per-device, collect SourceName for components where UpdateAction != UNKNOWN and ComplianceStatus not in {OK, UNKNOWN}

3. POST JobService/Jobs with operationName=INSTALL_FIRMWARE, rebootType=2 (graceful) or 3 (stage-only)

Returns an early error if no non-compliant components are found, preventing empty job creation.

Validated by live test: full firmware update of a PowerEdge R6515 (13 components including BIOS, PERC RAID, HDDs, NICs, SSDs) against Dell online catalog baseline.

v5.0.0 — initial release

• 28 read/write OME tools via Streaming HTTP MCP transport

• Docker container with non-root user, systemd unit, health check

• OData filtering and pagination on all list tools