Hermes-native AI software delivery team runtime with profile-driven agent orchestration, Kanban task management, and mission-scoped collaboration
Team Nexus exposes 23 tools via Makefile targets with minimal schema documentation. Most tools lack visible input schemas in the source code, only 6 tools (analyze_portfolio, kanban_create, discord_post_status, mcp_add_command, mcp_add_url, mcp_register_template) have explicit parameter definitions. The remaining 17 tools have empty or inferred schemas. Descriptions are present but generic (avg ~80 chars, well below the 194-char baseline for A+ tools). No output schemas documented. No error handling guidance. Tool names follow verb_noun convention (kanban_list, profile_validate) but lack clarity on mutual exclusivity and dependencies. Security concerns: no mention of secret injection, permission gates, or audit trails. Composition is poor, many tools are Makefile wrappers around shell commands, not true MCP tool implementations with structured I/O.
Analyzes a portfolio JSON file to compute performance metrics, unrealized P&L, sector exposure, peer comparisons, and investment theme opportunities with suggestions for rebalancing, stop losses, profit taking, and concentration risk
Validate profile-driven Docker Compose function services
Post compact Team Nexus status updates to Discord webhooks with optional thread routing
Run hermes doctor for one rendered profile to check runtime health
Create a mission-scoped Kanban task with title, assignee, conversation ID, and body
Initialize the shared Team Nexus Kanban board and mission contract triggers
Link parent->child dependency between Kanban tasks
17 of 23 tools have no visible input schema in source code. Only analyze_portfolio, kanban_create, discord_post_status, and mcp_* tools expose parameter definitions. Remaining tools (kanban_init, kanban_list, kanban_stats, kanban_watch, profile_validate, profile_permissions_check, workspace_init, compose_config, etc.) have empty or inferred schemas, violating the 'every tool must have a documented input schema' rule.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data. Kanban tools should return task IDs, statuses, and timestamps; profile tools should return validation results and file paths; MCP tools should return server configs. Without documented outputs, agents must guess what fields are available.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
List shared Kanban tasks
Audit existing Kanban tasks for missing mission markers
Install DB triggers rejecting Kanban tasks without mission markers
Remove DB mission-contract triggers
Print a valid deterministic Kanban mission task payload
Show shared Kanban task counts
Watch shared Kanban board events
Register an MCP server via command invocation
Register an MCP server via HTTP URL
List MCP servers registered for a profile
Load and register a shared MCP registry definition template
Fail if active profile runtime dirs/files are not writable by the host operator
Repair active profile runtime ownership/modes from inside the container
Render Docker profile files into ignored runtime/hermes/profiles directory
Validate profile-driven Team Nexus spec and manifests
Initialize shared workspace/artifact and ignored runtime directories
Descriptions are generic and under 50 chars for 14 tools (kanban_init, kanban_list, kanban_stats, kanban_watch, profile_validate, profile_permissions_check, profile_permissions_repair, workspace_init, compose_config, etc.). Baseline for A+ tools is 194 chars. Short descriptions lack context for LLM tool selection and do not explain WHEN to use each tool or what it returns.
No error handling guidance. Tools like kanban_mission_contract_uninstall (DESTRUCTIVE risk) and profile_permissions_repair (WRITE risk) lack recovery instructions. If a tool fails, the LLM has no actionable next step. No confirmation/dry-run pattern for irreversible operations.
No security controls visible. No mention of secret injection, permission gates, audit trails, or input sanitization. discord_post_status accepts a 'payload_json' parameter, if an LLM is tricked into injecting malicious JSON, there is no validation. Kanban and profile tools modify state without permission checks.