lighter-mcp has 19 tools with mixed quality. Tool schemas are explicitly defined in schema/index.ts with Zod validation, which is good for structure. However, descriptions are inconsistent, some tools have solid descriptions (e.g., 'Create and execute a market order on the Lighter protocol...'), while others are minimal (e.g., 'Say hello', 'Hello World'). Critical issues: (1) Private key parameters are exposed as tool parameters in 10+ tools (create_market_order, create_limit_order, close_position, cancel_order, add_tp_sl_orders, withdraw, get_positions, fetch_balance, fetch_referral_points), violating secret-injection pattern. (2) Tool naming uses underscores but some descriptions lack clarity on when to use them vs similar tools (e.g., fetch_balance vs get_positions both retrieve user data). (3) Error handling and output schemas are not documented in the tool definitions themselves, we see Zod input schemas but no output schema documentation. (4) Some tools combine multiple responsibilities (e.g., system_setup is vague; getUserAddresses + chooseWallet should clarify their relationship). (5) Three non-functional demo tools (hello_world, hello://world, hello) dilute signal and suggest incomplete cleanup. Baselines: avg tool description ~150 chars (median ~80 for the portfolio), within acceptable range, but several edge cases fall below 20 chars ('Say hello', 'Hello World'). Tool composition is reasonable for a trading protocol, tools are mostly single-responsibility, but secret exposure is a critical flaw that would block production deployment.

• CRITICAL: Move private key handling to server-side secret injection. Accept an account_id or wallet_selector parameter instead of private_key. Store keys in environment or vault and retrieve server-side. Remove private_key from all tool parameter schemas.
• Document output schemas for all trading tools. Create a schema section (e.g., 'Returns: {transaction_id: string, status: string, timestamp: ISO8601, ...}') in each tool description or in a separate output schema definition.
• Remove or retrofit the three demo tools (hello_world, hello://world, hello). If kept for testing, mark them as internal/hidden. Otherwise, delete and rely on Lighter protocol tools only.
• Expand system_setup description to 50-150 chars explaining what configuration it performs (e.g., 'Initialize the Lighter MCP server with blockchain network and wallet settings') and any prerequisites.
• Add per-tool error handling documentation. For irreversible operations (create_*_order, close_position, withdraw), document potential errors: 'Returns error if balance insufficient or network timeout (retryable). Check blockchain state before retrying to avoid double execution.'
• Embed numeric constraints in parameter descriptions, not just schema. E.g., 'Leverage for the order (integer, 1 - 100, default 10)' instead of relying on Zod min/max validators alone.
• For tools accepting private_key, add a deprecation notice in descriptions directing users to the server-side secret injection approach once implemented.
• Add output examples or schema definitions to tool registration (if using client.ts configureServer). E.g., 'fetch_price returns {bid_prices: [...], ask_prices: [...], last_trade_price: number, timestamp: string}'.

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

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry