homebutler
Related Servers
Alternatives to homebutler
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceMCP server for homelab diagnostics + auto-update pipeline, managing Docker hosts via SSH with read-only diagnostics, image-drift visibility, and automated update execution with rollback.MIT
- AlicenseNot gradedqualityDmaintenanceMCP servers for managing homelab infrastructure. Monitor Docker/Podman containers, Ollama AI models, Pi-hole DNS, Unifi networks, and Ansible inventory.44MIT
- AlicenseNot gradedqualityCmaintenanceMCP server and CLI for host and container operations, enabling Docker and Compose control, SSH, host inspection, logs, ZFS, and safe file transfer. It exposes flux and scout MCP tools with parity from the original TypeScript server.2AGPL 3.0
- AlicenseNot gradedqualityCmaintenanceProvider-agnostic MCP server for managing heterogeneous infrastructure (SSH, Proxmox VE, Virtualizor, Hetzner Cloud, Cloudflare) via a JSON inventory, exposing tools for VM/container management, DNS, firewalls, and SSH operations.MIT
- FlicenseNot gradedqualityBmaintenanceA self-hosted MCP server for homelabs with ~193 tools covering media, home automation, productivity, infrastructure, and public APIs, featuring a web dashboard for configuration and health monitoring.2-
- AlicenseNot gradedqualityCmaintenanceA single MCP server that gives an AI assistant comprehensive access to manage a homelab, including SSH, Docker, Proxmox, Synology, Cloudflare, and more, with 85 tools and a centralized configuration.MIT
TDQS
Scored across 44 tools
Tools are organized into clear families (docker_, install_, backup_, watch_, proxmox_, inventory_) with distinct resource+action targets, and the descriptions go out of their way to explain boundaries such as install_uninstall vs install_purge and backup_list vs backup_drill. The main soft spots are the diagnostics cluster — alerts, alerts_history, doctor, report, and to a lesser degree system_status — which all answer overlapping "is my server healthy" questions and require reading descriptions carefully to choose. Docker_stop vs install_uninstall also overlap conceptually, though the descriptions disambiguate them.
Nearly all tools follow a namespace_action pattern (docker_list, backup_create, watch_add, proxmox_guest_start, install_status), giving a predictable, scannable surface. The deviations are a handful of bare noun names (alerts, doctor, report, processes, wake, system_status, open_ports, proxmox_status, proxmox_node) that break the verb_noun expectation but stay readable and non-colliding. No camelCase/snake_case mixing.
44 tools is heavy for a single server and pushes past what an agent can hold in working context comfortably, even though the families are well organized and most tools earn a distinct place. There is real consolidation potential in the diagnostics area (alerts, alerts_history, doctor, report) and in the Proxmox read tools (proxmox_status, proxmox_node, proxmox_tasks, proxmox_task_status, proxmox_guests). The breadth is defensible given the domain spans Docker, Proxmox, backups, app installs, and monitoring, so it is not arbitrary bloat.
Coverage is unusually thorough: full lifecycle for app installs (install/status/uninstall/purge), backups (create/list/restore/drill), watch targets (add/remove/list/check/history), Docker inspection and control, and Proxmox guest and node operations. The one acknowledged gap is the absence of a docker_start to pair with docker_stop, which forces operators to bring containers back manually; other omissions (no docker exec, no config write, no supervisor install) appear deliberate and are documented as such. Minor gaps only, most with stated rationale.