Loading ToolBench
Open-source RAG router for MCP — sits in front of all your MCP servers and exposes only the relevant tools per query, killing context overload.
rag-mcp-router exposes 5 tools with clear, action-oriented names (search_tools, call_tool, get_result, list_servers, get_metrics). All tools have descriptions (avg ~120 chars, within baseline 34 - 392). Input schemas are present and typed. However, parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or dependencies. Output schemas are undocumented. Error handling is minimal; no recovery guidance. The router's core value (semantic tool selection) is well-articulated, but tool definitions lack the depth needed for reliable LLM reasoning in production.
Invoke a tool previously returned by search_tools. Pass the tool's server, name, and arguments exactly as described by its input schema.
Return live per-request accounting for the current session: tokens saved, surfaced tools, per-tool call counts, baseline vs actual.
Fetch the remainder of a large result that call_tool deferred. Pass the resultId from the deferred result, plus an offset (and optional limit) to page through the rest. Nothing is lost — the full payload is held server-side.
Show every configured downstream server, its connection status (connected/disconnected), how many tools it exposes, and the last error if any.
Describe in natural language what you want to do. Returns only the downstream tools relevant to that intent (with their input schemas), so you don't have to load every tool into context.
Parameter descriptions missing or incomplete. 'intent' in search_tools lacks format guidance (free-form string? max length?). 'k' lacks range constraints (1 - 100? 1 - 1000?). 'offset' and 'limit' in get_result lack defaults or bounds. LLMs cannot infer valid ranges without explicit constraints.
Output schemas undocumented. search_tools returns 'downstream tools relevant to that intent (with their input schemas)' but the exact response structure is not specified. Clients cannot parse results reliably without a formal schema. call_tool defers large results but the deferred result structure is not documented.
Error handling absent. No guidance on what errors search_tools or call_tool may return, or how to recover. If a downstream server is unreachable, does call_tool fail? Can the agent retry? Should it call list_servers first? No recovery path documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
call_tool 'arguments' parameter is a bare object with no schema. LLMs cannot validate which keys are required or what types they should be. The description says 'Arguments object for the tool' but does not specify structure, required fields, or type constraints.
Composition risk: call_tool requires 'server', 'name', and 'arguments' to be passed exactly as search_tools returns them. If search_tools omits a required field or returns a different format, call_tool will fail silently. No validation or chaining guidance documented.