Server has 9 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (get_, create_, modify_, cancel_). Descriptions are present but brief (avg ~80 chars, below 194-char baseline). All tools have input schemas with types and descriptions. Critical gap: no output schemas documented, LLMs cannot predict response structure for chaining. Tool annotations present (read_only_hint, destructive_hint, idempotent_hint) but only applied at registration time, not visible in tool definitions. Error handling and recovery guidance absent. Parameter descriptions lack format/constraint details (e.g., 'symbol' pattern is defined in schema but not explained in description text).

• Document output schemas for all 9 tools. Include field names, types, and descriptions. Example: 'get_candles returns {candles: [{timestamp, open, high, low, close, volume}], total_count: int}'.
• Expand parameter descriptions to include format constraints. For 'symbol': 'KRX: 6-digit code (e.g., 005930, 0101N0); US: ticker (e.g., AAPL). Only alphanumeric, '.', '-' allowed.'
• Add error handling guidance to destructive tools. Example: 'If order creation fails with "insufficient_funds", check get_holdings first. If "invalid_symbol", verify with get_stocks.'
• Implement confirmation pattern for create_order, modify_order, cancel_order. Return a dry-run result with 'input_required' to ask user approval before executing.
• Enhance tool descriptions with WHEN and WHY. Example: 'get_orders retrieves past and pending orders. Call this before create_order to check for duplicate orders. Use status filter to find pending orders awaiting execution.'

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

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