Loading ToolBench
Qwen-Omni Model Context Protocol Server for multimodal interactions with text, image, audio, and video support
This server has significant quality gaps across naming, descriptions, parameter validation, and error handling. While tool names are reasonably clear (multimodal_chat, analyze_image, analyze_audio, analyze_video, text_to_speech), the descriptions are inconsistent in quality and many parameters lack proper type definitions or validation constraints. Most critically, parameter schemas are incomplete, many lack explicit type declarations in the JSON schema visible in the source. The 'messages' parameter in multimodal_chat, for example, lacks a schema definition for the nested Message structure. Error handling is minimal: most tools return generic error strings rather than actionable recovery guidance. Composition is reasonable (each tool has a single primary purpose), but the implementation lacks the sophistication expected of production-grade agent tools. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared, and no output schemas are formally documented.
分析音频内容。 Args: audio_url: 音频URL或本地文件路径 prompt: 分析提示 voice: 是否输出语音以及音色选择（可选） Returns: 音频分析结果
分析图像内容。 Args: image_url: 图像URL或本地文件路径 prompt: 分析提示 voice: 是否输出语音以及音色选择（可选） Returns: 图像分析结果
分析视频内容（支持音视频）。 Args: video_url: 视频URL或本地文件路径 prompt: 分析提示 voice: 是否输出语音以及音色选择（可选） Returns: 视频分析结果
多模态对话，支持文本、图像、音频、视频输入，可输出文本和语音。 Args: messages: 对话消息列表，每个消息包含 role 和 content modalities: 输出模态列表，可选值：["text", "audio"] voice: 语音音色，默认 "Cherry" enable_thinking: 是否启用思考模式（思考模式下不支持音频输出） model: 使用的模型，默认 "qwen3-omni-flash" Returns: 对话回复内容
文本转语音。 Args: text: 要转换为语音的文本 voice: 音色选择，默认 "Cherry" Returns: 转换结果
Input parameter schemas lack proper type definitions. The 'messages' parameter in multimodal_chat is declared as array but the nested Message structure (role, content fields) has no schema definition visible. analyze_image, analyze_audio, analyze_video pass complex content structures but do not document their schemas.
Missing or trivial parameter descriptions for key inputs. The 'voice' parameter across all tools is described simply as 'voice color' or 'voice' without documenting: (a) what voice options are valid, (b) whether it's an enum or free-form string, (c) default behavior if omitted, (d) any constraints or dependencies with other parameters like enable_thinking.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No output schema documentation. None of the tools formally document their return structure. multimodal_chat returns a string with optional audio file path appended as plain text (example: 'response text\n\n🔊 audio file path'). This unstructured format forces the LLM to parse text output, violating the structured-output pattern.
Error handling is minimal and non-actionable. Tools return generic 'Error: {str(e)}' messages. The LLM receives no guidance on whether errors are retryable, user-fixable, or fatal. For example, if the Qwen API is temporarily unavailable, the agent has no way to know it should retry; if the image URL is invalid, the agent cannot self-correct without a hint like 'Invalid URL format, provide a publicly accessible image or local file path.'
Missing tool annotations. No tool declares readOnlyHint, destructiveHint, or idempotentHint. This is especially important for multimodal_chat which has risk=WRITE, agents should be warned that repeated calls with the same input may produce different outputs (non-idempotent), making retry-on-failure risky.
Vague or missing enum constraints. The 'modalities' parameter in multimodal_chat documents allowed values as '["text", "audio"]' in the description but the schema does not enforce an enum constraint, inviting hallucinated values. Similarly, 'model' parameter lists 'qwen3-omni-flash' as a default but does not declare all valid model options.
The 'content' field in multimodal_chat messages is under-specified. The implementation accepts complex nested structures (image_url objects, input_audio objects, text objects) but the schema shown in the evaluation metadata does not reflect this complexity. The LLM cannot know what content structures are valid without explicit documentation.
The 'enable_thinking' parameter description states 'thinking mode down not support audio output' (apparent typo) but does not explain what thinking mode does, when an agent should enable it, or what the performance/latency tradeoff is. The LLM cannot reason about parameter selection without clear semantic documentation.
Unspecified behavior for image/audio/video URL resolution. The analyze_* tools accept 'image_url or local file path' but do not document: (a) what file path format is expected (relative? absolute? URIs?), (b) what file types are supported, (c) max file size, (d) timeout for remote URL fetches. This forces the LLM to guess or fail silently.