Loading ToolBench
A secure on-demand gateway for long-tail MCP servers with lazy calls and declarative Method Mode.
MetaMCP defines 3 tools with clear action-verb naming (mcp_discover, mcp_call, mcp_run). All tools have descriptions and input schemas present in src/index.ts. Schemas are well-formed with typed properties and descriptions. However, output schemas are not documented in the visible code, and parameter descriptions vary in quality and completeness. The tools are a meta-gateway pattern (routing to child servers), which is architecturally sound, but descriptions could be more explicit about failure modes and LLM guidance.
Call one explicitly named child tool. The target starts lazily. Calls are never replayed implicitly after a timeout or transport failure.
Search configured servers, cached child tool schemas, and declarative Methods without starting every child. Set refresh=true with a specific server to refresh only that server.
Execute a named child tool with optional timeout, auto-retry backoff, and streaming progress updates via notifications. The target starts lazily.
Output schemas not documented. While input schemas are well-defined with types and descriptions, the tools do not expose what fields LLMs can expect in responses (e.g., what does mcp_discover return? What structure does mcp_call's result have?). Per pattern:tool and pattern:response-shaper, LLMs need documented output schemas to plan downstream tool calls and extract data correctly.
Error handling guidance is minimal. Descriptions state 'Calls are never replayed implicitly after a timeout or transport failure' (mcp_call) but do not explain what errors the LLM should expect or how to recover. Per pattern:recovery-guide, error responses should tell the LLM what to do next (retry? try a different server? ask the user?). Currently, an LLM encountering a failure has no guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2025-06-18+ | v2 |
Parameter 'query' in mcp_discover lacks constraint guidance. It is a free-form string, but the description does not explain what kind of queries are valid (e.g., 'fuzzy match capability names?', 'regex search?', 'exact match only?'). Per pattern:constrained-input, free-form parameters should include examples or format constraints in the description.
mcp_discover 'refresh' parameter behavior is non-obvious. The description says 'refresh=true with a specific server to refresh only that server' but does not clarify: what happens if refresh=true without a server? Is refresh stateful (does it update a cache)? What is the performance cost? Per pattern:tool-description, descriptions should be explicit about side effects and prerequisites.
mcp_run 'retries' and 'timeout' parameters lack usage examples and bounds. No description of valid ranges (is retries 0-10? 0-100? unlimited?). Is timeout in milliseconds only, or can it be seconds? Per pattern:tool-description and review:param-validation-rules, parameter constraints must be explicit.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Per current MCP spec (2026-07-28), tools should declare their semantics. mcp_discover is read-only; mcp_call and mcp_run may be destructive depending on the child tool. Annotating these enables smarter agent behavior (e.g., agents know they can safely retry mcp_discover but must ask before retrying destructive operations).