Tools have basic descriptions and parameter schemas, but lack depth and LLM-optimization. Descriptions are functional but generic (avg ~40 chars, below 194-char baseline). Parameter descriptions exist but are minimal. No output schemas documented. Error handling guidance absent. Tool names follow verb_noun convention (good), but descriptions don't explain WHEN to use each tool or dependencies between them. No enum constraints on string parameters like 'filter' and 'order'. Security-critical tools (faucet_delete, faucet_raw_sql) lack confirmation/dry-run patterns.

• Document output schemas for all tools. E.g., faucet_list_services should return {services: [{name: string, type: string, status: string}], total: number}. This enables LLMs to chain tools and extract required IDs.
• Expand descriptions to 100-200 chars. Add WHEN to use each tool and dependencies. E.g., 'Query a table with optional filtering and ordering. Call faucet_describe_table first to see available columns. Returns paginated results (default limit 100).'
• Add enum constraints to string parameters. E.g., 'order' should accept 'ASC|DESC' or specific column names. 'filter' should document SQL WHERE syntax or accept structured filter objects.
• Implement dry-run mode for faucet_delete and faucet_raw_sql. Add optional 'dry_run: boolean' parameter that returns affected row count without executing. Prevents accidental data loss.
• Add error handling guidance to descriptions. E.g., 'If service not found, call faucet_list_services to see available services. If table not found, call faucet_list_tables to verify table name.'

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained