Loading ToolBench
A comprehensive LLMOps platform with built-in and custom API tools for workflow automation, featuring tool management, API integration, and workflow execution capabilities
This server has critical definition gaps. Tool descriptions are present but minimal (10-30 chars), falling well below the 50-200 char LLM-optimized baseline. Input schemas are visible and properly typed, but parameter descriptions are sparse or missing context. No output schemas documented. Error handling is absent, no recovery guidance, no categorization of errors, no actionable messages. Tool names follow verb_noun convention (good), but descriptions lack WHEN/WHY context. The server exposes Chinese-language descriptions without English equivalents, limiting LLM usability. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE). Overall, this reads as an internal API wrapper with minimal LLM-facing polish.
创建自定义API工具
根据传递的provider_id删除对应的工具提供者信息
根据传递的provider_id+tool_name获取工具的详情信息
根据传递的provider_id获取工具提供者的原始信息
获取API工具提供者列表信息，该接口支持分页
获取LLMOps所有内置工具信息+提供商信息
获取所有内置提供商的分类信息
Descriptions are minimal (10-30 chars) and in Chinese only. LLM-optimized descriptions should be 50-200 chars in English, explaining WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'get_api_tool_providers_with_page' has only '获取API工具提供者列表信息，该接口支持分页' (Chinese, ~25 chars). LLMs cannot reason about tool selection without clear English context.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields without knowing what each tool returns. For example, 'create_api_tool_provider' likely returns a provider_id, but this is not documented. Agents cannot chain tools without explicit response schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
根据传递的提供商获取icon图标流信息
根据传递的提供商名字+工具名字获取指定工具的信息
更新自定义API工具提供者信息
校验传递的openapi_schema字符串是否正确
No tool annotations despite clear risk levels. Tools marked DESTRUCTIVE (delete_api_tool_provider) and WRITE (create_api_tool_provider, update_api_tool_provider) lack readOnlyHint, destructiveHint, or idempotentHint annotations. LLMs cannot distinguish safe reads from irreversible operations without these hints.
No error handling guidance. Tools provide no recovery hints, error categorization, or actionable messages. If 'create_api_tool_provider' fails due to invalid OpenAPI schema, the LLM receives no guidance on whether to retry, ask the user, or call 'validate_openapi_schema' first.
Parameter descriptions lack context and constraints. For example, 'openapi_schema' is described as 'OpenAPI规范的JSON字符串' (Chinese, no format guidance). LLMs need English descriptions stating format (JSON string), constraints (valid OpenAPI 3.0+), and examples of what makes it valid or invalid.