Dynamically routes user queries to Pareto-optimal LLMs based on intent, latency, and cost optimization
Single tool 'route_query' has a well-structured input schema with 4 parameters, each with type and description. However, the tool definition in mcp_server.py (tools/list response) is MISSING the input schema entirely, only name and description are returned. Per HARD SCORING RULE, this caps schema at 0. The tool description (67 chars) is adequate but generic. No output schema is documented. The client.py implementation shows sophisticated routing logic, but the MCP interface does not expose it properly. Tool is READ_ONLY (safe), but no error handling guidance is provided for edge cases (e.g., no models match constraints, invalid intent detection).
Dynamically routes user query to the Pareto-optimal LLM based on intent, latency, and cost.
Tool schema not exposed in MCP tools/list response. mcp_server.py returns only name and description; input schema with 4 parameters (prompt, max_latency_ms, cost_weight, allowed_models) is defined in client.py but never registered with the MCP server. Per HARD SCORING RULE, schema score must be 0.
Output schema not documented. route_query returns a dict with detected_intent, selected_model, composite_rank, estimated_latency_ms, and pareto_candidates array, but this structure is never declared in the MCP response. LLMs cannot plan downstream calls without knowing the response shape.
No error handling or recovery guidance. If all models are filtered out (e.g., max_latency_ms=100), the tool falls back silently to gemini-1.5-flash. No error message tells the LLM why the constraint was violated or what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Tool parameters not validated. cost_weight accepts 0.0-1.0 per description, but no runtime validation enforces this range. LLMs may pass 2.5 or -0.5, causing silent scoring errors.
tools/call handler ignores all parameters. mcp_server.py calls client.route_query() with no arguments, always using defaults. The LLM's parameter values are discarded, making the tool non-functional for custom queries.