MCP tool aggregator — offload MCP tools to a CLI daemon. Agents call tools through shell commands and scripts instead of loading schemas into context.
Muxed is a STDIO-only MCP proxy/aggregator that exposes 7 tools for discovering and invoking tools across remote MCP servers. Tool definitions are present and partially documented, but exhibit significant quality gaps: (1) Most tool descriptions are bare operational statements lacking guidance on when/why to use them; (2) Critical tools like 'call' expose partial schemas, the 'call' tool accepts a 'name' parameter but does NOT document the dynamic arguments that follow, forcing LLMs to guess at invocation patterns; (3) Parameter descriptions are minimal or absent in several tools (e.g., 'depth' in 'grep' and 'tools' lacks explanation of its algorithm or token-budget behavior); (4) No output schemas are documented, leaving LLMs unable to plan downstream composition; (5) Error handling is present but generic, no recovery guidance (e.g., if a tool call fails, should the agent retry 'call', or re-run 'grep' to find alternatives?). The tool set itself follows single-responsibility design (one verb per tool), and tool names are reasonably clear (servers, tools, grep, info, call, resources, read), but the definitions lack the depth required for confident autonomous invocation.
Execute a tool on a connected MCP server
Search for tools by pattern across all servers
Get detailed information about a server or tool including its input schema
Read a resource from a connected MCP server
List available resources from servers
List connected MCP servers and their status
List available tools across all servers, optionally filtered by server name
Critical: 'call' tool schema is severely incomplete. The tool accepts a 'name' parameter (server/tool format) but does NOT document or expose the dynamic input parameters that the target tool requires. LLMs cannot introspect what arguments to pass after selecting 'call', they must first run 'info' to fetch the schema, then construct the arguments from scratch. This two-phase pattern is error-prone and violates tool-chaining principles.
High: No output schemas documented for any tool. The 'tools' tool returns 'Array<{server: string, tool: Tool}>' (visible in code) but this is NOT exposed in the tool's definition for LLMs. The 'call' tool's output structure is not documented, does it return {content, isError}? Can the LLM rely on that? Without documented return types, LLMs cannot plan composition or error handling.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
High: Parameter descriptions are minimal or misleading. The 'depth' parameter in 'tools' and 'grep' is described as 'Collapse schemas deeper than N levels' but does NOT explain the token-budget auto-selection mentioned in the CLI help text ('Depth is auto-selected to fit a token budget if omitted'). The 'include' parameter says 'Include extra fields: "schema" adds input schemas' but does not clarify what other values are accepted or what fields are returned.
High: Missing guidance on tool selection and dependencies. Descriptions do not explain when to use 'grep' vs 'tools', when to call 'info' before 'call', or what the 'path' parameter in 'info' is for (JSON path extraction? Not documented). LLMs lack explicit dependency hints and will make redundant calls.
Medium: Error responses are not documented. The code shows 'ToolResult' with 'isError' flag and text content, but the tool definitions do not document error cases or recovery guidance. If 'call' fails (tool not found, server offline, etc.), what should the LLM do? Retry? Call 'grep' to verify the tool exists? No guidance provided.
Medium: The 'servers' tool has no input parameters documented (input schema is missing or empty), yet its description mentions no parameters. However, if 'servers' is truly READ_ONLY discovery, this is acceptable, but the definition should clarify whether it takes optional filters (e.g., by status, by name).
Medium: No confirmation or dry-run pattern for the 'call' tool. Destructive operations (e.g., calling 'delete_user' on a remote server) are invoked directly with no confirmation step. While muxed itself is a proxy, it should support optional confirmation for high-risk tool calls.