endpoint-aiops-mcp
A governed AI-ops MCP server for managed-endpoint fleets: inspect fleet, session, drift, and patch state, and perform audited remediation writes with dry-run and undo support.
Get fleet overview and inventory:
overview,endpoint_list,endpoint_get,endpoint_health_score.Analyze login/boot sessions and detect login storms:
session_list,login_storm_analysis.Report configuration drift and patch status/compliance:
drift_report,patch_status,patch_compliance, including fleet-majority baseline derivation.Remediate endpoints:
endpoint_assign_profile(high-risk, reversible, captures prior profile) andendpoint_reboot(medium-risk, no safe inverse); both supportdry_run.List and apply recorded undo tokens:
undo_list,undo_apply, with single-use tokens andeffectVerifiedwarnings.Use built-in governance: every MCP/CLI call is audited, risk tiers are recorded, runaway calls are guarded, credentials are encrypted, targets/dialects are configurable, and analysis tools accept injected records for offline use.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@endpoint-aiops-mcp Check for patch drift in the fleet"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Endpoint AIops
Audit availability: Real writes require a committed
pendingaudit row and stop before contacting the platform if storage is unavailable. Reads and previews may continue with a warning; new audit rows store outcome summaries rather than full responses.
Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by any endpoint-management vendor. Product and trademark names belong to their owners. MIT licensed.
Governed AI-ops for managed-endpoint fleets — thin clients, VDI endpoints,
and other centrally-managed devices — with a built-in governance harness:
unified audit log, token/runaway budget guard, undo-token recording, and
descriptive risk tiers. Vendor-neutral: it talks to an
endpoint-management server's REST API (Bearer auth) through a configurable
dialect — see Dialects. Self-contained: no
dependencies beyond httpx and the MCP SDK. The test suite is mock-based; the
endpoint-management REST paths have not yet been exercised against a live
management server — see docs/VERIFICATION.md.
What it does
Two signature analyses, plus the guarded reads and writes around them:
Login-storm analysis — during a "everyone logs in at 9am" incident, detect the storm (bursts of concurrent logins in a sliding window) and rank the endpoints/users dragging login and boot times. Every flag is reported with its number, not a black-box verdict.
Patch / config drift — find endpoints that have drifted from the fleet (outdated patch level, stray agent version, divergent OS build or config profile). With no declared baseline it derives one by fleet majority, so it works before a gold image exists.
Related MCP server: aiops-mcp
What works
CLI (
endpoint-aiops ...):init,overview,endpoint list/get/assign-profile/reboot,session list/storm,drift report/patch,secret set/list/rm/migrate/rotate-password,doctor,mcp.MCP server (
endpoint-aiops mcporendpoint-aiops-mcp): 13 tools (10 read, 3 write), every one wrapped with the bundled@governed_toolharness.Encrypted credentials: the management-server API key lives in an encrypted store
~/.endpoint-aiops/secrets.enc(Fernet + scrypt) — never plaintext on disk. Unlock with a master password fromENDPOINT_AIOPS_MASTER_PASSWORD(MCP/CI) or an interactive prompt (CLI).Reversibility:
endpoint_assign_profile(highrisk) captures the prior profile and records an inverse "reassign the prior profile" undo descriptor.endpoint_reboot(mediumrisk) captures the prior online state for the audit record but declares no undo (a reboot has no safe inverse).Safety: state-changing CLI ops (
endpoint assign-profile,endpoint reboot) require double confirmation and support--dry-run.
Capability matrix (13 MCP tools)
Category | Tools | Count | R/W |
Overview |
| 1 | read |
Inventory |
| 3 | read |
Sessions |
| 2 | read |
Drift |
| 3 | read |
Remediation |
| 1 | write (high) |
| 1 | write (medium) | |
Undo |
| 1 | read |
| 1 | write (medium) |
The analysis tools (login_storm_analysis, drift_report, patch_status,
patch_compliance, endpoint_health_score) accept injected records for
pure/offline analysis; endpoint_health_score and patch_compliance are
injected-only, the others also pull live from a configured target.
What this tool does, and does not, decide
It delivers managed-endpoint 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 account you connect it with: give it a management-console account or API token scoped to a read-only role 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 ~/.endpoint-aiops/audit.db,
and reversible 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 write. It is a label, not a gate.
Running a smaller / local model? See agent-guardrails.md — it lists the guardrails this tool now enforces for you (so you don't spend prompt budget restating them) and gives a ready-made system prompt for what's left.
Payload conventions
Absent is not empty. A field the management server did not report comes back as
null, never as""— the key is always present, so a missing patch level cannot be mistaken for a blank one.Capped lists announce themselves. Any list a
limitcan cut short is a truncation envelope:{"items": [...], "returned": N, "limit": L, "truncated": bool}, withtruncatedmeasured rather than inferred. Companion totals (driftedCount,behindCount,nonCompliantCount,stormCount, the healthsummary) are always the full, uncapped figures.
Quick start
As a Claude Code plugin
One install gives an agent both the skill and the MCP server:
/plugin marketplace add AIops-tools/marketplace
/plugin install endpoint-aiops@aiops-toolsThe MCP server is fetched with uv and pinned to the
package version this plugin declares, so an audit row can be traced back to the
code that wrote it. Credentials are still configured with endpoint-aiops init — see below.
As an OpenClaw plugin
The same bundle is published on ClawHub, where one install delivers the skill and its MCP server together:
openclaw plugins install clawhub:@zw008/endpoint-aiops
openclaw skills info endpoint-aiops # expect: Visible to model: yesRestart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is
fetched with uv, pinned to this exact release, so
uvx has to be on PATH — without it the skill still installs but reports
Visible to model: no. Credentials are configured exactly as below.
As a CLI or standalone MCP server
uv tool install endpoint-aiops # or: pipx install endpoint-aiops
endpoint-aiops init # wizard: add a target + store its API key (encrypted)
endpoint-aiops doctor # verify config, secrets, connectivity
endpoint-aiops overview # one-shot fleet health
endpoint-aiops session storm # detect a login storm + slow contributors
endpoint-aiops drift report # endpoints drifted from the fleet baselineRun as an MCP server (stdio):
export ENDPOINT_AIOPS_MASTER_PASSWORD=... # unlock secrets non-interactively
endpoint-aiops-mcpWhere that password then lives: an exported variable is readable by every process this shell starts and is recorded by shell history. On a shared or long-lived host, prefer the interactive prompt, or inject it from a secret manager for the life of the one command that needs it.
Governance
Every operation — MCP and CLI — passes through the bundled @governed_tool
harness. It records; it does not authorize (see above).
Audit — every call (params, outcome summary, status, duration, risk tier, and any operator-supplied approver/rationale) is logged to
~/.endpoint-aiops/audit.db(relocatable viaENDPOINT_AIOPS_HOME). The CLI writes the same row the MCP path does — there is no unaudited entry point.Runaway guard — a safety backstop, not an authorization gate: the same call hammered in a tight loop trips a circuit breaker so a stuck agent can't burn unbounded calls/time. Disable with
ENDPOINT_RUNAWAY_MAX=0; optional hard ceilings viaENDPOINT_MAX_TOOL_CALLS/ENDPOINT_MAX_TOOL_SECONDS.Undo recording — reversible writes record an inverse descriptor built from the fetched before-state.
Risk tier — a descriptive label on the audit row derived from
risk_level; it gates nothing.
Scope
This is the IT-endpoint member of the AIops-tools family (governed AI-ops
with audit + budget + undo + risk tiers). For OT / industrial edge
(Modbus, OPC-UA, PROFINET, …) see the separate industrial-aiops line.
Dialects — which server are you actually pointing at?
A dialect is the management server's API shape: resource paths, response
field names, the transport defaults (port + API base path), and how to
authenticate. Set it per target in config.yaml; endpoint-aiops init asks
for it and prints which one it configured.
Dialect | Transport | Auth | Status |
|
| static Bearer API key | Neutral placeholder — not a real vendor API. Useful only once you describe your server's paths in a |
|
| HTTP Basic login → | Documented-but-unverified dialect for IGEL UMS (IMI). This is not a claim that IGEL is supported — see Status. |
targets:
- name: ums1
host: ums.example.local
dialect: igel-ums # IMI paths, port 8443, /umsapi/v3, Basic-login auth
username: ums-admin # UMS account; the password lives in secrets.enc
scheme: https # or 'http' for a reverse-proxied server
verify_ssl: false # self-signed lab UMS onlyThe generic default is not an IGEL configuration and never was: IGEL
serves IMI at /umsapi/v3 on 8443, so a target left on the generic shape 404s
on its first probe. That mismatch is why the preset exists.
Where a server genuinely has no such resource, the dialect says so rather than
guessing a URL — IMI exposes no login/boot session resource, so session_list
and login_storm_analysis on an igel-ums target return a teaching error
naming the absent resource instead of calling an invented path.
A dialect selects the auth scheme too, not just paths — IMI rejects the
static Bearer token the generic dialect sends, so it logs in with HTTP Basic at
POST /umsapi/v3/login and carries the returned JSESSIONID cookie (once per
connection, then cached). Because the scheme comes from the dialect, a
credentials failure and a wrong-dialect failure are reported differently: a
401 names the scheme presented and, when the server sends a WWW-Authenticate
challenge, the scheme it actually wants — so a dialect mismatch does not send
you off rotating a perfectly good key.
⚠️ Note for IGEL specifically: a UMS account with too few permissions receives
empty lists rather than a 403. endpoint-aiops doctor authenticates as a
step separate from its reachability probe and warns when a successful login
returns no endpoints, because "no devices" and "not allowed to see the devices"
are otherwise indistinguishable.
Status
The test suite is mock-based. No dialect in this package has been exercised against a real management server, so this package does not claim support for any specific product — including IGEL.
genericis a placeholder shape, not a vendor API.igel-umsis a documented-but-unverified dialect. Its paths and field aliases are modelled from IGEL's published IMI documentation; its auth scheme is documented in the IMI manual and matches what three independent real-world IMI clients do. Neither has been run against an appliance by this project — IGEL UMS has no free edition, so it cannot be verified on the maintainer's hardware.
Both are recorded as UNKNOWN-pending-live in
docs/VERIFICATION.md, which ranks what a live run is
most likely to find wrong and defines the checklist it must cover. If you have a
UMS and run that checklist, the results are very welcome as an issue. Missing a
capability or a server dialect? Open an issue or PR — contributions welcome.
Available Tools
13 toolsdrift_reportARead-only
[READ] Report endpoints drifted from a per-field baseline (patch/agent/OS/profile).
Answers "which endpoints have drifted from the fleet?" With no baseline it derives one by fleet majority (the most common value per field is treated as intended), so it works before any gold image is declared. Pass 'endpoints' for pure analysis, or a target to pull live inventory.
Args: baseline: Field→intended-value map; omit to derive the fleet majority. fields: Inventory fields to check (default agentVersion, patchLevel, osBuild, profileId). endpoints: Injected inventory rows; skips live collection. target: Endpoint-management target name from config; omit for the default. limit: Max drifted endpoints to return (default 200).
Returns dict: {totalEndpoints, baselineSource, baseline, fieldsChecked, driftedCount, compliantCount, driftByField, driftedEndpoints:{items[], returned, limit, truncated}}. driftedCount is the full count; when driftedEndpoints.truncated is true, re-run with a higher limit.
Example: drift_report(endpoints=[{"hostname":"tc01","patchLevel":"2026-06"}, {"hostname":"tc02","patchLevel":"2026-05"}]).
Inputs: limit, fields, target, baseline, +1 more.
endpoint_assign_profileADestructive
[WRITE][risk=high] Assign a config profile to an endpoint (reversible).
Captures the prior profile before switching, so the harness records an undo (reassign the prior profile) and a faithful audit trail. Pass dry_run=True to preview: it resolves the same path and reads the same before-state as the real call, so it reports the profile that would actually be replaced and refuses on the same grounds the write would.
Args: endpoint_id: Endpoint id as returned by endpoint_list. profile_id: Config profile to assign. dry_run: If True, preview without assigning. target: Endpoint-management target name from config; omit for the default.
Inputs: profile_id (required), endpoint_id (required), target, dry_run.
endpoint_getARead-only
[READ] One managed endpoint by id, normalised to the stable shape.
Args: endpoint_id: Endpoint id (or uuid/mac) as returned by endpoint_list. target: Endpoint-management target name from config; omit for the default.
Inputs: endpoint_id (required), target.
endpoint_health_scoreARead-only
[READ] Composite per-endpoint health score (0-100), worst endpoints first.
Answers "which endpoints are worst?" by folding the fleet signals into one ranked view: it deducts points for each risk signal (offline, stale, patch-behind, agent-behind) and cites every deduction in the endpoint's 'reasons'. Pure analysis over injected inventory rows (the shape from endpoint_list) — no live connection is used. With no baseline, the patch and agent baselines are derived by fleet majority, so it works before a gold image is declared.
Args: endpoints: Injected inventory rows (id, hostname, online, lastSeenHours, agentVersion, patchLevel) to score. Required — no live pull. stale_hours: An endpoint whose lastSeenHours >= this is 'stale' (default 24). baseline: Intended {'agentVersion', 'patchLevel'}; omit to derive the fleet majority. limit: Max worst-first endpoints to return (default 50).
Returns dict: {endpointsEvaluated, baseline:{agentVersion, patchLevel, source}, summary:{healthy, degraded, critical}, worst:{items:[{endpoint, score, band, reasons[]} ...worst-first], returned, limit, truncated}, note}. The summary always counts the whole fleet; when worst.truncated is true, re-run with a higher limit to see further down the ranking.
Example: endpoint_health_score(endpoints=[ {"hostname":"tc01","online":True,"agentVersion":"12.6","patchLevel":"2026-06"}, {"hostname":"tc02","online":False,"agentVersion":"12.5","patchLevel":"2026-05"}]).
Inputs: endpoints (required), limit, baseline, stale_hours.
endpoint_listARead-only
[READ] List all managed endpoints (id, hostname, OS, agent/patch, online).
Args: target: Endpoint-management target name from config; omit for the default.
Inputs: target.
endpoint_rebootADestructive
[WRITE][risk=medium] Request an endpoint reboot (no safe inverse).
Records the endpoint's prior online state for the audit trail; a reboot cannot be undone, so no undo descriptor is offered. Pass dry_run=True to preview — for an operation with no inverse, knowing whether the endpoint is even online (and how long since it was last seen) before committing is the whole value of asking first.
Args: endpoint_id: Endpoint id as returned by endpoint_list. dry_run: If True, preview without rebooting. target: Endpoint-management target name from config; omit for the default.
Inputs: endpoint_id (required), target, dry_run.
login_storm_analysisARead-only
[READ] Detect login storms + rank the slowest login/boot contributors.
Answers "is this a morning login storm, and which endpoints/users are dragging login and boot times?" Groups logins into storm episodes (>= min_concurrent within a window_s sliding window) and flags sessions slower than the thresholds — every flag is reported with its number, not a verdict. Pass 'sessions' for pure analysis, or a target to pull live via session_list.
Args: since_hours: Live look-back window when sessions is omitted (default 24). window_s: Sliding window that defines "concurrent" logins (default 300). min_concurrent: Logins within a window that constitute a storm (default 10). slow_login_ms: Login duration (ms) flagged as slow (default 30000). slow_boot_ms: Boot duration (ms) flagged as slow (default 90000). sessions: Injected session records — {endpoint, user, login_ms, boot_ms, timestamp (ISO-8601), result}; skips live collection. target: Endpoint-management target name from config; omit for the default. limit: Max rows in each returned list (default 25).
Returns dict: {totalSessions, sessionsReceived, inputTruncated, stormCount, storms:{items:[{start, end, count, peakConcurrent, spanS, distinctUsers, distinctEndpoints, avgLoginMs}], returned, limit, truncated}, slowLoginCount, slowestByLogin:{items[], ...}, slowestByBoot:{items[], ...}, failedLogins, thresholds}. Each list is a truncation envelope — when its 'truncated' is true, re-run with a higher limit; stormCount is the full episode count.
Example: login_storm_analysis(sessions=[{"endpoint":"tc01","user":"a", "login_ms":42000,"timestamp":"2026-07-12T08:00:00Z"}, ...]).
Inputs: limit, target, sessions, window_s, +4 more.
overviewARead-only
[READ] One-shot fleet health: online/offline, stale endpoints, version spread.
Call this first to triage a managed-endpoint fleet before drilling into a specific endpoint, login storm, or drift report.
Args: target: Endpoint-management target name from config; omit for the default.
Inputs: target.
patch_complianceARead-only
[READ] Patch-compliance SLA measure: % of the fleet on the target patch level.
Reframes patch_status (the patch-level distribution) as an SLA/compliance verdict: what fraction of the fleet is on the target level, whether that meets the SLA, and which endpoints are non-compliant. Compliance is an exact string match on patchLevel — a transparent check, not a version-semantics parser. Injected-only: pass 'endpoints' (inventory rows); no live collection.
Args: endpoints: Injected inventory rows to evaluate (e.g. from endpoint_list). target_patch: Desired patch level; omit to use the fleet-majority level. sla_pct: Compliance SLA threshold percent; default 95.0. limit: Max non-compliant endpoints to return (default 200).
Returns dict: {endpointsEvaluated, targetPatch, targetSource, slaTargetPct, complianceRatePct, compliantCount, verdict, nonCompliantCount, nonCompliant:{items[], returned, limit, truncated}, note}. The rate is always computed over the whole fleet, never over the capped list.
Example: patch_compliance(endpoints=[{"hostname":"tc01","patchLevel":"2026-06"}, {"hostname":"tc02","patchLevel":"2026-05"}], target_patch="2026-06").
Inputs: endpoints (required), limit, sla_pct, target_patch.
patch_statusARead-only
[READ] Patch-level distribution + which endpoints are behind the target level.
Args: target_patch: Desired patch level; omit to use the fleet-majority level. endpoints: Injected inventory rows; skips live collection. target: Endpoint-management target name from config; omit for the default. limit: Max behind-endpoints to return (default 200).
Returns dict: {totalEndpoints, targetPatch, targetSource, distribution, behindCount, behind:{items[], returned, limit, truncated}}. behindCount is the full count; when behind.truncated is true, re-run with a higher limit.
Inputs: limit, target, endpoints, target_patch.
session_listARead-only
[READ] Recent login/boot sessions (endpoint, user, login_ms, boot_ms, result).
Args: since_hours: Look-back window in hours (1..720, default 24). target: Endpoint-management target name from config; omit for the default.
Inputs: target, since_hours.
undo_applyADestructive
[WRITE][risk=medium] Apply a recorded undo by dispatching its inverse tool.
The inverse runs through its own governed tool, so its real risk tier is recorded there. Pass dry_run=True to preview the inverse call without executing it. A token can only be applied once.
Args:
undo_id: The undoId from undo_list (or an _undo_id in a write result).
dry_run: If True, preview the inverse tool + params without running it.
target: Passed through to the inverse tool when it accepts a target.
Inputs: undo_id (required), target, dry_run.
undo_listARead-only
[READ] List recorded, not-yet-applied undo tokens (most recent first).
Each entry names the original tool, the inverse tool that undo_apply
would run, and a human note. Use the undoId with undo_apply.
Each entry carries effectVerified. False means the original write
lost its response, so the change it reverses is PROBABLE, not confirmed —
check the live state before applying, and do not report the result as a
restore of a state that may never have been reached.
Args: limit: Max rows to return (1..500, default 50). target: Unused (undo state is host-local); accepted for CLI uniformity.
Returns dict: {undos[], returned, limit, truncated}. One extra row is fetched, so 'truncated' is measured rather than guessed from the returned count happening to equal the limit; re-run with a higher limit when true.
Inputs: limit, target.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 13 tools
Most tools are distinct, but there is meaningful overlap in the fleet-analysis cluster: patch_compliance is explicitly a reframe of patch_status, drift_report and endpoint_health_score both fold the same baseline-derived signals, and overview overlaps with the list/health tools. The descriptions do a good job explaining the boundaries and relationships, which keeps agents from misselecting, but several tools answer very similar 'how is the fleet doing' questions.
Naming is consistently snake_case and resource-prefixed (endpoint_*, patch_*, session_*, undo_*, drift_report), giving a readable, predictable pattern. Minor deviations exist where action verbs and noun descriptors are mixed (endpoint_health_score, login_storm_analysis) and the bare 'overview' breaks the prefix convention, but overall it is coherent.
13 tools is well within the ideal range and each earns its place across triage, analysis, write, and undo categories. The surface is neither thin nor bloated for a fleet-management/aiops server.
The set covers read/analysis (inventory, drift, patch, health, sessions), write actions (assign profile, reboot), and a governed undo lifecycle, which is solid lifecycle coverage. Gaps remain: no profile inventory/listing tool, and no direct patch-remediation action despite heavy patch analysis, but agents can work around these.
Maintenance
Related MCP Connectors
Autonomous and governed SRE & MLOps control plane for AI agent platforms.
AI-native GRC: compliance scores, security findings, tickets and agent trust tiers.
Enterprise AI Control Plane: governance, guardrails, spend tracking, compliance & smart routing.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceAI Governance and SecOps platform for remote servers1-
- AlicenseAqualityBmaintenanceA self-contained, security-first, EU-sovereign unified AI-operations MCP server that fuses a live bitemporal fleet model, a drift engine, and a tiered audited actuator into one control plane.5Apache 2.0
- AlicenseAqualityBmaintenanceGoverned AI-ops for Ceph, providing root-cause health analysis and guarded destructive operations via a built-in governance harness with risk tiers, audit, and undo recording.37MIT
- AlicenseAqualityBmaintenanceGoverned network controller-layer operations (Cisco Meraki, plus Catalyst Center / Arista CVP / UniFi) — uplink loss/latency RCA, fleet health scoring, and config-template drift, with unbypassable audit logging (MCP + CLI), budget/runaway guards, and rollback.37MIT