Static source inference · medium confidence · detected: stateful session
Deprecated protocol patterns detected
Summary
Single tool 'kline' with visible schema and basic description, but significant quality gaps. Schema is present with typed parameters (codes, endDate, days, maxRows, adjust), but lacks proper descriptions for most parameters and defines 'codes' without type constraint (declared as 'string' but accepts both comma-separated and array formats, ambiguous). Description is minimal (56 chars) and generic, lacking WHEN to use, prerequisites, or return value documentation. No output schema documented. Parameter 'adjust' lacks explanation of what 'none' means vs other values. No error handling guidance. Tool annotations present (readOnlyHint correctly set), but overall definition lacks LLM-optimization per pattern:tool-description baseline (avg 194 chars for tool descriptions, avg 72 chars per param). Code sample shows MCP client calling the server, but actual server implementation not visible, tool definition inferred from examples/source-check/check_sources.py usage rather than explicit server-side registration.
Tools (1)
klineread onlyauthsource verified48/100
Fetch OHLC (Open, High, Low, Close) stock data for given codes and date range
Tool description is critically short (56 chars) and lacks essential details. Does not explain WHAT the tool returns, WHEN to use it vs alternatives, or any prerequisites. Pattern baseline requires 34-392 char range with complete context.
Parameter descriptions are missing or incomplete. 'codes' lacks clarity on format (comma-separated string vs array). 'endDate' has no format validation hint. 'days' and 'maxRows' missing range constraints. 'adjust' unexplained, what does 'none' mean, and what other values are valid? All parameters need 10-20 char minimum descriptions per pattern:tool-description.
'codes' parameter type ambiguous: declared as 'string' but description suggests array format. Per pattern:constrained-input, when multiple formats are valid, use explicit enum or separate parameters (codes_string, codes_array) with clear guidance.
kline
Recommendations
Expand tool description to 100-150 chars explaining: 'Fetch OHLC (Open, High, Low, Close) stock price data for Chinese stock codes. Returns daily bars with adjusted/unadjusted prices. Use this to retrieve historical stock data for technical analysis or backtesting. Requires a valid stock code (6-digit format, e.g., 000001 for Ping An Bank) and date range.'
Add full parameter descriptions: codes → 'Stock code(s) to fetch: either comma-separated string (e.g., "000001,000002") or array (e.g., ["000001", "000002"]). Codes are 6-digit strings in format XXXXXX.'; endDate → 'End date for the range in ISO 8601 format (YYYY-MM-DD). Cannot be in the future.'; days → 'Number of trading days to retrieve (1-365). Actual rows returned may be less if fewer trading days exist in range.'; maxRows → 'Maximum rows per stock (1-1000). Default: unlimited. Useful to cap response size for large date ranges.'; adjust → 'Price adjustment method. Use "none" for unadjusted prices (as-traded), or specify adjustment type if available (check tool for valid options).'
Document the complete output schema with example: '{items: [{code: string, rows: [{date: string (ISO 8601), open: number, high: number, low: number, close: number}], adjust: string}], qualityWarnings?: boolean, partialErrors?: boolean}'
Add error handling guidance: 'If a code is invalid, the tool returns qualityWarnings:true with that code omitted. If the date range is invalid (endDate before startDate, future dates), returns isError:true with reason. Retry is not useful for invalid codes, suggest the user verify codes via a stock search tool if available.'
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained
No output schema documented. LLMs cannot infer what fields kline returns (e.g., does it return {items: [{code, rows: [{date, open, high, low, close}]}]}?). Per pattern:response-shaper, all tool outputs must document structure, types, and pagination if applicable.
No error handling guidance. What happens if a stock code is invalid? If date range is out of scope? If the API times out? Per pattern:recovery-guide, errors must categorize as retryable/user-fixable/fatal and suggest next steps.
Tool definition inferred from example client code (check_sources.py), not seen as explicit server-side registration. Per HARD SCORING RULES, when tool registration is not directly visible, cap per-tool score at 50. Server implementation details not provided in source excerpt.
kline
Clarify parameter constraints in schema: make 'adjust' an enum (if only 'none' is valid, declare it as enum: ['none']; if others exist, list them). Change 'codes' type from 'string' to explicitly allow both string and array, or split into separate params with clear names.
Verify and document pagination/limits: does the API support pagination (offset/limit/cursor)? If large result sets are possible, add offset and limit parameters and document that results may be truncated.
Add a composition note: 'This tool is read-only (no side effects). Safe to retry. Results are point-in-time (same input always returns same output for a given market date range). For live/real-time quotes, use a different tool.'
Confirm server-side registration in MCP server code (not visible in provided excerpt). Ensure the 'kline' tool is registered in the server's tools/list response with identical names, schemas, and descriptions.