This server acts as a transparent proxy to a remote Kairos Signal HTTP endpoint. Both tools (tools/list, tools/call) have minimal, generic descriptions that fail to guide LLM selection. The tools/call input schema is present but lacks parameter descriptions, 'name' and 'arguments' are bare strings with no guidance on valid values, format, or constraints. No output schema is documented. The server does not validate inputs, provide error recovery guidance, or explain when to use each tool. Descriptions are under 50 characters, well below the 194-char baseline for production tools. No pagination, no result limits, no chaining IDs documented. This is a thin bridge with no value-add for agent reasoning.

• Add detailed parameter descriptions to tools/call: 'name' should explain valid tool names (e.g., 'The name of a Kairos Signal tool to invoke. Call tools/list first to discover available tools.'), and 'arguments' should describe the expected object structure and required fields.
• Document the output schema for both tools. For tools/list, describe the structure of the returned tool catalog (e.g., array of {name, description, inputSchema}). For tools/call, describe what the remote tool returns.
• Expand tool descriptions to 100 - 200 characters. Explain the purpose, when to call each tool, and any prerequisites. E.g., 'Fetch the live catalog of Kairos Signal tools (DePIN, network telemetry). Call this first to discover available tools before invoking tools/call.'
• Add error handling that translates remote JSON-RPC errors into actionable guidance. E.g., if tools/call fails with 'unknown tool', return 'Tool not found. Call tools/list to see available tools.' If it fails with 'invalid arguments', return the schema of the expected arguments.
• Document pagination and result limits. If tools/list returns a large catalog, cap results and offer pagination. If tools/call can return large responses, document limits and chunking behavior.