Loading ToolBench
Homelab inventory collector - collects and aggregates infrastructure data from multiple sources (Proxmox, Hetzner Cloud, Dockhand, UniFi, Tailscale) via MCP tools
homelib presents a moderately well-structured tool interface for infrastructure management. Tool naming follows verb_noun conventions consistently (list_*, get_*, trigger_*), which is excellent for LLM discoverability. However, critical gaps emerge in schema completeness and parameter descriptions. Approximately 60% of tools lack comprehensive input parameter schemas or have minimal parameter documentation. Output schemas are not visible in the provided source, only input parameters are documented. Error handling exists but lacks recovery guidance or classification (retryable vs fatal). The codebase uses mark3labs/mcp-go (v0.44.1), indicating proper MCP protocol integration, but optional features like tool annotations, structured error reporting, and resource/prompt support are absent.
Get Tailscale ACL policy configuration
Get compute capacity analysis: CPU, memory, and disk allocation by node and zone
Get current collection run progress and latest completed collection metadata
Get Tailscale DNS configuration and nameserver mappings
Get detailed information about a specific host including services and configuration
Get Tailscale subnet routes and route distribution
Get high-level summary statistics: host counts by source, zone, and type
List security and configuration findings, optionally filtered by source and severity
List all hosts in the inventory with optional filtering by source, zone, status, type, or search query
No output schemas documented. Tools return JSON results but expected fields, types, and structure are not formally specified. LLMs cannot reliably extract data or plan downstream calls without knowing what fields will be present.
Seven tools (list_networks, get_acl, get_dns, get_routes, get_summary, get_collection_status, get_capacity) have zero or minimal input parameters. Descriptions are generic (10-50 chars, e.g., 'List all networks'). Too brief to guide LLM selection when multiple discovery tools exist.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
List all networks discovered in the infrastructure
List services/containers running on hosts, optionally filtered by host and stack name
Full-text search across hosts, services, and findings
Start a new inventory collection run asynchronously across all configured sources
Error handling returns mcp.NewToolResultError() with basic messages but provides no recovery guidance. Errors like 'failed to get hosts: <err>' do not tell LLM whether to retry, ask user, or abandon. Missing error categorization (retryable, user-fixable, fatal).
No pagination support visible. Tools like list_hosts, list_services, list_findings return all matching results. Large result sets will blow context window. No limit parameter or cursor/offset pagination documented.
Parameter documentation incomplete. Parameters like 'source', 'zone', 'status', 'type', 'search' lack descriptions of valid values or constraints. Descriptions do not specify enum options, format (e.g., what constitutes a valid host type), or examples of valid inputs.
Destructive operation (trigger_collection) lacks confirmation mechanism or dry-run option. LLM could unintentionally trigger data collection runs repeatedly. No explicit permission checks visible.
Tool composition: get_host returns both host and services in one response (good), but search() and list_findings() do not indicate whether they return necessary IDs for downstream tools. If search returns a host_name, can an LLM pass it directly to get_host? Not clear.