Moodle Downloader MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MOODLE_URL | Yes | The base URL of the Moodle site. | |
| MOODLE_PASS | No | The password for the Moodle account. | |
| MOODLE_USER | Yes | The username for the Moodle account. | |
| MOODLE_TOKEN | No | A webservice token for authentication. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| moodle_setupA | Universal setup schema + auth status for any Moodle school. Call first when unauthenticated. Never invent username formats. |
| moodle_probeA | Check if a Moodle base URL is reachable and Mobile token login looks available. No credentials required. |
| moodle_configA | Show moodle-agent config path and site profiles (token redacted). |
| moodle_whoamiC | Verify saved Moodle token and return current user/site info. |
| moodle_initA | Log in to ANY Moodle site and save webservice token (password is not stored). Username format is school-specific — pass exactly what the user uses on the portal. Prefer token if available. Password goes only via env to the child process. |
| moodle_courses_listB | List enrolled Moodle courses (id, shortname, fullname). |
| moodle_course_treeA | Show sections and modules (with file counts) for one course id. |
| moodle_course_downloadA | Full download of one course into --out (or config out_dir). force=true re-downloads even if size matches. Can take several minutes. |
| moodle_course_syncA | Incremental sync one course (skip unchanged files by size). Use this to repair incomplete downloads. |
| moodle_sync_allC | Sync all enrolled courses. Long-running. |
| moodle_wiki_scaffoldA | Create/update _wiki stubs for a downloaded course (by path or course_id). |
| moodle_wiki_statusC | Show ready vs pending wiki cards for a local course. |
| moodle_wiki_rebuild_indexB | Rebuild _wiki/INDEX.md from filled card frontmatter. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
The authentication tools (moodle_setup, moodle_probe, moodle_config, moodle_whoami, moodle_init) have overlapping responsibilities around setup and token verification, which could cause confusion. Course and wiki tools are clearly distinct, but the auth cluster blurs boundaries.
Tool names mix verb-first patterns (moodle_setup, moodle_sync_all) with noun-first patterns (moodle_courses_list, moodle_wiki_scaffold). Some names use nouns as actions (moodle_course_tree, moodle_wiki_status), breaking a consistent verb_noun convention.
With 13 tools, the server is well-scoped for its purpose of downloading Moodle courses and managing wiki scaffolding. Each tool addresses a distinct step in the workflow, and the count feels neither sparse nor bloated.
Core workflows are covered: authentication, course listing, downloading, syncing, and wiki generation. Minor gaps exist, such as no explicit logout or local download management tool, but agents can likely work around these.