Loading ToolBench
An MCP interface for the Merge API that provides dynamic tools for interacting with multiple business systems through unified API endpoints
This server exposes a single dynamically-generated tool ('dynamic_tools_from_merge_api') that is a meta-wrapper rather than a true tool. The actual tools are generated at runtime from an OpenAPI schema, making static analysis impossible. The wrapper tool has NO meaningful schema, it declares an empty properties object with a dynamic description. This violates fundamental MCP principles: tools must be statically discoverable with complete schemas, descriptions, and parameter definitions. The server generates tools at initialization, but the source code shows no evidence of how those dynamically-created tools are named, described, or schematized. The single visible 'tool' is not a real tool, it's a placeholder that shifts all responsibility to runtime discovery, which defeats the purpose of the MCP tools interface. An LLM cannot reason about or select from tools it has not been explicitly told about.
Tools are dynamically generated from the Merge API OpenAPI schema. Each operation in the schema becomes an MCP tool with parameters extracted from path, query, and request body schemas. Operations are filtered by enabled scopes (read/write permissions) and requested scopes.
Tool schema is completely empty. Declared as {"type":"object","properties":{},"description":"..."}. No parameters are documented, no types are specified, no validation constraints exist.
Tool is a meta-wrapper, not a discoverable tool. The server registers a single tool named 'dynamic_tools_from_merge_api' that does nothing itself. Actual tools are generated dynamically at runtime from the OpenAPI schema. LLMs receive NO information about what tools are available, their names, parameters, or descriptions until after initialization. This breaks static tool discovery, a core MCP principle. Clients like ChatGPT cannot work with tools that are not listed upfront.
Tool name 'dynamic_tools_from_merge_api' does not follow verb_noun convention. It reads as a noun phrase rather than an action. Correct form would be something like 'call_merge_api' or 'invoke_merge_operation', but since the tool is a meta-wrapper, the naming is inherently broken.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Description states 'Tools are dynamically generated...' This is a meta-description about the architecture, not a description of what the tool does. This description fails on all counts, it describes the implementation, not the interface.
No output schema documented. The tool's response structure is unknown, clients cannot plan downstream actions or extract the right data.
Tool composition is broken. The server does not expose individual, discoverable tools. Instead, it forces clients to call a generic wrapper and hope the generated tools inside match what they need. This violates pattern:tool-chain and pattern:tool, each tool should be independently discoverable and callable with explicit schemas.
No error handling guidance. If a dynamically-generated tool fails, the error is opaque to the LLM. No recovery guidance, no categorization (retryable vs user-fixable vs fatal), no suggested alternatives. Per pattern:recovery-guide, errors must tell the LLM what to do next.