An AI-powered multi-agent orchestration system with a control plane UI, kinetic layer for file operations, and LangGraph-based agent coordination. Supports task planning, execution, approval workflows, and git/filesystem operations.
Swarm-Lord exposes 4 file/git manipulation tools with minimal documentation. Tool names follow verb_noun convention (list_files, read_file, write_file, run_git), which is positive. However, descriptions are extremely brief (10-30 chars), parameter descriptions are missing or trivial, and input schemas lack proper type definitions and constraints. The 'tool' parameter in list_files and read_file is redundant and confusing. No output schemas are documented. Error handling is absent, no guidance on recovery or categorization. Security concerns are severe: write_file and run_git are destructive operations with no confirmation, permission checks, or audit trails. This server would not pass code review.
List files in the workspace directory
Read the contents of a file from the workspace
Execute git commands in the workspace directory
Write content to a file in the workspace
Descriptions are critically short (10-30 chars). Pattern requires 10-1024 chars with WHAT, WHEN, and prerequisites. E.g., 'List files in the workspace directory' lacks context on when to use it vs alternatives, what structure is returned, and any prerequisites.
Input schemas lack proper type definitions. 'tool' parameter in list_files/read_file is typed as string with description 'Must be list_files', this is a hardcoded constant, not a parameter. Schemas should define 'path' as string with format/pattern constraints (e.g., relative path, no traversal). No minLength, maxLength, or pattern validation.
No output schemas documented. Callers cannot know what fields list_files returns (array of strings? objects with metadata?), what read_file returns (raw content? with encoding?), or what run_git returns (stdout only? stderr? exit code?). LLMs cannot plan downstream calls without this.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Destructive operations (write_file, run_git) lack confirmation, permission checks, or audit trails. No dry-run support. Agents can overwrite files or execute arbitrary git commands without safeguards. Pattern requires confirmation_request for irreversible operations.
No error handling guidance. If write_file fails (permission denied, disk full, path traversal blocked), the response is likely a raw error or exception. LLMs need actionable recovery hints: 'Permission denied. Check workspace permissions or try a different path.' Pattern requires recovery-guide.