Loading ToolBench
The server exposes a single tool 'dynamic_superface_tools' that is fundamentally incoherent from an MCP design perspective. The tool definition is inferred rather than explicitly registered with schema details, and it violates core separation-of-concerns principles by attempting to dynamically proxy all Superface API tools through a single MCP tool. The tool has no input schema visible in the source code, only a generic description stating that 'Tool names and signatures are determined at runtime.' This creates multiple critical failures: (1) the input schema is missing entirely, triggering a hard score of 0 for schema; (2) the description is vague and does not explain WHAT the tool does, WHEN to use it, or what it returns, it only describes an implementation detail; (3) there is no way for an LLM to know what parameters to pass or what the output structure will be, making the tool essentially non-functional for agent planning; (4) parameter validation and error handling are completely absent, the tool accepts arbitrary arguments and passes them opaquely to the Superface API.
Dynamic tools provided by Superface API. Tool names and signatures are determined at runtime by calling superface.getTools() and passed through to superface.runTool()
Missing input schema entirely. Tool accepts arbitrary arguments with no structure, types, or constraints. LLM cannot infer valid parameters.
Tool description is implementation-focused, not LLM-focused. Describes that 'names and signatures are determined at runtime' (8 words, internal detail) rather than explaining: What does the tool do? When should it be called? What does it return? No actionable guidance.
Tool name 'dynamic_superface_tools' is generic and does not start with an action verb. Does not convey what calling this tool DOES. Naming violates verb_noun convention (e.g., 'call_superface_api' or 'run_superface_tool' would be clearer, though still problematic).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 21 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 9 | - | v1 |
Design violates single-responsibility principle. Tool attempts to dynamically proxy an entire external API (Superface) through a single MCP tool. Instead of registering discrete tools (e.g., 'list_superface_tools', 'call_http_api', 'invoke_workflow'), the server tries to make one opaque proxy tool do everything. This is a composition anti-pattern: the LLM cannot plan because it does not know what tools are available until runtime.
No input validation or error handling visible. Tool accepts arguments from LLM, passes them directly to superface.runTool(), and returns JSON result. If Superface API returns an error, LLM receives raw error response with no recovery guidance (e.g., 'Authentication failed' with no hint to check SUPERFACE_API_KEY).
Output schema is not documented. Server returns JSON from Superface API opaquely as text. LLM cannot know what fields to expect or how to extract relevant data for downstream decisions.
Tool definition is inferred from runtime behavior (calling superface.getTools()). No explicit tool registration with schema is visible in source. Combined with missing schema, actual score is 8.