Loading ToolBench
Give Claude Code superpowers — parallel multi-model queries, smart routing, and image/video generation across OpenAI (GPT-6, GPT-5.6, o-series, GPT Image 2), Gemini (Nano Banana, Veo), DeepSeek, Kimi, Grok, and 12+ providers
Server defines 11 tools with schemas and descriptions present, but quality is inconsistent. Tool names follow verb_noun convention (ask_all, ask_model, generate_image, list_models, delegate, web_search, get_conversation_history, clear_conversation, get_server_status). Descriptions are present but brief (avg ~80 chars, below the 194-char baseline). Parameter descriptions exist but lack detail on constraints, formats, and valid ranges. No output schemas documented. Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions. Security concern: conversation_id and model parameters accept free-form strings with no validation. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions (clear_conversation is destructive). Schemas use proper JSON types but lack enums, patterns, and min/max constraints.
Query all available chat models in parallel and return aggregated responses
Query both fast and reasoning models in parallel, returning aggregated responses
Query a specific model by key with optional conversation history
Clear conversation history for a given conversation ID
Route a query to a specific category's delegated model based on routing configuration
Generate images using specified image generation model
Generate videos using specified video generation model
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., model_id, conversation_id) from responses.
Parameter descriptions lack constraint details. 'max_tokens' and 'temperature' have no min/max bounds; 'model' parameter accepts free-form strings with no enum of valid model keys; 'size' and 'quality' for image generation lack valid option lists.
No tool annotations (readOnlyHint/destructiveHint). clear_conversation is destructive but unmarked; ask_* tools are read-only but unmarked. LLMs cannot distinguish safe from risky operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Retrieve conversation history for a given conversation ID and model
Get current server status including loaded models, budget usage, and configuration
List all available models with their capabilities and pricing information
Perform web search using configured search provider
Error handling is implicit. No visible error recovery guidance in tool definitions. If a model key is invalid or API call fails, LLMs have no guidance on what to do next (retry, call list_models, ask user).
Conversation management lacks idempotency guarantees. conversation_id is user-provided with no validation; no documentation on what happens if the same conversation_id is reused across different models or if history is corrupted.