Loading ToolBench
MCP server to operate the home AI lab — diagnostics, model ops, and gated remote commands across the Mac mini and Alienware.
Lab-control-mcp has clear, domain-specific tool names and generally good descriptions (avg 180 chars, within baseline 194). All 7 tools have input schemas with types and descriptions. However, several tools lack parameter constraints (enums for 'host', 'model', 'command'), and error handling is not documented, LLMs won't know how to recover from invalid inputs or permission denials. Output schemas are not documented. Tool composition is reasonable (single responsibility), but run_command's allowlist mechanism is opaque to the LLM, it cannot predict which commands will succeed. Security annotations (readOnlyHint/destructiveHint) are present and correct.
Run inference through the LiteLLM gateway. Args: prompt: The user prompt. model: Gateway model alias — `chat`/`code`/`embed` are free local models; `claude` is the paid escalation (budget-capped). Defaults to free `chat`. max_tokens: Max tokens to generate.
Health of every lab service: gateway (LAN + Tailscale), Ollama (GTX; M4 only if configured), Qdrant, Postgres exposure (null = not checkable from here).
List the Ollama models on the Alienware (gtx), plus the Mac mini (m4) if OLLAMA_M4 is set.
Pull an Ollama model onto a host. Args: host: 'm4' (Mac mini) or 'gtx' (Alienware). name: Model name, e.g. 'llama3.1:8b'.
Re-apply / restart the Alienware stack (LiteLLM, Qdrant, Postgres) via its deploy script.
Run an ALLOW-LISTED command on a lab host. Safety: shell metacharacters (; | & < > ` $ \) are rejected, and the command must match the configured allowlist. Disallowed commands return a structured error (not an exception). Output is captured and truncated. Args: host: 'mini' (Mac mini, run locally) or 'alienware' (run over SSH). command: The command to run (must be allow-listed). timeout: Seconds (0 = configured default).
run_command lacks parameter constraints and error guidance. 'host' and 'command' accept free-form strings; LLMs cannot predict which commands are allowlisted or what happens on rejection. Description mentions 'structured error' but does not document the error response format or recovery path.
pull_model and gpu_generate accept 'host' and 'model' as free-form strings without enums. 'host' should be enum ['m4', 'gtx']; 'model' should be enum ['chat', 'code', 'embed', 'claude']. LLMs will hallucinate invalid values.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does lab_status return a dict with 'gateway', 'ollama', 'qdrant' keys?). Breaks tool chaining.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Run local-agent-lab's smoke tests on the Mac mini and return the output.
Error handling not documented. What does run_command return when a command is not allowlisted? What does pull_model return on network failure? LLMs have no recovery guidance.
gpu_generate description includes example model names ('chat', 'code', 'embed', 'claude') in prose rather than as enum constraints. LLMs may treat these as examples and hallucinate variants like 'chat-v2' or 'code-large'.