All 12 tools suffer from severely underdeveloped schemas and descriptions. Every tool uses a generic command/params pattern with no enum values, parameter types, or constraints visible in the schema. Descriptions are boilerplate and fail to distinguish tools or guide LLM selection. No output schemas documented. The surf_sql tool creates server-side state but lacks confirmation/dry-run patterns. Tools are named generically (surf_*) without action verbs. Parameter descriptions are absent from the input schema itself.

• Replace generic {command: enum, params: object} schema with explicit per-command schemas. For each command, define required/optional parameters with types, descriptions, and constraints (e.g., enum values, min/max, regex patterns).
• Rewrite tool descriptions to be LLM-optimized (50-200 chars). Include: what the tool does, when to use it vs. similar tools, what it returns, and any prerequisites. Example: 'Get real-time market price for a token by symbol or contract address. Returns price, 24h change, volume. Use this before analyzing token trends.'
• Rename tools with action verbs: surf_market → get_market_data or search_market_prices; surf_sql → execute_sql_query or create_sql_job. Make the intent clear from the name alone.
• Document output schemas for each command. Include field names, types, and descriptions. Ensure responses include IDs/references needed for chaining (e.g., if a market search returns token_id, downstream tools should accept token_id).
• For surf_sql, add a dry_run parameter (boolean, default false) to preview results without committing. Document that sql-job-create is non-idempotent and requires confirmation. Provide error recovery guidance (e.g., 'Query timeout, try reducing date range or adding LIMIT clause').