Loading ToolBench
A local MCP router that aggregates multiple MCPs into a single interface for Claude
Super-MCP Router demonstrates solid tool design with complete schemas, clear descriptions, and thoughtful parameter constraints. All 6 tools have explicit input schemas with typed properties and descriptions. Tool names follow verb_noun convention (list_, search_, get_, use_, record_). Descriptions range 80 - 200 chars, meeting the 10 - 1024 baseline. Security annotations are well-integrated. However, output schemas are not documented in the source, parameter descriptions could be more prescriptive about constraints and error recovery, and error handling lacks actionable recovery guidance. The use_tool handler shows sophisticated continuation logic but no dry-run validation details. Overall, this is a well-engineered router that would benefit from explicit output schema documentation and richer error messages.
Get detailed information about specific tools including schemas, notes, and security annotations
List all available tool packages with their metadata, health status, and configuration
List tools available in a specific package with optional pagination and detail levels
Record or remove untrusted advisory notes for tools to help with tool selection and usage
Search for tools across all packages using BM25 full-text search with relevance scoring
Execute a tool from a package with arguments, supporting result continuation for large outputs
Output schemas not documented. Tool descriptions state what is returned (e.g., 'List all available tool packages') but do not specify the structure of the response object, field types, or pagination metadata. LLMs cannot plan downstream tool calls without knowing what fields to extract.
Error handling lacks actionable recovery guidance. The source shows validation (e.g., 'tool_ids must be a non-empty array') but does not document what the LLM should do next: retry, call a discovery tool, or ask the user. Bare error codes do not guide agent behavior.
use_tool dry_run parameter lacks validation details. Description says 'Validate arguments without executing' but does not explain what validation is performed, what errors are returned, or how the LLM should interpret a successful dry-run.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
record_tool_note parameter descriptions are terse. 'The note text to record (required unless remove is true)' does not explain the purpose of notes, length limits, or what constitutes a valid advisory. The TOOL_NOTE_NOTICE constant exists in code but is not surfaced in the parameter description.
Pagination parameters (page_token, page_size) lack explicit constraints. list_tools accepts page_size with default 20 but does not document min/max bounds. Unbounded numeric parameters let LLMs pass absurd values.