Loading ToolBench
A Spring Boot-based MCP server that acts as a distributed tool gateway, registering and managing remote tools from multiple MCP servers and exposing them through a centralized MCP interface
The server exposes a single tool 'dynamic_remote_tools' which is poorly defined. The tool name violates naming conventions (no action verb, plural noun form, ambiguous intent). The description is vague and does not explain WHAT the tool does, WHEN to use it, or WHAT it returns. Most critically, NO input schema is visible in the provided source code, the tool accepts arbitrary 'arguments' but does not declare parameter names, types, descriptions, or constraints. The output schema is also undocumented. The tool's behavior (dynamically invoking remote tools) requires the agent to know tool names and parameter structures that are never declared. This violates the core pattern of self-documenting tools and makes the tool unusable without external documentation.
Dynamically registered remote tools from distributed MCP servers. Tools are registered via ToolRegistrationService and stored in ToolRegistry with callback URLs for invocation
Tool name 'dynamic_remote_tools' lacks action verb and is ambiguous. Does it list tools? Call tools? Register tools? Register them where? The name should be verb-first (e.g., 'invoke_remote_tool', 'call_registered_tool', or 'list_available_remote_tools') to clarify intent. Current name violates verb_noun convention.
NO input schema is visible or declared for 'dynamic_remote_tools'. The code shows 'buildJsonSchema(tool)' constructing schemas from RemoteToolEntity objects, but the gateway tool itself has NO parameters defined. An agent calling this tool has no way to know what parameters to pass or what they mean.
Tool description 'Dynamically registered remote tools from distributed MCP servers. Tools are registered via ToolRegistrationService and stored in ToolRegistry with callback URLs for invocation' is implementation-focused, not user-focused. It does NOT explain: (1) What does calling this tool DO? (2) When should an LLM call it instead of calling the specific remote tools directly? (3) What does it RETURN? The description is 188 chars but fails to answer the 'What/When/Return' pattern. Description score capped at 20.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Output schema is undocumented. The code returns 'new McpSchema.CallToolResult(List.of(new McpSchema.TextContent(result)), false)', a plain text string. The agent does not know what fields to expect, whether the result is JSON, plain text, or error, or how to parse the response.
No error handling or recovery guidance. If 'forwardToRemote()' fails (network error, invalid tool name, missing callback URL), the agent gets a raw exception or unclear result. No actionable error message tells the LLM whether to retry, which tool to call next, or what went wrong.
Tool composition is broken. The gateway is supposed to dynamically register remote tools. But the single exposed tool 'dynamic_remote_tools' does not clearly specify HOW to invoke those tools. The agent must somehow know the names of registered tools, their parameters, and their signatures, none of which are documented in the tool definition itself. This violates the principle that tool output should contain IDs/references the next tool needs (pattern:tool-chain).
The 'arguments' parameter is not typed or constrained. The code accepts 'Map<String, Object> arguments' with no validation, enum constraints, or format specification.