The server exposes 3 task management tools with basic naming and descriptions, but suffers from significant gaps in schema definition, parameter documentation, and error handling. All three tools follow a simple verb_noun pattern (get_*, list_*) which is good, but descriptions lack depth about when to use each tool and what they return. Input schemas are present but parameters are minimally described, no enums, ranges, or constraints despite optional/required flags. Output schemas are not documented. The tools operate on async task state (backtest, download) but lack guidance on task lifecycle, result structure, or error recovery. No explicit tool annotations (readOnlyHint is present in metadata but not visible in formal schema). This is a below-average server with functional but incomplete definitions.

• Document output schemas for all three tools. For get_task_status, specify: {status: enum[pending|running|completed|failed], progress_description: string, completion_percentage: number [0-100]}. For get_task_result, specify: {status: enum[...], result: object (with documented fields), error_message?: string}. For list_tasks, specify: {tasks: [{id, type, status, created_at, ...}], total_count: number, has_more: boolean}.
• Convert natural-language enums into formal JSON Schema constraints. Add 'enum': ['backtest', 'download'] to type parameter and 'enum': ['pending', 'running', 'completed', 'failed'] to status parameter in list_tasks input schema.
• E.g., for taskId: 'The unique task ID returned by async backtest or download operations. Format: UUID v4. Use get_task_status to poll progress or get_task_result to retrieve final result.'
• Add pagination guidance to list_tasks. Document: 'Returns up to 100 most recent tasks. Use offset and limit parameters for pagination. Always check has_more flag before assuming you have all results.'
• Add error recovery guidance in descriptions. E.g., 'If task_id is invalid or task no longer exists, call list_tasks to discover available task IDs. If task status is failed, check error_message field for retry hints.'
• Clarify tool composition in descriptions. Add to get_task_status: 'Use this to poll ongoing task progress. Once task reaches completed or failed status, call get_task_result to retrieve full output.' Add to get_task_result: 'Call this only when task status is completed or failed. For in-progress tasks, use get_task_status instead.'

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

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