Loading ToolBench
A Model Context Protocol server that converts HTTP APIs into MCP tools. Loads tool definitions from a JSON configuration file and exposes them as callable MCP tools.
This server has one dynamic tool with minimal quality guardrails. The tool name 'dynamic_tools_from_config' does not follow verb_noun conventions and provides no actionable guidance to LLMs about what it actually does. The description is vague and meta, it explains that tools are loaded from a config file, but does not tell the LLM what the tool itself does or when to call it. The input schema is generic with placeholder '[dynamic_parameters]', making it impossible to validate that individual loaded tools have proper schemas. No parameter descriptions are provided for the dynamic parameters. The tool accepts arbitrary query parameters merged into axios config, creating a security risk and making it impossible for LLMs to reason about expected inputs. No documented output schema exists. Error handling converts axios errors into generic McpError messages without recovery guidance. The entire design assumes tools are defined externally in a JSON config file, but that config format is not documented in the server code provided, the tool definitions are invisible to this evaluator. Per the hard scoring rules: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Since tool schemas, descriptions, and names come from an external JSON file not shown, this tool's per-tool score is capped at 50, and the definition quality suffers accordingly.
Tools are dynamically loaded from a JSON configuration file specified via CONFIG_JSON_PATH environment variable. Each tool in the config becomes a callable MCP tool that makes HTTP requests via axios.
Tool name 'dynamic_tools_from_config' does not follow verb_noun convention. Should start with an action verb (get_, create_, call_, execute_) to signal intent to LLMs.
Input schema is generic and does not define actual parameters. The '[dynamic_parameters]' placeholder is not a real schema, it tells LLMs nothing about what inputs are expected, what types they are, what constraints apply, or what they control.
Tool descriptions are insufficient. The description is meta ('Tools are dynamically loaded from...') and does not answer: What does this tool do? When should I call it? What will it return? This fails to meet the 50-200 char optimized range and lacks WHAT, WHEN, WHAT-RETURNS context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 20 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
No parameter descriptions. Dynamic parameters lack any description explaining what each parameter controls, expected format, range, or constraints. This violates the requirement that every parameter must have a non-empty description.
Tool definitions are external to the server code (loaded from CONFIG_JSON_PATH environment variable). The actual tool names, schemas, descriptions, and parameters are not visible in the source provided, they are inferred to exist in a JSON config file. Per hard scoring rule: tool definitions that cannot be seen in source are capped at overall score 50.
No output schema documentation. The executeTool method returns a generic text response wrapping JSON.stringify(response.data) but does not document what fields or structure are expected in the response. LLMs cannot plan downstream calls or extract data without knowing the output shape.
Security risk: arbitrary query parameters. The tool merges any supplied args directly into axios params without validation or sanitization. This exposes the tool to injection attacks and allows the LLM to pass unvalidated input to external APIs.
Error messages lack recovery guidance. When an axios request fails, the error is converted to 'API 请求失败: {error.message}' (Chinese, partially untranslated) without telling the LLM what to do next. Per pattern:recovery-guide, errors should suggest next steps.
No pagination support. If external APIs return large result sets, the tool returns everything as a single JSON text response, risking context window exhaustion and degraded LLM reasoning.
Configuration file format not documented. The server accepts tools from CONFIG_JSON_PATH but does not provide a schema, example, or documentation of what the JSON structure must be. Users and evaluators cannot verify tool definitions.