ai-agents-mcp-itsops
Related Servers
Alternatives to ai-agents-mcp-itsops
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables MCP-compatible clients to semantically search, retrieve, and list engineering runbooks, providing relevant runbooks in response to natural language queries.MIT
- AlicenseNot gradedqualityBmaintenanceEnables operators and MCP clients to perform read-only, multi-cluster Kubernetes diagnostics by correlating deployment inventory, approved Prometheus metrics, firing alerts, and reusable troubleshooting skills without executing cluster commands or modifying workloads. It exposes tools, resources, and prompts for deployment health checks, metric queries, alert inspection, and skill discovery.MIT
- AlicenseAqualityDmaintenanceProvides access to Kubernetes troubleshooting runbooks, enabling search, discovery, and retrieval of guides for common issues like pod crashes, node problems, and network failures.3MIT
- FlicenseNot gradedqualityBmaintenanceEnables read-only Kubernetes incident investigation through MCP tools for listing pods, describing resources, fetching logs, and searching runbooks.1-
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to access and read mdbook documentation, including structure, content, and search.4 npm3MIT
- AlicenseBqualityCmaintenanceEnables stdio MCP clients to gather read-only diagnostics and incident evidence from Linux homelabs, including health, disks, services, Docker containers, logs, and confirmation-required remediation proposals.10MIT
TDQS
Scored across 4 tools
Each tool targets a clearly different resource: runbook search, local host health, k8s pod status, and a deliberate timeout probe. The only mild overlap is host_health vs k8s_pod_status, but the scope distinction (local lab host vs approved cluster/namespace) is stated explicitly, so confusion is unlikely.
All four names use consistent snake_case, which is the most important signal. Verb-led (search_runbooks) and noun-led (host_health, k8s_pod_status, slow_probe) patterns are mixed, but all names are readable and predictable within the set.
Four tools is on the thin side for an IT-ops server, with only read-only diagnostics and a synthetic probe. Each tool earns its place and nothing is redundant, but the surface feels minimal for the apparent domain.
The server provides a coherent read-only diagnostic surface (runbooks, host, pods) plus a timeout test, but omits common ops needs like logs, events, metrics, or any remediation/action tools. As a lab/read-only harness this may be intentional, yet agents will hit dead ends for anything beyond status checks.