Inference AIops MCP server
Governed GPU inference ops (vLLM + Ray Serve): latency RCA, scaling, drain, 39 tools.
not scanned yet
0 stars109 downloads/wk
Reviews
Write oneNobody has reviewed Inference AIops yet.
If you have run it, two minutes of your experience saves the next person an afternoon.
Inference AIops tools
No tool declarations could be read from the package source. They show once the server is installed.
How Inference AIops compares
Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.
- Safety score
- 91/100
- higher than 85% of 48,255 servers
- Downloads a week
- 109
- more than 65% of 12,191 servers with a package
Release history: 3 versions in the registry since 2026-09-16, latest 2026-10-30, typically one every 28 days.
Install Inference AIops in Claude Code, Cursor or VS Code
claude mcp add inference-aiops -- uvx inference-aiops
What the publisher says
From the Inference AIops repository's README, as published. We do not edit it. Read it on GitHub
<!-- mcp-name: io.github.AIops-tools/inference-aiops -->
Inference AIops
Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by the vLLM or Ray projects or any inference-serving vendor. Product and trademark names belong to their owners. MIT licensed.
Governed AI-ops for GPU inference clusters — vLLM (OpenAI API + Prometheus /metrics) and Ray Serve / Ray Jobs (Ray dashboard), plus the single-process serving engines SGLang and TGI (Text Generation Inference) — with a built-in governance harness: unified audit log, policy engine, token/runaway budget guard, undo-token recording, and descriptive risk-tier labels on every audit row. It parses each engine's Prometheus /metrics directly (no Prometheus server required) and probes the Ray dashboard independently. A bearer token is optional (many stacks run open).
Serving engines. vLLM is the flagship (full Ray Serve control plane: scale, drain, autoscale, LoRA, hot-swap). SGLang and TGI are supported for engine-agnostic observability — health, running-model identity, request-latency metrics, queue depth, and latency RCA — read from each engine's own endpoints and metric names. Being single-process servers, they have no Ray-shaped scale/drain API: those writes return a teaching error pointing you at a real horizontal-scale layer (Ray Serve / Kubernetes / a load balancer).
What it does
The flagship value is root-cause analysis, wrapped in guarded reads and writes:
climbs, it correlates queue depth (running vs waiting), KV-cache pressure / preemptions, and prefix-cache locality into a ranked cause plus the specific knob to turn (add replicas, raise max-num-seqs, fix routing, enlarge KV cache). Every flag is a number, not a black-box verdict.
- diagnoselatencyspike (flagship RCA) — when TTFT/TPOT/e2e latency
replicas, or routing that strands a cache-warm replica → what to scale down.
- diagnoselowutilization — the inverse: idle GPUs, over-provisioned
Prometheus/Grafana deployment needed.
- Prometheus-native — reads vLLM's /metrics endpoint directly; no
audit + budget + risk-tier approval + undo-token + prompt-injection sanitize, with dry-run + double-confirm on the fragile prod ops (scale-down, scale-to-zero, drain, redeploy, hot-swap) the community reports as dangerous.
- Governance-grade — the first governance-grade entrant in this niche:
or CPU-mock + Ray in one local container (ray start --head).
- Laptop self-test — ~80% of the tool self-tests free: vLLM on a single GPU
What this tool does, and does not, decide
It delivers inference-cluster operations — reads and writes — accurately and efficiently, and records every one of them. It does not decide whether a write is allowed to happen. That is the agent's judgement, or the permission of the environment you connect it with: restrict the network path so it can only reach the read/metrics endpoints, or run the Ray dashboard without its job-submission API, and the writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure. The one thing the tool guarantees is that nothing is silent: every call, over MCP and over the CLI alike, lands an audit row in ~/.inference-aiops/audit.db, and destructive writes still capture their before-state and record an inverse where one exists.
Each tool declares a risk_level, kept in agreement with its [READ]/[WRITE]
documentation tag by a test, and carried into the audit row as a descriptive
tier — so a reviewer can see at a glance that a row was a high-risk
scale-to-zero. It is a label, not a gate.
Shortened. The full README is on GitHub.
Nothing above is checked by us. What we check is on the safety report.
Inference AIops: common questions
- Is Inference AIops MCP server safe?
- Yes, by our scan: it is graded A (91/100). Read the Inference AIops safety report
- How do I install Inference AIops?
- It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
- Does Inference AIops need an API key?
- Not as far as the registry entry and our scan can tell: no credentials are declared or required.
- Is Inference AIops maintained?
- The last commit was 48 days ago (2026-09-16). The latest release is v0.13.0.
- How does Inference AIops compare with other MCP servers?
- safety score 91/100 (higher than 85% of 48,255 servers); downloads a week 109 (more than 65% of 12,191 servers with a package). Full comparison.