Loading ToolBench
AI Development Orchestration Platform with multi-agent swarm coordination, ML/RL optimizations, real-time dashboard, and specialized skill system. Provides gateway server for WebSocket communication, FastAPI dashboard backend, TUI command center, and extensible skill runner.
This MCP server exhibits critical definition quality deficiencies. None of the 6 tools have visible input schemas in the source code provided. While 4 tools have descriptions, they are generic and lack the specificity LLMs need for proper tool selection. The 'message' and 'command' tools show partial schema information in the metadata, but these are not formal JSON Schema definitions. The server appears to be a custom gateway/orchestration system rather than a standard MCP tool server, making tool registration and schema visibility unclear. Tool names follow basic verb_noun patterns but descriptions lack context about when to use each tool, what it returns, and how it chains with other tools.
Handle CLI commands starting with / - supports /status, /swarm-status, /preview, /context commands for system monitoring and task orchestration
Handle client connection - creates session for client and establishes WebSocket connection
Handle client disconnection - closes session and cleans up message queue
Handle status request - returns health status of gateway components including sessions, message router, and component health
Handle list sessions request - returns all active sessions with metadata
Handle incoming message - validates message type and content size, routes message through message router
No formal JSON Schema definitions visible for any tool. Input schemas are either missing or not present in the provided source. This violates the critical requirement that all tools must have documented input schemas for LLM tool selection.
Descriptions are generic and lack specificity. 'Handle client connection' and 'Handle incoming message' do not explain WHEN to use these tools, WHAT they return, or HOW they chain with other tools. LLMs cannot distinguish between similar tools or plan multi-step sequences with such vague descriptions.
'connect' and 'disconnect' are session-management tools that should clarify whether they are meant for MCP clients to invoke, or internal gateway operations. If they are MCP-callable tools, their descriptions must explain what 'session' means in the context of this gateway, and what data structures are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
The 'message' tool accepts generic 'content' of type 'any', which is ambiguous. What formats are valid? What happens if content is invalid? What does the tool return? Without concrete examples and constraints, LLMs will pass arbitrary payloads and error handling will be opaque.
The 'command' tool lists example commands (/status, /swarm-status, /preview, /context) in its description, but does not expose these as an enum constraint. LLMs may hallucinate unsupported commands like /logs, /debug, or /info, causing errors with no guidance for recovery.
No output schemas are documented for any tool. LLMs cannot know what fields to expect from connect, get_status, or list_sessions, making it impossible to plan downstream tool calls or extract required data for follow-up operations.
No error handling guidance. None of the tool descriptions explain what errors can occur, how to recover, or whether operations are retryable. For example, what happens if connect() fails? Can the LLM retry, or is the session permanently broken?