Loading ToolBench
MCP server for securely querying Moodle LMS with PII redaction and privacy protection
This server has critical definition quality gaps. All three tools are READ_ONLY operations with basic descriptions, but lack essential schema documentation, parameter descriptions, and proper output structure definitions. While the naming follows verb_noun convention (list_, get_), the schemas are incomplete, parameters lack descriptions in the interface, and output formats are undocumented plain text rather than structured objects. The code reveals database error handling but no guidance for LLM recovery. Per-tool analysis shows consistent deficiencies across naming (acceptable), descriptions (minimal but present), and schemas (critical gaps).
Identifies students who haven't logged into Moodle for X days.
Retrieves the last X recently active users across the entire Moodle platform.
Returns a list of students in a course with PRIVACY REDACTION applied.
No output schema documentation. All three tools return unstructured plain-text strings (e.g., 'Student_1 - Status: Enrolled'). LLMs cannot parse structured fields, extract downstream references (like student IDs), or plan multi-step workflows.
Missing parameter descriptions in tool definitions. The 'course_id' parameter in list_students_safe has a description ('The course ID to query for enrolled students'), and 'days_inactive' and 'limit' have descriptions, but the schema structure shown lacks clarity on expected ranges, validation rules, and format constraints.
Input schemas incomplete. list_students_safe schema shows course_id as integer with description, but does NOT specify min/max bounds, required field status, or validation constraints. 'days_inactive' defaults to 7 but no min/max range documented. 'limit' defaults to 10 with no upper bound.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Non-idempotent semantics unclear. All three tools query a live database. Repeated calls with identical parameters may return different results (new logins, activity changes). No mention of pagination, caching, or result determinism.
No error recovery guidance. Exception handlers return generic strings like 'Secure Connection Error: {error}' and 'Database Error: {error}'. A connection failure should suggest retry, checking credentials, or fallback paths, not a raw exception message.
Hardcoded database credentials in source code. The connection strings use hardcoded host, user, and password: host='host.docker.internal', user='moodle_ai_reader', password='Njibhu@123'. This is a critical security vulnerability.
No pagination or result limits enforcement. list_students_safe uses LIMIT 10 hardcoded in SQL; get_recent_active_users accepts a 'limit' parameter but the description does not specify max allowed (capping at 100 prevents context explosion).
Tool descriptions are minimal and lack context for tool selection. 'Returns a list of students in a course with PRIVACY REDACTION applied' (list_students_safe) does not state: (1) What is returned? (2) When to use this vs get_at_risk_students? (3) What are prerequisites (valid course_id)?