MCP server for exam preparation with question generation, audio processing, and chat capabilities. Provides tools for retrieving practice questions from a knowledge base and processing multi-modal input (text and audio).
The ExamBOT MCP server exposes only 1 tool: get_random_question. While the tool has a name, description, and declared input schema, significant quality gaps prevent a higher score. The description is present but verbose and partially vague (what does 'JSON structure' mean exactly?). The input schema declares a 'topic' parameter as optional string, but lacks critical details about valid topic values, constraints, and expected format. Most critically, there is NO documented output schema, the description mentions 'question', 'answer', and 'explanation' fields in prose, but no formal schema is provided. This violates the pattern:tool and pattern:response-shaper requirements. The tool does not employ error handling guidance, confirmation for potentially unsafe operations, or recovery paths. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The server architecture relies on FastAPI/HTTP, and main.py is truncated mid-code, so the actual tool registration via fastmcp cannot be fully verified, only inferred from requirements.txt listing fastmcp==2.11.3. Because tool registration is not directly visible in the provided source, the score is capped at 50 per HARD SCORING RULE #4. However, documentation gaps lower it further.
Get a random practice question from the database Arguments: It takes the topic of the question (optional). Returns: string : It returns a JSON structure that contains the following fields: 'question' is the practice question to be shown to the user; 'answer' is the correct answer to that question; 'explanation' is the explanation that can help the user understand the question and answer.
No output schema documented. Description mentions 'JSON structure' with fields 'question', 'answer', 'explanation' but provides no formal schema. LLMs cannot parse or plan downstream use of the returned data without a typed schema.
Tool registration not directly visible in source code. main.py is truncated and does not show the @server.tool() decorator or fastmcp registration. Only inferred from requirements.txt. Per HARD SCORING RULE #4, tool overall score capped at 50.
'topic' parameter lacks enum or constraint definition. Description says 'optional' but does not list valid topic values, format requirements, length limits, or invalid examples. Invites LLM hallucination of topic names.
No error handling guidance. No recovery hints for failure cases (e.g., 'topic not found'). A raw error or empty result leaves the LLM with no actionable next step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No tool annotations. No readOnlyHint (this is read-only), no destructiveHint (not destructive), no idempotentHint (appears idempotent). Missing these hints forces LLMs to infer safety semantics.
Description is verbose (169 chars) and uses informal language ('can help the user understand'). Should be concise and action-oriented: 'Retrieve a practice question on a specified topic. Returns question, answer, and explanation.'
Parameter description lacks concrete detail. Says 'topic of the question (optional)' but does not indicate what happens if omitted (e.g., 'random topic selected'), or what topics are available.
No pagination or result limiting guidance in case the tool returns arrays (e.g., multiple questions). If batch retrieval is possible, document page/offset, limit, and total count fields.