Loading ToolBench
This a simple implementation of an MCP server using iFlytek. It enables calling iFlytek workflows through MCP tools.
The server exposes 2 tools with significant quality gaps. SYS_UPLOAD_FILE has a basic schema but minimal description (51 chars, below 10-char baseline). The dynamic_workflow_tools entry is inferred rather than directly registered, tool names, descriptions, and schemas come from iFlytek API at runtime, not from explicit MCP tool definitions in code. This violates the principle of verifiable tool definition and caps that tool at 50. Parameter descriptions are missing for file path in SYS_UPLOAD_FILE. No output schemas are documented. Error handling is absent, no recovery guidance, no actionable error messages. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server loads workflows from YAML but does not validate schema quality before registration.
upload file. Format support: image(jpg、png、bmp、jpeg), doc(pdf)
Dynamic tools loaded from iFlytek workflows defined in CONFIG_PATH. Each workflow becomes a callable tool with its own input schema retrieved from the iFlytek API.
Tool definitions are inferred from runtime API responses, not explicitly registered in code. dynamic_workflow_tools names, descriptions, and schemas come from iFlytek API responses at runtime, making them unverifiable from static analysis and breaking the contract that MCP tool definitions are discoverable before execution.
SYS_UPLOAD_FILE description is only 51 characters ('upload file. Format support: image(jpg、png、bmp、jpeg), doc(pdf)'), lacks actionable guidance. Does not state that file path must be absolute or relative. Does not state which file formats are valid or what the tool returns. Does not explain when to call this vs direct file parameter passing.
Parameter 'file' in SYS_UPLOAD_FILE has minimal description ('file path'). Does not specify: absolute vs relative paths, supported file extensions, max file size, error handling for missing files, or what 'file path' resolves to (server-side path? client-side path? URL?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No output schema documented for any tool. SYS_UPLOAD_FILE returns TextContent but the exact structure (success/failure indicator, file ID, URL, etc.) is not documented. Callers cannot plan downstream operations without knowing what fields to extract.
Error handling is absent. upload_file() and chat_message() can fail (network error, invalid file, API error) but no recovery guidance is provided. Errors are unstructured text wrapped in TextContent, the LLM cannot distinguish retryable errors from user-fixable ones.
No tool annotations. SYS_UPLOAD_FILE is destructive (creates/modifies files on server) but lacks destructiveHint annotation. dynamic_workflow_tools are read-only (chat/call workflows) but lack readOnlyHint. These hints guide agent behavior and safety analysis.
No pagination or result limiting. dynamic_workflow_tools can stream arbitrarily long responses. SYS_UPLOAD_FILE returns unstructured text. No mention of max response length, truncation strategy, or when results are capped.
API key is embedded in Flow object and passed as a parameter to internal methods. While not exposed as a tool parameter, this violates secret-injection pattern, if Flow objects are logged or persisted, credentials leak.