MCP server for kenoma multi-agent swarms. Enables inter-agent communication via shared SQLite database with message passing, reactions, contracts, and agent lifecycle management.
kbus server has 12 tools with complete input schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (kbus_send, kbus_spawn, kbus_terminate), which is good. However, descriptions are terse (avg ~60 chars, well below the 194-char baseline for A+ tools) and lack context about when to use each tool or what happens on failure. Parameters have types and descriptions, but many descriptions are minimal (e.g., 'Timeout in milliseconds' for kbus_wait). No output schemas are documented anywhere in the source. Error handling is absent, no guidance on retryability, recovery steps, or what errors mean. The contract-related tools (kbus_contract_bid, kbus_contract_award, etc.) form a coherent subsystem but lack inter-tool chaining documentation (e.g., does kbus_contract_award return a contract_id that kbus_contract_report needs?). Security: no evidence of permission gates, audit logging, or rate limiting despite tools like kbus_terminate and kbus_spawn being destructive. Overall, this reads like a functional but under-documented internal tool suite.
List all registered agents and their status
Report a contract breach
Announce a new contract for bidding
Award a contract to a bidding agent
Submit a bid on a contract announcement
Report completion or status of a contract
Revoke a contract
Add an emoji reaction to a message
No output schemas documented. Tools return data but LLMs cannot plan downstream calls or extract required fields. E.g., does kbus_agents return agent_id, status, role? Does kbus_spawn return a new agent_id for chaining to kbus_send?
Descriptions are terse (avg ~50 chars vs 194-char baseline). Lack context on when to use each tool, what happens on error, or prerequisites. E.g., 'Block until a message arrives' does not explain timeout behavior, what happens if no message arrives, or whether this is idempotent.
No error handling guidance. Destructive tools (kbus_terminate, kbus_spawn, kbus_contract_revoke) lack confirmation steps, dry-run modes, or recovery instructions. An LLM could accidentally terminate all agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Send a message to another agent or broadcast to all agents
Spawn a new agent with specified role, goal, and constraints
Terminate another agent with optional reason and mode (soft/hard)
Block until a message arrives for this agent, with optional timeout
Contract tools lack inter-tool chaining documentation. Does kbus_contract_award return a contract_id that kbus_contract_report accepts? Are commitment_id and contract_id the same? Ambiguity forces LLM guessing.
No permission gates or audit logging visible. Tools like kbus_terminate and kbus_spawn are destructive but lack access control checks or logging. No evidence of rate limiting to prevent runaway agent loops.