HomeFleet per-machine daemon (MCP front, node service, discovery, dispatch) — a distributed job delegation system with local agent execution, workspace sync, and artifact management
HomeFleet demonstrates solid tool design with comprehensive schemas, clear descriptions, and thoughtful error handling. All 12 tools have explicit input/output schemas with type definitions and parameter descriptions. Tool names follow verb_noun conventions (list_nodes, delegate_task, read_file, write_file). Descriptions average ~150 chars and explain WHAT, WHEN, and consequences. However, some parameter descriptions lack format/constraint details, and output schemas could be more explicit about field semantics. Error handling is production-grade with recovery guidance. Security posture is strong (no secrets in params, path traversal guards on .git). Composition is clean, each tool has one responsibility, and outputs chain well (jobId returned by delegate_task feeds into job_status/job_result/cancel_job).
Cancel a running or pending delegated job
Delegate a task (recon, command, or write) to a paired worker node. Syncs the named repo to the worker before delegating; the agent supplies only a repoId, the daemon resolves it to its local repo path, syncs that repo's current HEAD to the worker, and uses the SYNCED commit as the job's WorkspaceRef
Edit a workspace text file by exact-match replace: fails unless oldText occurs exactly once; that single occurrence is replaced with newText. Paths are relative to the workspace root; anything under .git is refused.
Find files matching a glob pattern in the workspace. Supports *, **, and ? wildcards. Returns up to 1,000 results.
Search for a regex pattern in workspace files. Skips .git and node_modules directories. Returns up to 100 matches across files scanned up to 16 MiB total.
Retrieve the terminal result of a delegated job (once SUCCEEDED, FAILED, or CANCELED). For write jobs, also surfaces the lazy-apply outcome: artifactStatus (applied/failed/none), reviewCommand (when applied), and applyError (when apply failed)
Parameter descriptions lack explicit format/constraint details. E.g., 'pattern' in grep is described as 'Regular expression pattern' but does not state regex flavor, max length, or escaping rules. LLMs benefit from concrete constraints like 'PCRE regex, max 1024 chars'.
Output schema for job_result does not explicitly document the structure of 'artifactStatus', 'reviewCommand', and 'applyError' fields. The code comment mentions these are 'lazy-apply outcome' fields, but the schema definition is not visible in the provided source. This forces LLMs to infer field semantics.
delegate_task accepts a complex oneOf schema with three task types (recon, command, write), each with different required fields. The description does not explain when to use each type or how to choose between them. LLMs may struggle to construct valid payloads without trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 84 | 2026-07-28+ | v2 |
Poll the status of a delegated job (PENDING, RUNNING, SUCCEEDED, FAILED, CANCELED)
List the contents of a workspace directory. Paths are relative to the workspace root.
List all paired nodes with their identity, reachability status, and live capabilities (roles, executors, models, active jobs)
Read a text file from the workspace. Paths are relative to the workspace root. Content is capped at 65,536 bytes.
Execute an allowlisted shell command in the workspace. Only available when the command allowlist has entries. Aborts on cancellation signal or timeout.
Create a new text file or completely replace an existing one. Missing parent directories are created. Content is UTF-8, at most 1,048,576 bytes. Paths are relative to the workspace root; anything under .git is refused.
run_command description states 'Only available when the command allowlist has entries' but does not explain how an LLM discovers what commands are allowlisted. This creates a discovery gap, the agent cannot know which commands are safe to invoke without calling the tool and failing.
Error handling is strong overall, but error messages are not visible in the provided source code. The comment states 'Errors follow the MCP tool-error convention' and 'phrased so the agent can tell X from Y', but actual error response examples are not shown. Cannot verify error messages are actionable and recovery-guiding.