Loading ToolBench
A collection of AI-powered tools and agents including travel assistant, design change detection, and voice/image processing
This server has critical gaps in tool definition quality. Both tools have descriptions present but they are minimal and do not adequately explain intent, prerequisites, or usage context. Schemas are present but parameter descriptions are vague or missing critical constraints. The server lacks documentation of output structure, error handling guidance, and idempotency information. Tool names are adequate (verb_noun format) but lack the depth expected for production systems. No parameter validation constraints are visible. The codebase shows the tools are not fully implemented MCP tools but rather example scripts using OpenAI API directly (simple_test/) and custom LLM calls (agent_travel/), suggesting the 'MCP server' is in early proof-of-concept stage rather than production-ready.
Comprehensive analysis of user message for design changes with JSON-structured output including answer, reason, summary, suggestions, and rule violations
Analyze user message to determine if design change is needed
Retrieve analysis results for a message including design generation status and results
Get attraction recommendations based on city and weather conditions
Retrieve message history for a session
Get weather of a location, the user should supply a location first.
Generate image from existing image using Flux I2I workflow, supporting local files, base64, and URLs
Tool descriptions are too brief and lack LLM guidance. 'Get weather of a location, the user should supply a location first' (64 chars) does not explain WHAT the tool returns, WHEN to use it over alternatives, or prerequisite steps. According to rubric, descriptions should be 10-1024 chars and written as prompt-engineering instructions.
Parameter descriptions are missing or minimal. 'location' is described as 'The city and state, e.g. San Francisco, CA' which includes an example value (violates rubric: examples tempt LLMs to reuse them literally). No format constraints, length limits, or examples of invalid inputs documented.
No output schema documented. LLMs cannot plan downstream calls or know what fields to expect. For get_weather, is the output a string like '24℃', an object with {temp, condition, humidity}, or a structured weather object? This forces LLMs to guess or fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Send a message to the chat API and receive a response
Send a voice message for transcription and processing
Generate image from text prompt using Flux T2I workflow
Convert audio file to text using Whisper large-v3 model
No error handling documentation. What happens if the location is invalid, the service is down, or the city is ambiguous? No recovery guidance provided to the LLM.
Parameter schema for get_attraction lacks descriptions. 'city' and 'weather' parameters have minimal descriptions ('The city name', 'Current weather condition'). No constraint on what constitutes valid weather input (e.g., is 'sunny', 'Sunny', 'SUNNY' all accepted? Required enum?).
No idempotency guarantees documented. If an agent retries get_weather or get_attraction due to ambiguous failure, will it return the same result or potentially different data? State idempotency clearly.
Tools are not visible as complete MCP tool definitions. The code shows OpenAI tool schema (simple_test/tool_calls.py) and custom dictionary registration (agent_travel/available_tools.py), but no clear MCP server implementation file.