Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Critical blockers prevent meaningful evaluation. All 20 tools are defined only in test files (crates/mcp/tests/tool_router_shape.rs), not in the actual MCP server implementation code. This means tool definitions are inferred from test shape assertions rather than explicit runtime registration. Per the rubric, inferred tools are capped at 50. Additionally, no input schemas are visible in the provided source code, only tool names and brief descriptions. Parameter types, constraints, and output schemas are completely absent from the visible codebase. The descriptions are extremely minimal (12-48 characters), leaving LLMs unable to determine when or why to select these tools. No error handling, validation, or recovery guidance is documented. The server is alpha software (v0.5.0-alpha.5) with a sprawling workspace structure (11 internal crates) but zero evidence of production-grade tool definition practices.
No input schemas visible for any tool. All 20 tools lack documented parameter types, constraints, and descriptions. LLMs cannot infer what inputs each tool accepts.
Tool definitions are inferred from test files, not explicitly registered in the MCP server runtime. Per scoring rules, inferred tools are capped at 50 overall.
1. Migrate tool definitions from test files to explicit runtime registration in the MCP server code (likely in crates/mcp/src/server.rs or similar). Use the rmcp crate's tool registry with full JSON Schema definitions.
2. Expand ALL tool descriptions from current 12 - 48 chars to 80 - 200 chars. Follow the pattern: 'Action: [what the tool does]. When: [when to call it]. Returns: [what you get back, including any IDs needed for chaining]. Example: [a realistic use case].' Example: 'Read observations from the live feed. Use this after initializing a session to see new observations in real-time. Returns a paginated list of observation records with timestamps and lens filters applied. Requires an active observation session initialized via daemon8_init().'
3. Document every parameter with explicit type, description, constraints, and examples. For daemon8_connect, explicitly state: 'server_address (string, required): The hostname or IP of the daemon8 observation server (format: hostname:port, e.g. localhost:8080). timeout_seconds (integer, optional, default 30): Connection timeout in seconds (range 1 - 300). verify_ssl (boolean, optional, default true): Whether to verify SSL certificates if using HTTPS.'
All tool descriptions are under 50 characters (range 12 - 48 chars), far below the 50 - 200 char baseline for LLM-optimized descriptions. Examples: 'Connect to a daemon8 observation server' (39 chars), 'Get daemon8 status and current observations' (43 chars). These are too terse to guide tool selection.
No parameter descriptions documented anywhere. LLMs cannot understand what daemon8_connect's parameters mean, what constraints they have, or how they relate to other parameters.
No error handling or recovery guidance. If daemon8_connect fails, the LLM has no instruction on what to try next or why it failed (timeout, invalid credentials, service unavailable?).
Tool names like 'daemon8_init', 'daemon8_status', 'daemon8_connect' are prefixed with a product name rather than action verbs. 'initialize_observation_session', 'get_session_status', 'establish_observation_connection' would be clearer for LLM intent parsing.
Generic parameter names like 'type', 'filter', 'options', 'data', 'config' appear likely but are not documented. Without field-level descriptions, LLMs cannot construct valid payloads.
5. Add pagination parameters to list_* tools (list_connections, list_debug_sessions). Include: 'limit (integer, optional, default 20, range 1 - 100): Maximum results per page. offset (integer, optional, default 0): Result offset for pagination. Return a response containing total count, current page, and next_offset/has_more flag.'
6. Implement structured error responses for all tools. When daemon8_connect fails, return: '{ "error": "connection_failed", "message": "Failed to connect to server at localhost:8080. Check that the server is running and the address is correct.", "recovery": "Verify the server URL with daemon8_status or check network connectivity. If the server is behind a firewall, ensure the port is accessible.", "retryable": true }' instead of a raw exception.
7. Rename tools to lead with action verbs, not the product name. Examples: 'daemon8_connect' → 'establish_observation_connection', 'daemon8_init' → 'initialize_observation_session', 'daemon8_status' → 'get_session_status', 'daemon8_help' → 'describe_available_tools'.
8. Add idempotent hints (tool annotations) to read-only tools and destructive hints to write tools. Mark 'read_live_feed', 'lens_status', 'list_connections' with readOnlyHint=true. Mark 'end_debug_session', 'clear_lens' with destructiveHint=true.
9. Define parameter relationships explicitly. If 'set_lens' depends on an active observation session, state in the description: 'Requires: active observation session. Call daemon8_init() or check status with get_session_status() before calling this tool.'
10. Provide response examples in the documentation or README. For 'read_live_feed', show a sample response with observation records, timestamps, and lens filter output so LLMs can anticipate the structure.