A Spring Boot-based MCP server for AI-assisted quiz generation with tools to create multiple types of questions (fill-blank, radio, checkbox, essay, file)
This MCP server has severe definition quality issues across all dimensions. Tool descriptions are extremely brief (4-6 characters in Chinese), provide no actionable context, and fail to meet minimum standards. Input schemas are visible in the type annotations but lack detailed parameter descriptions. The server appears to be a Spring AI integration for quiz question generation, but the tool definitions do not meet production MCP standards. All five tools follow an identical pattern with minimal documentation. No output schemas are documented. Error handling guidance is absent. The tools are focused on CREATE operations (WRITE risk) but this critical side-effect nature is not reflected in descriptions or error guidance.
生成多选题
生成简答题
生成文件题
生成填空题
生成单选题
Tool descriptions are critically short (4-6 characters in Chinese, e.g. '生成填空题' = 'Generate fill-blank question'). These fail the 10-1024 character minimum and provide zero context for when/why to use each tool or what it returns.
No output schemas documented for any tool. LLMs cannot determine what fields to expect in responses, preventing proper composition and downstream tool selection. This violates the critical requirement to document output structure.
Input parameters (fillBlankPayLoad, radioQuestionPayLoad, etc.) lack individual descriptions. The rubric requires 'every parameter needs a description explaining what it controls.' Currently, only a single vague description exists for the entire payload object. Parameters with type 'FillBlankQuestion', 'RadioQuestion', etc. are not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 13 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
No error handling guidance provided. Tools are marked as WRITE risk (destructive operations that create questions) but there is no documentation of what errors can occur, how to retry, or how to recover. This violates the pattern:recovery-guide and pattern:error-classification requirements.
toolContext parameter description is generic ('Tool context containing quizId'). What is a quizId format? Is it required? What happens if it's invalid or missing? LLMs cannot determine valid input without explicit constraints (format, range, enum).
Tool names use English verb_noun style (createFillBlankQuestion) but descriptions are entirely in Chinese, creating a language mismatch. Tool names are reasonable but descriptions fail to guide LLM selection and usage.
No documentation of what FillBlankQuestion, RadioQuestion, CheckboxQuestion, EssayQuestion, and FileQuestion types contain. LLMs must infer the expected structure for these payloads, risking incorrect formatting and failed API calls.