Loading ToolBench
Model Context Protocol server for Moodle development — search moodledev.io docs from Claude, Cursor, Continue, or any MCP client.
moodle-mcp defines 10 tools with generally clear naming and adequate descriptions. Most tools have complete input schemas with type constraints and descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and composition clarity. Tool descriptions average 180 chars (baseline 194), which is acceptable but could be more specific about when to use each tool vs. alternatives. Parameter descriptions are present but sparse in some cases. The server accepts natural identifiers (queries, component names) which is good, but does not clearly document what data structures are returned or how tools chain together. Security is handled well (no secrets in params, environment-based auth), but error recovery paths are not explicitly documented in most tool descriptions.
Call a Moodle Web Services function on the configured instance. Requires MOODLE_URL and MOODLE_TOKEN env vars. The token's capabilities determine what may be invoked; this tool itself performs no privilege escalation. Many WS functions modify state — review the function name before invoking.
Fetch a single moodledev.io page and return its full extracted body text + headings. Use after search_moodle_docs when you need the whole page, not the excerpt. Accepts absolute moodledev.io URLs or relative paths (e.g. /docs/apis/core/hooks).
Look up Moodle capability/access API docs with a quick-reference card (db/access.php, has_capability, RISK_* bitmask). Optional component name (e.g. 'mod_quiz') focuses the search.
Return the Moodle core Hooks API index — known hook classes and where listeners are declared. Use when the user asks about hook callbacks, db/hooks.php, or which hooks are dispatched by core.
Return current Moodle versions parsed from moodledev.io/general/releases — useful when checking $plugin->requires or LTS targets.
Output schemas not documented for any tool. LLMs cannot plan multi-tool sequences without knowing what fields are returned.
Tool descriptions lack 'when to use' context and often do not distinguish from similar tools. E.g., search_moodle_docs vs lookup_db_xmldb overlap but selection criteria are not explicit.
No error recovery guidance in descriptions. E.g., search_tracker and list_ws_functions do not explain what happens on invalid token, network error, or empty results, or what the LLM should do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
List all Moodle plugin types with one-line descriptions and a documentation URL when one exists in the sitemap.
List the Moodle Web Services functions available to the configured instance token (via core_webservice_get_site_info). Requires MOODLE_URL and MOODLE_TOKEN env vars. Read-only.
Search Moodle XMLDB / database conventions — install.xml schema, field types (XMLDB_TYPE_*), upgrade.php patterns.
Search the official Moodle developer documentation at moodledev.io. Returns top matching pages with title, URL, headings, and a short excerpt. Supports phrase matching with double quotes and synonym expansion (cap→capability, ws→webservice, hook↔listener, etc.). Use this for any API, plugin type, Hooks listener, capability, XMLDB, web service, or developer-facing Moodle concept. When MOODLE_DOCS_ALGOLIA_APP_ID and _API_KEY env vars are set, uses Algolia DocSearch for higher-precision recall.
Search tracker.moodle.org (Jira) for issues matching the query. Returns key, status, resolution, last-updated, and affected/fix versions. Use when the user asks about known bugs, MDL-XXXX tickets, or feature requests. Optional version filters scope the search to a release.
Tool chaining IDs not documented. search_moodle_docs returns hits; unclear if fetch_moodle_page accepts the returned URLs directly. call_ws_function accepts function names; unclear how list_ws_functions results map to call_ws_function parameters.
Destructive tool (call_ws_function) lacks confirmation or dry-run pattern. Description warns that many WS functions modify state but offers no safeguard or user confirmation step.
Some descriptions contain jargon without explanation (XMLDB, RISK_* bitmask, bracketed-key form, Algolia DocSearch, core_webservice_get_site_info). LLMs may not understand when to invoke these tools.