MCP server for quantitative trading strategy generation, backtesting, and execution. Provides tools for task registration, Yahoo Finance data querying, code execution via Kubernetes, and result retrieval.
AgentQuant MCP server has three tools with basic schema definitions, but exhibits significant gaps across naming clarity, parameter descriptions, output documentation, and error handling. The codebase shows tool registration via FastMCP decorators (@mcp.tool()), but the source excerpt is incomplete (ends mid-function in yh_query_save). All three tools are write-operations that lack confirmation/dry-run patterns, proper error guidance, and output schema documentation. Naming is partially acceptable but lacks clarity for LLM disambiguation. Parameters have type hints and some descriptions, but descriptions are sparse and lack format/constraint details. No visible pagination support, no error classification, and no recovery guidance.
Execute the generated code and return the output.
Register a task with the user_prompt, return a task UUID if succeeded.
Query Yahoo Finance and save the data, return storage key if succeeded.
Incomplete source code in excerpt: yh_query_save function ends mid-implementation ('task_info' appears unfinished). Cannot fully assess output schema, error handling, or full parameter validation.
No output schema documentation visible. None of the three tools have documented return types or response field descriptions. LLMs cannot plan downstream calls or extract required IDs without knowing the output structure.
Destructive/write operations lack confirmation or dry-run pattern. All three tools perform state mutations (register task, query/save data, execute code) but have no confirmation_required annotation, no dry_run parameter, and no guidance about idempotency. Agents risk unintended side effects.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error recovery guidance. Exception handlers catch errors (e.g., 'Failed to save to Redis') but return bare status strings ('failed', 'success') without actionable next steps. LLM receives no guidance on whether to retry, ask user, or abort.
Parameter descriptions incomplete. 'time_frame' in yh_query_save lacks clarification on allowed values (1d, 1h, 1m inferred from comment only; not formal enum). 'start_date' and 'end_date' lack format validation examples. No mention of timezone handling.
Naming lacks verb clarity. 'yh_query_save' uses abbreviation 'yh' (Yahoo Finance not obvious) and combines two operations (query + save). 'task_register' is acceptable but 'code_executor' is vague, does it parse, validate, compile, or run? Consider: 'create_task', 'fetch_yahoo_finance_data', 'execute_trading_code'.
No pagination or result limits documented. yh_query_save fetches historical OHLCV data which could span years; no visible limit, offset, or page_size parameters to constrain response size. Large uncontrolled results blow context window.
Tool description for yh_query_save incomplete: does not specify what data is returned, what 'storage key' format is, or how task_id is used. Code shows data is stored in Redis with a key like 'TICKER:TIMEFRAME:DATE:DATE', but description does not surface this.
code_executor lacks input validation and assumes task_id exists. No description of what code will be executed, what environment it runs in, or what outputs to expect. Source excerpt is incomplete; full logic not visible.
Missing tool annotations. None of the three tools carry destructiveHint, readOnlyHint, or idempotentHint annotations in their schemas. Per current MCP spec (2026-07-28), write tools should be marked destructive.