Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server implements 6 Chinese astrology tools with consistent but mediocre quality. All tools have schemas and non-empty descriptions, but descriptions are minimal (20-40 chars each, well below the 194-char production baseline). Parameter descriptions exist but are repetitive boilerplate across all tools. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. No output schema documentation visible in tool definitions. Error handling and recovery guidance are absent. Tool naming follows verb_noun convention (get_, analyze_) which is good, but parameter naming has consistency issues (birth_date vs date, query_date inconsistently named). The tools form a coherent astrology domain but lack the LLM-optimized descriptions and output schemas expected of production tools.
Tool descriptions are too short and lack LLM selection guidance. All 6 tools have descriptions of 20-40 characters (Chinese). Production baseline is 194 chars. Descriptions do not explain WHEN to use this tool vs similar ones (e.g., when to call get_ziwei_chart vs analyze_ziwei_palace), causing LLMs to guess.
No tool annotations despite all tools being READ_ONLY. The metadata readOnlyHint should be present in tool definitions to inform agents this is safe to call repeatedly. Current spec (2026-07-28) expects tool annotations for safety classification.
Expand each tool description to 100-200 characters. Include: (1) What the tool calculates (e.g., 'Generates a Zi Wei Dou Shu natal chart showing personality archetypes and life trajectory'); (2) When to use it vs related tools (e.g., 'Call this to see the birth chart structure. Call get_ziwei_fortune to forecast future periods.'); (3) Key output (e.g., 'Returns the 12 palaces with star placements and interpretations').
Add readOnlyHint: true to all 6 tool definitions in the tool registration code (likely mingli_mcp/mcp_server/tools/registry.py or tool handler files). This signals to agents these are safe, repeatable, non-destructive calls.
Document output schemas for each tool. Define the response structure (e.g., get_ziwei_chart returns {chart_type: string, palaces: [{name: string, stars: [string], meaning: string}], generated_at: string}). This allows LLMs to plan chained calls and extract values.
Standardize parameter names across tools: use 'birth_date' consistently (not 'date'), 'query_date' for fortune lookups. Add a discovery table in README: 'Parameters across all tools'.
Enhance parameter descriptions with dependency hints. For each solar_time correction param, add: 'If true, longitude, latitude, birth_hour, birth_minute are required for accurate True Solar Time calculation; defaults to false (Standard Time only).'
Add error classification to tool descriptions. Example: 'Returns error code INVALID_DATE if birth_date is malformed (use YYYY-MM-DD format, valid month 01-12, day 01-31). Try reformatting the date or call with default dates to see the expected format.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 6 points across a rubric change (v1 → v2)
40/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
40
<=2025-11-25
v2
2026-03-09
F
34
-
v1
No output schema documentation visible in tool definitions. LLMs cannot plan downstream tool calls or extract relevant data without knowing what fields to expect. Production tools document return type with field names and types.
Parameter naming inconsistency: some tools use 'date', others use 'birth_date', and query tools use 'query_date'. This forces LLMs to reason about parameter mappings rather than reusing parameter names across similar tools.
Parameter descriptions are generic boilerplate repeated across all 6 tools (e.g., '出生日期 (格式: YYYY-MM-DD)' for date, '性别 (男/女)' for gender). They do not explain why the parameter matters for the specific tool or dependency hints for optional fields like solar_time correction.
No error handling or recovery guidance in tool definitions. If birth_date is invalid or time_index is out of range, the LLM has no hint what to do next. Pattern expects: 'Invalid date: got "2025-13-45", must be YYYY-MM-DD with valid month/day.'
Optional parameters (longitude, latitude, use_solar_time, birth_hour, birth_minute) lack clear dependency documentation. The description should state: 'Required only if use_solar_time is true; otherwise ignored.' Current descriptions assume LLMs infer this context.
Create separate tool discovery/help resources (via resources capability) documenting: (1) Astrology system differences (Zi Wei vs Ba Zi); (2) Parameter value ranges (time_index 0-12 corresponding to 12 Chinese hours); (3) Output field meanings and how to interpret results.
Document the relationship between time_index (0-12) and human time. Add: 'time_index maps to Chinese hour: 0=late night (23:00-00:59), 1=early morning (01:00-02:59), etc. Use time_index 12 for unknown birth time (system will use default midday).'
Consider adding a discovery tool like 'list_palaces' or 'get_astrology_guide' (via resources) that returns the schema of analyze_ziwei_palace results, helping agents understand what palace_name values are valid and what the output structure is.