mcp-uni exposes 3 core tools with basic schemas and descriptions. Tool names follow verb_noun convention (connect_mcp, disconnect_mcp, list_mcp), which is good. However, descriptions are minimal (10-30 chars), parameter descriptions are sparse or missing, and output schemas are not documented. The connect_mcp tool has a complex oneOf schema for transportConfig, but lacks guidance on when to use SSE vs stdio. Error handling is minimal, no recovery guidance or actionable error messages.
Connect a MCP server to the host
Disconnect a MCP server from the host
List all MCP servers
Tool descriptions are under 20 characters and lack context. 'Connect a MCP server to the host' (30 chars) does not explain WHEN to use this tool, what prerequisites exist, or what happens on success/failure.
No parameter descriptions for transportConfig sub-fields. The oneOf schema defines 'type', 'url', 'query', 'headers' (for SSE) and 'type', 'command', 'args', 'env', 'cwd' (for stdio), but LLMs cannot infer when to use each variant or what each field means. Missing descriptions violate pattern:tool-description.
Output schemas are not documented. All three tools return text content, but the response structure is not formally specified. LLMs cannot plan downstream calls or extract structured data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. If connect_mcp fails (e.g., invalid transport config, unreachable server), the error is logged but not returned with actionable guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next.
Dynamic tool registration from connected clients is inferred, not explicitly visible in schema definitions. Tools from mcpHost.getClients() are registered at runtime (server.ts:48-60), but their schemas are derived from tool.inputSchema without explicit validation or documentation.