Loading ToolBench
This server has significant definition quality gaps. All four tools are visible and registered via @mcp.tool() decorator, confirming they are explicitly defined (not inferred). However, schemas are incomplete, descriptions lack LLM-optimization detail, and parameter documentation is sparse. Tool naming is reasonable (verb-noun style: text_to_image, image_to_video, text_to_video, encode_image_to_base64), but descriptions are written in Chinese with minimal English support, limiting LLM usability in mixed-language environments. Input schemas ARE present with type declarations and defaults, but parameter descriptions are minimal (often just 'xxx说明' = 'xxx description'). Error handling is present but generic, responses use boolean 'success' flags without actionable recovery guidance. Output schemas are not formally documented; return values are inferred from code (dictionary structure). No parameter constraints (enums, length limits, regex patterns) are enforced beyond defaults. The server lacks pagination support, per-item error reporting for batch operations, and structured error messages with recovery hints.
将本地图片文件编码为base64字符串 Args: image_path: 图片文件路径 Returns: 包含base64编码字符串或错误信息的字典
图生视频功能 - 根据图片和文本描述生成视频 Args: prompt: 视频描述提示词 image_base64: 图片的base64编码字符串 duration: 视频时长（秒） ratio: 视频比例，如"16:9" model: 使用的模型名称 Returns: 包含视频URL或错误信息的字典
文生图功能 - 根据文本描述生成图片 Args: prompt: 图片描述提示词 size: 图片尺寸，格式为"宽x高"，如"1024x1024" model: 使用的模型名称 Returns: 包含图片URL或错误信息的字典
文生视频功能 - 根据文本描述生成视频 Args: prompt: 视频描述提示词 duration: 视频时长（秒） ratio: 视频比例，如"16:9" model: 使用的模型名称 Returns: 包含视频URL或错误信息的字典
Tool descriptions are in Chinese and lack LLM-optimized English structure. Baseline good description length is 194 chars; these are shorter and miss context about WHEN to use each tool and prerequisites (e.g., 'text_to_image' doesn't explain that it requires DOUBAO_API_KEY environment variable). Descriptions do not answer 'What does it do?', 'When to call this vs. similar tool?', 'What does it return?'
Parameter descriptions are minimal and generic ('图片描述提示词' = 'image description prompt'). Per the rubric, average param annotation length should be ~72 chars; most here are <20 chars. No guidance on format, constraints, or dependencies. For example, 'size' parameter has no examples of valid formats beyond the default '1024x1024', and 'model' parameter lists defaults but doesn't explain how to discover available models or what constraints apply.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No input validation or enum constraints. Parameters like 'size' and 'ratio' accept free-form strings without validation. The code does not check if 'size' matches 'WIDTHxHEIGHT' format or if 'ratio' is a valid aspect ratio. LLMs will hallucinate invalid values (e.g., '100x200x300' for size, or 'widescreen' for ratio). Per pattern:constrained-input, known-set parameters should be declared as enums.
Error responses lack recovery guidance. All tools return {'success': False, 'error': 'message'}, but errors do not tell the LLM what to do next. For example, 'API key is required' does not say 'Set DOUBAO_API_KEY environment variable' or 'Check if the key has expired'. Per pattern:recovery-guide, errors must guide the next step.
Output schemas are not formally documented. Return types are inferred from code (e.g., text_to_image returns {'success': bool, 'image_url': str or 'error': str}), but this is not declared in docstrings or schema. LLMs cannot plan downstream calls without knowing the response structure.
API key exposed in initialization logic. The server expects DOUBAO_API_KEY as an environment variable (correct), but the initialize_client() function is called inside each tool and could raise ValueError exceptions. If the key is missing, the error message will surface it to the LLM context. Per pattern:secret-injection, credentials should never appear in error responses or tool parameters.
Long-running operations (text_to_video, image_to_video) use polling with 60 * 5 second = 300 second timeout. No explicit timeout error or progress reporting. If the task fails after 100 iterations, the LLM sees a generic 'Video generation timed out' message without context on why or how to retry. Per pattern:progress, long operations should report progress or offer a way to check status later.
No parameter validation for image_base64 input in image_to_video. The tool accepts any string as image_base64 and constructs a data URL. If the string is not valid base64, the API call will fail, but the tool does not validate before sending. Per review:param-validation-rules, validation should happen early with clear error messages.
Missing composition pattern: encode_image_to_base64 is a utility tool that produces output (base64 string) that image_to_video consumes (image_base64 parameter). However, the description does not hint at this relationship. Per pattern:tool-chain, related tools should be discoverable from descriptions.