Homelab MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ssh_discoverA | SSH into a system and gather hardware/system information. If credentials were stored with |
| ssh_execute_commandA | Execute a command on a remote system via SSH. If credentials were stored with |
| start_interactive_shellA | Start an interactive web-based shell session on a remote system. Opens a browser-based terminal with full TTY support for running interactive commands and scripts. Perfect for Proxmox community scripts or any interactive command-line tools. Requires HTTP server mode (--http flag). In stdio mode, this tool returns an error with setup instructions. |
| discover_and_mapA | Discover a device via SSH and store it in the network site map database. Recommended follow-up: run the configure_host_fingerprint prompt to capture per-host capability signals for drift detection. |
| bulk_discover_and_mapA | Discover multiple devices via SSH and store them in the network site map database |
| get_network_sitemapA | Get all discovered devices from the network site map database |
| analyze_network_topologyB | Analyze the network topology and provide insights about the discovered devices |
| suggest_deploymentsB | Suggest optimal deployment locations based on current network topology and device capabilities |
| get_device_changesB | Get change history for a specific device |
| purge_failed_discoveriesA | Remove sitemap rows for devices where discovery failed (status='error' or empty/null/'unknown' hostname). Pass dry_run=true to preview the removal candidates without deleting them. (Equivalent to |
| purge_devicesA | Bulk-delete sitemap rows by filter. Single mutually-exclusive filter per call selected by filter_type. Supported filter_types: 'hostname' (exact-match string, no glob/LIKE), 'last_seen_older_than_days' (integer N — rows where last_seen < now - N days, exclusive boundary; N=0 matches all rows older than this instant), 'status' (exact match string like 'error' or 'success'), 'ip_range' (CIDR string like '192.168.1.0/24' or '2001:db8::/32' — rows whose connection_ip is not a valid IP are silently skipped). Composite/ANDed filters are NOT supported (use two calls). Pass dry_run=true to preview the candidate set without deleting. Zero-match returns success with purged_count=0, never an error. Note: filter_type='status', value='error' covers ONLY status='error' rows; use purge_failed_discoveries for the broader failed-discovery filter (includes zombie hostnames). Use |
| purge_devices_previewA | Preview the result of purge_devices without persisting. Returns the candidate set the bulk delete would touch. Read-only — no DB write. Phase 44 D-11. |
| remove_deviceA | Delete a single sitemap row by device_id. Pure SQL DELETE on the sitemap row plus cascade DELETE on discovery_history rows for that device_id. No SSH dial, no Ansible runs, no Terraform plans on the handler call path. The keyring credential entry bound via ssh_credential_id is preserved — only the sitemap row is dropped, so a subsequent discover_and_map can re-bind without re-adding the credential. Pass dry_run=true to preview the would-delete row payload without writing. Use |
| remove_device_previewA | Preview the result of remove_device without persisting. Returns the would-delete row payload. Read-only — no DB write, no keyring touch. Phase 44 D-11. |
| update_device_fingerprintA | Merge fingerprint data (kernel, OS, package digest, capabilities) into a device's sitemap row. Top-level keys overwrite (last-write-wins). The capabilities sub-dict updates one level deep — each incoming top-level capability key REPLACES its stored entry entirely (NOT a recursive merge); stored capability keys not present in the call are preserved. Callers updating any field within a capability must pass the full capability dict. Run discover_and_map first to populate the device. See the configure_host_fingerprint prompt for the conversational workflow. Persists to DB and bumps updated_at; last_seen is preserved (Phase 38 REVIEW-FIX WR-03). |
| update_device_fingerprint_previewA | Preview the merge result of update_device_fingerprint without persisting. Returns the would-be merged fingerprint dict using the same merge rules: top-level overwrite + capabilities one-level overwrite (incoming capability keys replace stored entries entirely; not recursive). Read-only — no DB write, no last_seen or updated_at mutation. Phase 38 D-05c. |
| deploy_infrastructureB | Deploy new infrastructure based on AI recommendations or user specifications |
| update_device_configA | Update configuration of an existing device |
| decommission_deviceA | Safely remove a device from the network infrastructure. Stops services, removes the device from clusters, optionally migrates services per migration_plan, then deletes the sitemap row. Use |
| scale_servicesB | Scale services up or down based on resource analysis |
| validate_infrastructure_changesA | Validate infrastructure changes before applying them |
| create_infrastructure_backupC | Create a backup of current infrastructure state |
| rollback_infrastructure_changesB | Rollback recent infrastructure changes |
| decommission_device_previewA | Preview what decommission_device would affect without executing. Returns a structured dry-run report. No infrastructure is modified. |
| rollback_infrastructure_changes_previewA | Preview what rollback_infrastructure_changes would affect without executing. Returns a structured dry-run report. No infrastructure is modified. |
| deploy_vmB | Deploy a new VM/container on a specific device |
| control_vmB | Control VM state (start, stop, restart) |
| get_vm_statusA | Get detailed status of a specific VM |
| list_vmsA | List all VMs/containers on a device |
| get_vm_logsA | Get logs from a specific VM/container |
| remove_vmC | Remove a VM/container from a device |
| remove_vm_previewA | Preview what remove_vm would affect without executing. Returns a structured dry-run report. No infrastructure is modified. |
| list_available_servicesA | List all available homelab services that can be installed |
| get_service_infoC | Get detailed information about a specific service |
| check_service_requirementsA | Check if a device meets the requirements for a service installation |
| install_serviceC | Install a homelab service on a target device |
| get_service_statusC | Get the current status of an installed service |
| plan_terraform_serviceA | Generate a Terraform plan to preview changes without applying them |
| destroy_terraform_serviceA | Destroy a Terraform-managed service and clean up all resources |
| refresh_terraform_serviceB | Refresh Terraform state and detect configuration drift |
| check_ansible_serviceB | Check the status of an Ansible-managed service deployment |
| run_ansible_playbookB | Run an existing Ansible playbook for a service |
| destroy_terraform_service_previewA | Preview what destroy_terraform_service would affect without executing. Returns a structured dry-run report. No resources are destroyed. |
| register_serverA | Verify SSH connectivity to a registered server using keyring credentials. Does not write any credentials — credentials must already be stored via |
| list_registered_serversA | List all registered servers with their SSH credentials and connection status |
| list_keyring_credentialsA | List hosts that have credentials stored in the OS keyring registry. Call this before ssh_discover or ssh_execute_command to check whether a host has stored credentials. Returns hostname and username per entry. |
| search_proxmox_scriptsA | Search Proxmox community installation scripts from the community-scripts/ProxmoxVE repository |
| get_proxmox_script_infoA | Get detailed information about a specific Proxmox community script |
| list_proxmox_resourcesB | List all Proxmox cluster resources (VMs, containers, nodes, storage). |
| get_proxmox_node_statusA | Get detailed status of a Proxmox node (CPU, memory, uptime, etc.) |
| get_proxmox_vm_statusB | Get status of a specific VM or container |
| manage_proxmox_vmC | Manage a VM or container (start, stop, shutdown, reboot, reset, suspend, resume) |
| create_proxmox_lxcB | Create a new LXC container on Proxmox |
| create_proxmox_vmB | Create a new VM (QEMU) on Proxmox |
| clone_proxmox_vmB | Clone a VM or container to create a new one |
| delete_proxmox_vmB | Delete a VM or container from Proxmox |
| delete_proxmox_vm_previewA | Preview what delete_proxmox_vm would affect without executing. Returns a structured dry-run report. No VM is deleted. |
| scan_infrastructure_driftA | Scan for infrastructure drift against the sitemap. Returns a four-bucket coverage report — probed_ok (sitemap host probed successfully), unreachable (sitemap host that did not respond), unknown (reserved for Phase 39 — infrastructure present on a Proxmox hypervisor but absent from sitemap), and changed (reserved for Phase 39 — fingerprint differs from stored). All four buckets are always present in the response (empty arrays for Phase-39-reserved buckets) so client code can iterate without defensive checks. Each scan also returns a counts sub-dict mirroring bucket sizes and, when zero hosts were scanned (empty sitemap or filter narrowed to zero), a top-level guidance field pointing to the sitemap CRUD tools (discover_and_map, get_network_sitemap, purge_failed_discoveries, decommission_device). Recovery from credential-resolution failure is handled via 'homelab-mcp credentials add --type proxmox'. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| decommission_device_workflow | Safe guided workflow for decommissioning a homelab device |
| deploy_service_workflow | Pre-flight checked service deployment workflow |
| homelab_health_check | Read all infrastructure resources and summarize homelab state |
| connect_to_device | Step-by-step onboarding workflow for connecting a new device to the homelab |
| configure_host_fingerprint | Conversational workflow for capturing per-host capability fingerprints (GPU passthrough state, Vulkan/CUDA versions, ZFS pool config, etc.) to enable Phase 39 changed-infrastructure drift detection. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Virtual Machines | Proxmox, Docker, and LXD VM/container inventory from all managed hosts |
| Device Inventory | All devices discovered on the homelab network via SSH and mDNS scanning |
| Services | Status of installed services (Docker, Proxmox, custom stacks) across all hosts |
| Drift Report | Latest infrastructure drift scan result. Four-bucket coverage report (probed_ok, unreachable, unknown, changed) with per-bucket counts and a conditional guidance field when no hosts were scanned. Populated by scan_infrastructure_drift; recovery via discover_and_map / get_network_sitemap / remove_device / purge_devices / purge_failed_discoveries / decommission_device. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/washyu/homelab_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server