MCP server for hierarchical Claude instance orchestration via tmux, enabling Executive instances to spawn Managers and Managers to spawn Specialists with role-based access control
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has severe definition quality issues across nearly all 19 tools. While schemas are present for most tools, descriptions are generic and often lack actionable guidance. Parameter descriptions are sparse or missing entirely. Many tools exhibit overlapping functionality (e.g., send, enhancedSend, send_message patterns). Error handling lacks recovery guidance. Security concerns around AWS credential handling and permission gating are not addressed. The server attempts to be a multi-domain orchestrator (Claude instance management + AWS VM management + message queuing) but lacks cohesive design, tools feel like feature dumps rather than carefully composed interfaces. Average tool score across all 19 is ~38/100, placing this in the D (Poor) range.
Tools (19)
enhancedReadread onlysource verified62/100
Read messages from queue without losing them
enhancedSendwritesource verified62/100
Send a message with queuing and guaranteed delivery
executeParallelwritesource verified55/100
Execute parallel tasks for Manager instances. Enables Managers to run multiple Specialists concurrently.
listread onlysource verified57/100
List all active Claude instances. Enhanced with parallel execution awareness.
readread onlysource verified65/100
Read output from a Claude instance. Enhanced with circuit breaker protection.
restartwritesource verified62/100
Restart a dead instance using --continue flag.
sendwritesource verified62/100
Send text/prompt to a Claude instance. Enhanced with circuit breaker protection.
19 tools span 3 unrelated domains (Claude orchestration, AWS EC2, message queuing) with inconsistent naming and overlapping functionality. Tools like 'send' vs 'enhancedSend' and 'read' vs 'enhancedRead' create dangerous ambiguity for LLM tool selection.
Output schemas are completely missing for 18 of 19 tools. LLMs cannot plan downstream tool calls or know what fields to extract. This violates the 'documented return types' baseline (100% of A+ tools have them).
Split 'send' / 'enhancedSend' and 'read' / 'enhancedRead' into a single, well-defined tool per domain. Document the queue/circuit-breaker model clearly in descriptions.
Add output schemas for all 19 tools. Document the structure (fields, types, example values) that callers will receive. This is a hard requirement for A-grade tools.
Expand tool descriptions to 100-200 chars minimum. Include WHEN to use (vs similar tools), WHAT the tool does, WHAT it returns, and any prerequisites. Examples: 'spawn: Create a new Claude instance in a specific role (executive/manager/specialist) within a parent hierarchy. Use this to delegate tasks to specialized sub-agents. Returns instance_id and connection details. Requires workDir to exist.'
Add descriptions for every parameter. Use format 'Name (type, enum values if applicable): [purpose and constraints]'. Example: 'role (enum: executive|manager|specialist): Role determines parallelization capabilities. Managers can spawn and coordinate Specialists; Specialists cannot spawn children. Required.'
For vm_* tools, replace 'identifier' with separate 'vm_id' and 'vm_name' parameters, or document clearly which are accepted. Add guidance: 'Can pass either AWS instance ID (i-xxxxx) or friendly name (dev-instance-1). If ambiguous, instance ID takes precedence.'
Add pagination to list operations. Define limit (default 20, max 100) and cursor/offset. Return total count and next_cursor for large result sets. Example: list(limit=50, cursor=abc123) returns {instances: [...], total: 1523, next_cursor: def456}.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 2 points across a rubric change (v1 → v2)
48/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
F
48
<=2025-11-25
v2
2026-03-09
D
50
2024-11-05+
v1
writesource verified68/100
Create a new Claude instance with role and context. Enhanced with parallel execution awareness and workspace modes.
subscribewritesource verified62/100
Subscribe to messages matching a pattern
terminatedestructivesource verified63/100
Terminate a Claude instance and optionally its children. Enhanced to clean up parallel executors.
vm_bulk_createwriteauthsource verified65/100
Create multiple VM instances for parallel development
13 tools have descriptions under 60 characters (bare minimum). Examples: 'Stop a running VM instance' (26 chars), 'Restart a dead instance using --continue flag' (45 chars). Current descriptions omit all context and LLM selection cues.
Parameter descriptions are sparse or completely absent. Examples: 'context' in spawn is described as 'Context information for the instance' (22 chars, non-actionable). 'tasks' in executeParallel has no schema, callers must guess task format. Current baseline is ~20%.
No pagination support for list operations (list, vm_list, vm_bulk_create output). Large result sets will exhaust context windows and cause hallucination.
AWS credential handling not documented or restricted. vm_* tools require AWS credentials but no description of how credentials are injected (environment variables, vault, config file). No evidence of this in descriptions.
Ambiguous parameter names lack type suffix guidance. Examples: 'identifier' in vm_* tools should split into 'vm_id' vs 'vm_name'. 'role' in list should be 'instance_role'.
No error recovery guidance. Tools lack descriptions of expected errors and recovery steps. Example: spawn fails if workDir doesn't exist, no guidance on this. Try search_users() with a partial name.' Current implementation has no such guidance.
No tool composition guidance. Dependency chains are unclear: to use vm_ssh, must user first call vm_status or vm_list? Are IDs returned by vm_create reusable across tools?
No idempotency guarantees. Agents retry on failures, are spawn, vm_create, enhancedSend idempotent? Can calling spawn twice with the same params create two instances or return the same one?
spawnvm_createvm_bulk_createenhancedSend
For destructive operations (terminate, vm_terminate), implement multi-step confirmation. Example: First call returns {action_id, pending_confirmation: true, summary: 'Will terminate 5 instances'}. Second call requires {action_id, confirmed: true} to proceed. Document this flow in description.
Document AWS credential injection clearly in tool descriptions and main server documentation. Example: 'Requires AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY in environment or ~/.aws/credentials. Uses region from AWS_REGION env var (default us-east-1).'
Add error handling guidance to descriptions. For each tool, list common errors and recovery steps: 'If spawn fails with 'workDir not found', ensure the directory exists. If spawn fails with 'parent_id invalid', call list() first to verify parent instance ID.'
Document tool composition and chaining. Add a matrix showing: spawn returns instance_id → use instance_id with send/read/terminate. vm_create returns instance_id → use with vm_status/vm_ssh/vm_stop. executeParallel requires managerId from a Manager instance → spawn with role=manager first.
Clarify idempotency and retry semantics. Example: 'spawn is idempotent per role/workDir/context, calling twice with same params returns the same instance_id. send is non-idempotent (each call appends to queue). Agents should generate unique IDs for non-idempotent operations to detect duplicates.'
Add schema validation constraints in descriptions. Example: 'count (integer, 1-10): Number of VMs to create in parallel. Minimum 1, maximum 10 per API limits. Defaults to 1.'
For async operations (vm_create_image, vm_bulk_create), document polling mechanism: Does tool block until completion? Return a job_id for polling? Define timeout and retry logic.
Remove implementation details from descriptions. Examples: 'Restart a dead instance using --continue flag' should become 'Restart a terminated instance and restore its queued messages from backup. Use when an instance crashes but work should continue.' Hide the --continue flag.
Add permission/security scope documentation. Example: 'vm_create requires: aws:ec2:RunInstances, aws:ec2:CreateTags. Only users/agents with these scopes can invoke this tool.' This enables least-privilege agent design.