Compress all connected MCP servers into a single router MCP to save tokens
This is a meta-router tool that proxies to other MCP servers. The 8 tools include 2 operational meta-tools (get_tool_schema, invoke_tool), 5 QA mock tools for testing (echo, add, multi_block, failing_tool, documented_tool), and 1 HTTP server test tool (whoami). The meta-tools have schemas and descriptions, but the QA/test tools are undocumented mock implementations. Input schemas ARE visible for all tools, but several lack descriptions or have minimal descriptions. The router's core purpose (compress multiple MCP servers) is functional but the tool definitions prioritize internal testing over LLM optimization. Descriptions are present but generic ('Returns...'); no parameter descriptions exist for any tool. Output schemas are not documented. Error handling is minimal.
Adds two numbers together.
A tool with a deliberately long description for testing description passthrough.
Returns the input message with an "echo: " prefix.
Returns an error result with a specific message.
Get the JSON schema for one or more tools from a connected MCP server, or omit the tool names to list a server's tools and their arguments. You MUST call this for a tool before you can invoke it with invoke_tool.
Invoke a tool on a connected MCP server with the given arguments.
Returns multiple content blocks of different types.
Most tools lack parameter descriptions. Every parameter needs a description explaining what it controls; LLMs cannot infer meaning from names alone.
No output/return schemas documented. Tools return results but no schema describes the structure of responses, LLMs cannot plan downstream calls or extract the right data.
QA/test tools (echo, add, multi_block, failing_tool) have minimal, generic descriptions. Descriptions under 50 characters provide insufficient context for LLM tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Reports whether the request carried a valid bearer token.
Tool names lack clarity on intent. 'multi_block', 'failing_tool', 'documented_tool' are vague, they do not clearly signal the action or when to use them. Baseline: 90% of production tools start with an action verb.
Error handling is not documented. No guidance on retryability, user-fixable vs fatal errors, or recovery paths for agents.