An MCP server that provides RAG-based educational support with task answering capabilities using document processing and semantic chunking
Single tool 'get_task_answer' has a clear, action-oriented name and reasonable description, but lacks critical depth in parameter documentation and output schema definition. The parameter descriptions are minimal (10-15 chars each), falling well below the 72-char baseline for A+ tools. The tool's output is completely undocumented, LLMs cannot predict or plan downstream usage. Input schema is present but parameters lack the constraint documentation, format hints, and dependency explanations required by pattern:constrained-input and pattern:tool-description. The server is functional but would require significant hardening before production use.
Answer questions based on task materials and learning steps using RAG retrieval
Parameter descriptions are severely under-specified. 'step' is described as 'The current learning step (orientation, conceptualisation, executive_support)', this is only 75 chars but lacks guidance on what happens if an invalid step is passed, or whether the parameter is required. 'question' and 'current_document' descriptions are similarly bare (15-20 chars).
Output schema is completely undocumented. The tool returns a string (the model's response), but LLMs have no visibility into whether this is a free-text answer, structured JSON, markdown, or raw model output. No schema definition means downstream tools cannot reliably parse or chain on this result. Per pattern:response-shaper, structured output with typed fields is required.
The 'step' parameter accepts a free-form string but the description suggests only three valid values: 'orientation', 'conceptualisation', 'executive_support'. This should be declared as an enum constraint in the JSON schema, not just mentioned in the description. Per pattern:constrained-input, free-form strings invite hallucinated values; enums are self-documenting.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
No error handling documentation. The tool calls an LLM (OpenAI GPT-4) and a retrieval chain, both of which can fail (API errors, empty results, timeouts). The code has no try-catch or error recovery logic visible. Per pattern:recovery-guide, error responses must tell the LLM what to do next, but this tool offers no guidance on failure modes.
Tool description is 115 chars, which is at the lower end but acceptable. However, it does not explicitly state WHEN to use this tool vs others, or what makes it distinct. 'Answer questions based on task materials and learning steps using RAG retrieval' lacks guidance on prerequisites (must documents be loaded first?) or failure recovery.
The 'current_document' parameter description is only 38 chars ('The current document/task being worked on') and does not specify format, required length, valid values, or what happens if the document doesn't exist in the database. Should be expanded to ~72 chars with constraint and dependency info.