Loading ToolBench
A set of block-based LLM agent node libraries designed for ComfyUI. Allows users to quickly and conveniently build their own LLM workflows and easily integrate them into their existing SD workflows.
This MCP server has severe definition quality issues across all four tools. Tool names lack action verbs (data_base_advance, use_api_tool), descriptions are minimal or generic, and critically, input schemas are incomplete or missing proper type definitions. The server appears to be a ComfyUI node wrapper rather than a proper MCP implementation. Parameter types are inconsistent (some listed as 'string' when they should be integers), descriptions are sparse and sometimes in Chinese, and there is no evidence of output schemas, error handling guidance, or recovery paths. Tool registration appears to happen dynamically through a custom NODE_CLASS_MAPPINGS pattern rather than standard MCP tool registration.
查询用户上传的文件中与用户提问相关的信息。
用于查询任意时区当前是星期几
通过关键词获得GitHub上的仓库信息。
Generic API tool for making HTTP requests with configurable parameters
Tool names lack action verbs. 'data_base_advance', 'use_api_tool', and 'get_weekday' are non-standard. 'data_base_advance' should be 'query_knowledge_base' or 'search_documents'. 'use_api_tool' is dangerously generic and violates single-responsibility principle.
Parameter type definitions are inconsistent and wrong. In data_base_advance, 'k' (paragraph count) is typed as 'string' but should be 'integer'. In search_github_repositories, 'paper_num' (page number) is 'string' but should be 'integer'. This forces LLMs to pass numbers as strings, causing type mismatches.
Missing or incomplete descriptions on parameters. 'use_api_tool' accepts only an 'id' parameter with description 'API ID identifier', this is circular and tells an LLM nothing about what API it connects to, what it returns, or when to use it. No enum of valid API IDs is provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Tool descriptions are too short and lack context. 'get_weekday': 'Generic API tool for making HTTP requests with configurable parameters' (11 chars) does not explain what it does, when to use it, or what it returns. 'search_github_repositories' description is 74 chars but does not specify sort order, result format, or pagination.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract data when they do not know what fields to expect. Each tool needs documented return types (e.g., 'returns {documents: [{source, content, index}]}').
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. If knowledge base query returns no results, should the LLM retry with different keywords or inform the user? No guidance is given.
Descriptions are in Chinese for some tools (data_base_advance, get_weekday, search_github_repositories) while others are in English (use_api_tool). This mixes language contexts and will confuse multilingual LLMs. Standardize to English or provide parallel translations.
use_api_tool combines multiple responsibilities: it is both a generic HTTP client and an API multiplexer. A single tool that can make requests to any API is a security and usability red flag. Split into specific tools (query_github_api, query_openai_api, etc.) or document allowed APIs, rate limits, and timeout behavior.
Parameter constraints are not documented. For search_github_repositories, what is the valid range for 'paper_num'? For data_base_advance, what is the range for 'k'? Without bounds, LLMs will pass invalid values (k=999999, page_num=-1).
No pagination documented. search_github_repositories accepts 'paper_num' but the output schema is unknown, does it return total count? next_cursor? Clients cannot implement intelligent pagination without knowing result structure.