Loading ToolBench
Provides access to Moodle courses, content, calendar events, resource download, and class schedule.
MUSTER MCP has explicitly registered 7 tools with schemas and descriptions visible in main.py. However, the implementation exhibits significant gaps in description quality, parameter documentation, error handling, and output schema clarity. All tool descriptions are present but many fall below the production baseline of 10-1024 characters (most are 50-150 chars). Parameter descriptions are minimal. Critical issues: (1) output schemas are not documented, responses are wrapped in JSON but structure is not described to LLMs; (2) error handling returns generic error objects with no recovery guidance; (3) parameter constraints and formats are not formalized (enums, patterns, ranges); (4) tool descriptions lack WHEN/WHY guidance and prerequisites; (5) no indication of data sensitivity, especially for tools handling file downloads and browser automation. The tools are functional but designed for human developers, not LLM agents, LLMs lack signal to select tools confidently or handle failures.
Download Moodle resource file(s) (PPT, PDF, etc.) from a URL. Supports saving to a custom local directory.
Get all available courses and URLs from Moodle.
Get class schedule in this week; pass null for full week, or date (YYYY-MM-DD) to filter. If you need multiple days, pass null once instead of multiple calls.
Get all assignments/resources for a course by exact name (call get_all_courses first).
Get current local datetime as YYYY-MM-DD HH:MM:SS.
Get upcoming events and deadlines from Moodle calendar.
Output schemas not documented. Tool responses are JSON-wrapped but structure is not declared in tool metadata. LLMs cannot plan downstream calls or extract fields reliably.
Error handling returns generic error dicts with no recovery guidance. Example: {"error": "Failed to get courses: <exception>"} tells LLM nothing about why it failed, whether to retry, or what to do next.
Parameter descriptions are minimal and lack constraint documentation. Example: download_resource 'download_path' parameter has unusual description mentioning 'WRONG: true, false', this is confusing and suggests poor parameter design. Missing: format specs, valid ranges, regex patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Open a URL in a new authorized browser window after Moodle login (show to user).
Tool descriptions lack action context. They state WHAT (e.g. 'Get all courses') but not WHEN to use, prerequisites, or dependencies. Example: get_course_content says 'call get_all_courses first' in description but this is a procedural hint, not a design pattern.
open_URL_with_authorization tool name is awkward ('with_authorization' reads unnaturally). Better names: open_url, open_resource_url, or open_authorized_url. Current name risks LLM confusion on intent.
download_resource description includes implementation detail ('PPT, PDF, etc.') but does not specify what file types are supported, what size limits exist, or where files are downloaded if no path is given. Missing: format constraints, output format, success criteria.
No pagination support on list-like tools (get_all_courses, get_course_content, get_pending_events). If a user has 100+ courses or 1000+ events, returning all at once will overflow context and waste tokens.
get_class_schedule uses optional 'date' parameter with type ['string', 'null']. Schema allows null, but parameter is not in required array, this is ambiguous. LLMs may struggle to understand whether to pass null or omit the parameter entirely.