Hong Kong misc MCP Server providing misc data tools
Single-tool server with acceptable naming and schema quality, but descriptions lack depth and lack critical guidance for LLM tool selection. The tool `get_government_auction_data` follows verb_noun naming correctly and has a complete JSON Schema with typed parameters. However, the description (98 chars) falls short of actionable guidance, it states WHAT the tool does but not WHEN to use it or critical constraints (e.g., date range validation, available languages). Parameter descriptions are present but minimal (12 - 45 chars each), providing only bare names without format guidance. No error handling documentation or recovery guidance is visible. Output schema is inferred from the code (List[Dict]) but not explicitly documented in the tool definition. The server lacks pagination, result limits, and structured output documentation, baseline for A-grade tools includes these. Code quality is good (clean structure, input validation), but tool definition maturity is mid-grade.
Auction data of confiscated, used/surplus, and unclaimed stores from Government Logistics Department Hong Kong.
Tool description lacks actionable guidance for LLM selection. Does not state WHEN to call this tool vs. alternatives, what constraints apply (e.g., date range limits, data freshness), or what the typical use case is. Current description (98 chars) only restates the data source without context.
Output schema not explicitly documented. The tool returns List[Dict] with fields inferred from code (Date of Auction, Auction List No., Lot No., Description, Quantity, Unit), but the tool definition contains no formal schema documentation. LLMs cannot reliably predict what fields to expect or how to chain with downstream tools.
Parameter descriptions are minimal (12 - 45 chars). E.g., 'Starting year for the data range.' does not specify format (4-digit year?), valid range (1900 - 2100?), or whether historical data is available. 'Language code for the data ('EN', 'TC', 'SC').' embeds example values in description rather than declaring enum constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No error handling guidance. The code shows `return {'type': 'Error', 'error': csv_data['error']}` for fetch failures, but the tool definition provides no recovery guidance (e.g., 'If data unavailable for a date range, try expanding the range or checking the Hong Kong Government Logistics Department website'). Agents cannot self-correct on errors.
No result limit or pagination. The function returns all matching auction items without a limit or pagination parameters. If 1000+ items match the date range, the response will blow the context window. Baseline pattern recommends capping results at 20 - 50 items and offering pagination.
Language parameter should be an enum, not a free-form string. The description lists valid values ('EN', 'TC', 'SC'), but the JSON Schema type is 'string' with no enum constraint. LLMs may hallucinate invalid values (e.g., 'English', 'Traditional', 'Simplified'). Schema should enforce `"enum": ["EN", "TC", "SC"]`.
No documented date range constraints. The code shows `end_date = datetime(end_year, end_month, 28)` (hardcoded to 28th for safety), but this is not documented in parameter descriptions. Users (and LLMs) cannot know whether they can query 20 years back or only 2 years. Similarly, no statement of data freshness (is today's data available? Is there a lag?).