MCP Server for KASE Stock Data - Exposes stocks.db via HTTP endpoints using fastmcp
The server defines 3 tools with basic verb-based names (get_*, list_) and reasonable descriptions (100-150 chars each). However, parameter descriptions are sparse or missing, output schemas are documented but lack detail, and error handling is generic. The schema shows proper Pydantic models for input validation but doesn't expose detailed constraints to the LLM. This is a fair/C-grade server: functional definitions with noticeable gaps in parameter annotation and output documentation.
Get the available date range in the database
Get stock price data for a specific ticker within a date range
Get list of all available ticker symbols in the database
Parameter descriptions are minimal or absent. 'ticker' in get_stocks has a description, but there is no guidance on valid ticker symbols, case sensitivity, or how to discover them. LLMs cannot infer these constraints from the name alone.
Date format validation is performed at runtime (datetime.strptime), but the LLM is not informed that dates must be ISO 8601 (YYYY-MM-DD). The parameter description says 'YYYY-MM-DD format' in the docstring, but this is not propagated to the JSON schema description field visible to the LLM.
Output schema for list_available_tickers and get_date_range are only inferred from return type hints (list[str] and dict). No structured schema documentation is provided to the LLM. The return dict for get_date_range lacks field-level descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error handling returns generic exception messages ('Database query failed', 'Error retrieving stock data'). LLMs are not told whether to retry, ask the user for a different input, or declare the task unachievable. No recovery guidance.
Tools do not accept pagination parameters (limit, offset, page). list_available_tickers may return thousands of ticker symbols, blowing the LLM context window. No guidance on result size limits.
The tool composition is good (three single-purpose tools), but there is no guidance on the expected workflow. Should get_date_range be called before get_stocks to validate date bounds? This dependency is not documented.