Loading ToolBench
A chat application server with LangChain integration supporting knowledge bases, search engines, agents, and dynamic tool management
This server exhibits significant quality gaps across naming, descriptions, parameter documentation, and output schemas. Of 8 tools examined, 5 have Chinese-only descriptions with minimal English support, 3 tools lack clear action verbs in naming, and most parameters lack proper type constraints and validation guidance. The tool interface prioritizes backend API exposure over agent-friendly design. Tool composition violates single-responsibility principle (chat_router handles 5 different chat types). No documented output schemas, error recovery guidance, or security boundary enforcement visible.
Get list of all built-in tools with their configuration templates and metadata
Main chat router that handles different chat types (LLM chat, knowledge base chat, search engine chat, agent chat, workflow chat)
Get available child tools for a given parent tool by name
创建工具
删除工具
获取工具详情
分页查询工具列表
Chinese-only descriptions. 5 of 8 tools (child_tools, create_tool, update_tool, delete_tool, chat_router) have descriptions exclusively in Chinese ('获取子工具', '创建工具', '删除工具', etc.) without English translations. LLMs trained primarily on English cannot reliably parse or act on Chinese descriptions, causing tool selection failures and invalid invocations.
Chat_router violates single-responsibility principle. Tool name 'chat_router' does not start with an action verb; description is a generic catch-all: 'Main chat router that handles different chat types (LLM chat, knowledge base chat, search engine chat, agent chat, workflow chat)'. This tool combines at least 5 distinct operations in one interface, forcing the LLM to reason about internal 'chat_type' enums rather than calling specialized tools. Should be split into 5 separate tools: query_llm, query_knowledge_base, search_external, invoke_agent, execute_workflow.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
更新工具
Parameter descriptions in Chinese only. Tools create_tool, update_tool, delete_tool, and chat_router expose parameters with descriptions like '工具中文名称', '工具id', '对话类型', etc., all in Chinese. English-centric LLMs cannot reliably interpret these constraints. Example: chat_router's 'chat_type' parameter has no English description of valid enum values or when each type is appropriate.
Missing or incomplete output schemas. None of the 8 tools document their response structure. Built_in_tools, create_tool, update_tool, delete_tool, get_tools, and get_tool_detail return BaseResponse objects, but the schema of BaseResponse and the 'data' field contents are not visible in the provided code. LLMs cannot infer what fields to expect or extract (e.g., does create_tool return just tool_id or a full tool object?). Per pattern tool, all tools must document output schemas.
Missing enumeration constraints. chat_router accepts 'chat_type' as a string with no enum definition provided. Valid values are stated only in the docstring ('LLM chat, knowledge base chat, search engine chat, agent chat, workflow chat'), not as a machine-readable constraint. This invites hallucination; the LLM may pass 'chat_type': 'gpt_chat' or 'ai_chat' instead of the correct values. Should use JSON Schema enum or allOf with const values.
No error handling guidance. The code shows basic try-catch blocks (e.g., in create_tool, update_tool, delete_tool) that return BaseResponse(code=500, msg=...). These error responses provide no actionable recovery guidance. Per pattern recovery-guide, errors must tell the LLM what to do next. Example: if delete_tool fails with 'Tool in use', the error should suggest 'Check which workflows reference this tool using get_tool_detail().'
Dangerous default behavior in create_tool, update_tool, delete_tool. The 'state' parameter defaults to '0BT' (enabled) with no explanation of what '0BT' and '0BF' mean in descriptions. If an LLM omits 'state', the tool activates by default, which could enable a dangerous or misconfigured tool unintentionally. Defaults must not cause unexpected side effects. The parameter description should clarify: 'state: "0BT" enables tool, "0BF" disables; omitting defaults to enabled.'
Ambiguous parameter naming in child_tools. The tool accepts a single parameter 'tool_name_en' (tool English name), but the description is '工具名称' (tool name in Chinese). It is unclear whether this is a system ID, human-readable name, or localized identifier. Should be 'tool_name_en_identifier' with a clear description: 'The English identifier of the parent tool (e.g., "web_search", "calculator").'
No pagination limit enforcement in get_tools. The tool accepts a 'size' parameter with a hardcoded cap of min(abs(size), 1000). The description says 'The pagination size' but does not state the maximum (1000). Per pattern paginated-result, large results can exhaust context windows. Should document: 'Returns up to 1000 results per page. To retrieve large datasets, iterate through pages using the page parameter.'
Missing parameter type hints in function_properties (create_tool, update_tool). These tools accept a 'function_properties' parameter described as 'The parameter definition' but offer no validation that the object conforms to JSON Schema. An LLM could pass arbitrary or malformed property definitions. Should validate against a schema and return a clear error: 'function_properties must be valid JSON Schema with type, description, and required fields.'