Loading ToolBench
MCP service aggregator and hub providing centralized management of multiple MCP servers, tool access control, group-based tool filtering, and API-to-MCP tool conversion
MCP Knot exposes 18 tools with significant quality gaps. Most tools lack proper descriptions (many under 20 chars or in Chinese), parameter descriptions are sparse or missing, and input schemas are incomplete or inferred. Tools like 'getGroupTools', 'configureGroupTools', and 'executeTool' have descriptions in Chinese that don't meet the 10-1024 character English baseline. Parameter types are present but descriptions are minimal. No output schemas are documented. Error handling guidance is absent. The server appears to be an internal API wrapper rather than a production-grade MCP server. Tool naming follows verb_noun convention but lacks clarity on when to use similar tools (e.g., getGroupTools vs getGroupAvailableTools).
配置组工具过滤（POST /:groupId/tools）- 设置组的工具白名单，支持工具可用性验证和配置持久化
执行API工具 - 调用API转MCP服务执行工具，返回统一的ToolResult格式
执行工具 - 验证组访问权限、工具访问权限、路由工具执行、验证参数、执行工具并处理结果
获取API工具定义
获取API生成的工具列表 - 从API转MCP服务获取转换后的工具
获取组可用工具（GET /:groupId/available-tools）- 返回组内所有可用工具，支持工具过滤和按服务器分组
获取组的工具列表（GET /:groupId/tools）- 返回组内所有可用工具及其按服务器分组的信息
获取服务健康状态
获取API工具统计信息 - 返回API工具总数和初始化状态
Descriptions are in Chinese and extremely brief (10-25 chars). LLMs cannot determine when to select tools or what they do. Examples: 'getApiTools' → '获取API生成的工具列表', 'reloadConfig' → '重新加载API工具配置'. Descriptions must be in English, 50-200 chars, and explain WHAT, WHEN, and WHY.
Parameter descriptions are missing or minimal. 'groupId' has only 'Group ID' (8 chars); 'args' has only 'Tool call parameters' (20 chars). LLMs cannot infer parameter meaning from names alone. Every parameter needs a description explaining format, constraints, and examples.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
获取组的工具列表 - 从MCP服务器和API工具服务获取工具，支持缓存
检查工具是否为API工具
执行健康检查
重新加载API工具配置
重启API工具集成服务
关闭API工具集成服务
将MCP server返回的各种结果格式统一转换为ToolResult - 处理标准MCP结果、错误结果、对象、原始类型等
校验单个参数的类型是否符合schema声明 - 支持string、number、integer、boolean、array、object等类型
根据工具的inputSchema校验参数 - 验证参数类型、必填性、额外属性等
No output schemas documented. Tools return results but LLMs cannot plan downstream calls or extract fields. Example: 'executeTool' returns a ToolResult but the structure is not documented. Every tool must document its return type and fields.
Similar tool names lack disambiguation. 'getGroupTools' vs 'getGroupAvailableTools' vs 'getToolsForGroup', unclear which to call when. Tool descriptions must explain the distinction and when to use each variant.
No error handling guidance. Tools like 'executeTool' and 'configureGroupTools' can fail but provide no recovery hints. Error responses must tell LLMs what to do next (retry, ask user, or abort). Example: 'Tool not found. Call getGroupAvailableTools() to see available tools.'