A Spring AI MCP Server using stdio transport for help desk ticket management with AI-powered troubleshooting, elicitation, and sampling capabilities
Three tools with basic structure but significant gaps. Tool names are action-oriented (createTicket, getTicketStatus, troubleshootIssue) and descriptions exist in Chinese, but lack English translations and depth. Input schemas are visible with type and description fields present. However, output schemas are completely undocumented, LLMs cannot predict what these tools return. Parameter descriptions are minimal (1-2 phrases). No error handling guidance, no pagination support for getTicketStatus (which returns lists), and no indication of idempotency or side effects. The troubleshootIssue tool description mentions 'AI analysis' but does not clarify whether it calls an external LLM or uses local logic. Tool composition is reasonable (three distinct concerns), but parameter naming could be more explicit (e.g., 'issue_description' vs 'issue').
建立「服務工單」
取得所有「服務工單」並提供工單相關細節,包括工單編號、問題描述、狀態、建立時間及預計完成時間
在開立服務工單之前,先透過 AI 分析問題並提供自助排障建議,包含可能原因、排查步驟與是否建議開立工單
Output schemas completely undocumented. LLMs cannot predict return types, field names, or structure for any of the three tools. This forces agents to guess and risks parsing failures.
getTicketStatus returns a list but has no pagination (limit, offset, page_size) or result count. Returning all tickets at once risks context window exhaustion and violates the paginated-result pattern.
Descriptions are in Chinese only and lack English translations. Tool descriptions do not explain WHEN to use each tool vs. the others, or what the LLM should expect. Descriptions under 50 chars for getTicketStatus.
No error handling guidance. If createTicket fails (e.g., duplicate issue, invalid username), the LLM receives no recovery hint. No indication of retryability or user-fixable errors.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2025-06-18+ | v2 |
Parameter 'issue' is ambiguous, does it mean issue_description, issue_title, or issue_category? Naming should be explicit (e.g., 'issue_description'). No enum constraints on priority or status fields.