Loading ToolBench
CLI-based system for orchestrating collaborative AI agents
This MCP server has significant definition quality gaps. While all 7 tools have descriptions and basic input schemas, the schemas are incomplete (missing explicit types for all parameters), descriptions lack LLM-optimized structure, and there is no documented output schema for any tool. The tool names follow verb_noun convention (init, run, help, send, models, list_agents, list_groups), which is positive, but parameter definitions are minimal. No error handling guidance, no parameter constraints (enums, ranges), no security considerations in descriptions, and no output structure documentation. This server reads as a thin CLI wrapper without agent-centric design.
Get detailed help about Dai Assistant and its features. Available help topics: - agents: Learn about agent roles and capabilities - config: Configuration file format and options - examples: See more usage examples - workflow: Understand the AI collaboration workflow
Initialize a new project with default agent configuration. This command creates a new project directory with: - Default agent configuration files - Project structure - Basic templates
List all available agents from the YAML config file.
List all groups and their member agents from the YAML config file.
List available models for LLM providers. This command shows all available models for either a specific provider or all providers if no provider is specified.
Run the multi-agent orchestration with specified configuration. Start the collaborative AI process with your defined team of agents. Agents will work together based on their roles and the project requirements.
NO OUTPUT SCHEMAS DOCUMENTED. Tools provide no schema for return values. LLMs cannot plan downstream tool composition or validate received data. For example, 'models' tool returns a list of model names, but the response structure is completely undocumented.
INPUT SCHEMAS LACK EXPLICIT TYPE DEFINITIONS. All parameters are defined as 'type: string' without proper JSON Schema structure. Example: 'provider' parameter in 'send' tool has no enum constraint (should be restricted to [openai, anthropic]), forcing the LLM to guess valid values.
PARAMETER DESCRIPTIONS ARE MINIMAL OR GENERIC. Parameters like 'provider' and 'model' in the 'send' tool have one-line descriptions that do not explain format, constraints, or valid values. No guidance on what 'message' should contain or how long it can be. Rubric baseline: 72 chars avg; these are 30-50 chars.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Send a message to the selected LLM provider. This command sends a message to the specified LLM provider and model. Currently, it only confirms receipt of the message.
NO ERROR HANDLING GUIDANCE. Descriptions do not explain what errors are possible, how to recover, or whether operations are retryable. For example, 'init' with a duplicate project name will fail, but the description provides no recovery hint like 'Use a unique project name or check existing projects first.'
NO PARAMETER CONSTRAINTS OR VALIDATION RULES STATED. The 'send' tool accepts 'provider' and 'model' with no validation. Description should explicitly state 'provider: must be one of [openai, anthropic]' and 'model: e.g., gpt-4, gpt-4-turbo, claude-3-5-sonnet'. Currently, LLMs must guess or hallucinate valid values.
INCOMPLETE TOOL COMPOSITION METADATA. 'run' tool accepts an agents_config file path, but there is no 'discover_agents' or 'validate_config' tool to help agents find valid configuration files first. This forces agents to guess file paths, risking failures.
'help' TOOL IS HARDCODED AND NOT EXTENSIBLE. Help topics are baked into src/cli/main.py. If agents call 'help agents', they receive a fixed string. There is no dynamic discovery of available topics or agents from the actual configuration. Not agent-friendly.
DESTRUCTIVE OPERATIONS NOT MARKED. 'init' creates a directory on disk (WRITE risk noted), but the description does not warn the LLM that this is irreversible or suggest a confirmation step. Pattern: destructive tools should support dry-run or explicit confirmation.
NO PAGINATION OR RESULT LIMITS. 'list_agents' and 'list_groups' return raw lists with no offset/limit parameters or documented max result count. If an agents config file contains 1000 agents, responses will be huge and blow context windows.
AMBIGUOUS 'send' TOOL SEMANTICS. Description says 'Currently, it only confirms receipt of the message.' This suggests the tool is incomplete. LLMs will be confused about whether this actually sends to the LLM provider or just echoes. Either complete the implementation or split into separate 'validate_message' + 'send_to_provider' tools.