An MCP server for querying ERP system data including attendance, student profiles, faculty information, departments, courses, and feedback from a MongoDB database
Critical failures across all dimensions. All 13 tools lack proper input schemas, parameters are documented in descriptions but not in structured JSON Schema with types. Descriptions are minimal (10-20 chars) and do not explain WHEN to use each tool or what it returns. No output schemas documented. Parameter descriptions are generic ('Array of entity objects') without explaining what entities are valid or how to construct them. No error handling guidance. No tool annotations (readOnlyHint, etc.). Naming is inconsistent: 'student_list_by_class' and 'class_student_list' are duplicates (tools 5 and 13). No pagination support despite tools returning lists. No security considerations (MongoDB ObjectId exposure, hardcoded credentials in source). This server is not production-ready.
Get attendance report for a class by classId
Get attendance summary for a student by studentId
Get attendance report for a subject by subjectId
List students in a class by classId
List subjects in a course by classId
List classes in a department by departmentId
No input schemas with type definitions. All tools declare parameters in descriptions only (e.g., 'entities' is described as 'Array of entity objects' but has no JSON Schema type, properties, or required fields). LLMs cannot validate inputs or understand structure.
Descriptions are too short (10-20 chars) and lack context. 'Get attendance summary for a student by studentId' does not explain when to use this vs other attendance tools, what 'entities' parameter structure is, or what the response contains. Descriptions must be 50-200 chars with WHAT, WHEN, and WHAT-IT-RETURNS.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 22 | <=2025-11-25 | v2 |
Get department summary by departmentId
Get faculty profile by facultyId
List subjects taught by a faculty by facultyId
Get feedback responses for a specific question
Get feedback summary by semester
List students in a class by classId
Get student profile by studentId
Duplicate tools: 'student_list_by_class' (tool 5) and 'class_student_list' (tool 13) appear to do the same thing. LLMs will waste reasoning cycles deciding between them. Consolidate into one canonical tool.
No output schemas documented. Tools return complex objects (e.g., attendance reports with charts, nested student info) but LLMs have no schema to understand what fields to expect. This forces LLMs to guess field names for downstream operations.
No error handling guidance. Tools do not document what happens on invalid input (e.g., missing studentId, invalid instituteId). No recovery suggestions. LLMs receive raw errors with no actionable next steps.