Loading ToolBench
The simplest way to create Model Context Protocol (MCP) servers in JSON or JavaScript.
The server exposes a single tool 'get_language_list' with significant definition quality gaps. The tool name lacks clarity on what 'language list' means in context, and the description is vague about its actual purpose and return value. Parameters are defined with type annotations via Zod schema, but descriptions are minimal (10-20 chars each) and do not follow best practices for parameter documentation. No output schema is documented for the tool's return value. The implementation shows HTTP client integration (axios), but the tool definition lacks the structured clarity needed for reliable LLM interaction. This is a data retrieval tool but does not follow production-grade patterns for discovery, pagination, or result documentation.
获取语料平台支持的语言列表
Tool name 'get_language_list' is ambiguous, does not clarify what 'language' means (supported languages? language codes? language configurations?). The name should be more specific to the use case.
Tool description '获取语料平台支持的语言列表' (approximately 'Get supported language list of corpus platform') is too generic. Does not explain WHEN to use this tool, WHAT data it returns, or any prerequisites. Baseline for A+ tools is 50-200 characters with clear intent statements.
Parameter descriptions are minimal: 'project' → '项目名称' (project name), 'language' → '语言' (language), 'env' → '环境' (environment), 'customize' → '定制客户的名称' (customer name). Each is only 2-4 words with no guidance on format, valid values, or constraints. Baseline is 10-1024 characters with actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No output schema documented. The tool returns a response with 'content' array containing 'text' field with JSON-stringified data, but this structure is not declared in the tool definition. LLMs cannot plan downstream interactions without knowing what fields and structure to expect.
No error handling documentation. Tool makes HTTP requests that could fail (network, 404, 500, timeout) but provides no guidance on error messages, recovery steps, or retry logic. Baseline pattern requires error responses to tell the LLM what to do next.
No pagination support. If the language list is large, the tool returns everything at once, potentially blowing the context window. Baseline pattern requires limit/offset and total count for list-returning tools.
Hardcoded URL with placeholder '${project}/${env}/${language}/${customize || 'default'}' suggests this is a template-based integration, but the tool does not validate inputs against the API requirements. No regex patterns, enums, or constraints declared.
Tool name does not follow verb_noun convention clearly. 'get_language_list' reads as 'get' + 'language_list', but 'language_list' is vague. Consider 'get_supported_languages', 'get_corpus_languages', or 'list_available_locales' to be more specific.