OkoNebo exposes 13 read-only weather tools via STDIO. Tool names follow verb_noun convention (get_*), which is good. Descriptions are present but generic (10 - 50 chars), below the 50 - 200 char baseline for LLM-optimized docs. Only 2 tools (get_tides, get_pws_trend) have parameters with type/description; the rest accept no inputs. No output schemas are documented. Error handling is absent, tools return raw API responses without recovery guidance. The server includes content-safety scanning and source attribution (ai_safety + data split), which is a security plus, but this does not compensate for schema and description gaps.

• Add explicit input schemas to all 11 no-parameter tools. Even if a tool takes no inputs, declare 'Input: {}' with a description explaining why (e.g., 'No parameters required; returns current conditions for the configured station.').
• Expand descriptions to 80 - 150 characters. Include WHAT the tool does, WHEN to use it, and a hint at the output. E.g., 'Get current temperature, humidity, wind speed, and conditions from the configured weather station. Use this for real-time updates; call get_forecast for multi-day predictions.'
• Document output schemas for each tool. Use a structured format like 'Returns: {temp_c: number, humidity_percent: number, wind_kmh: number, condition: string}' in the description or a separate schema field.
• Add error handling with recovery hints. Wrap _get() calls in try-except; return structured errors like {'error': 'service_unavailable', 'message': 'OkoNebo API timeout', 'retry_after_seconds': 30} instead of raw exceptions.
• Migrate from STDIO to HTTP+SSE or Streamable HTTP transport. STDIO blocks remote access and hosted MCP clients. Use FastAPI's existing /api/* endpoints to expose MCP over HTTP, enabling broader integration.