Provides tools for querying a Moodle site as a student, including courses, assignments, grades, forums, and files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Moodle Student MCP What's due in the next two weeks?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets Claude (or any MCP
client) query your Moodle as a student — no admin access required. It
uses the official Moodle mobile-app web service (moodle_mobile_app) with a
personal token, so it only sees what you already see: your courses, topics,
assignments, deadlines, grades, forums, and downloadable files.
Works with any Moodle site that has the official mobile app / web services enabled, and with any login method — a local password, or SSO via SAML/CAS/ OAuth (e.g. Google or Microsoft).
Tool | What it does |
| Confirm the token and show who you are |
| Courses you are enrolled in |
| Sections/topics and activities of a course |
| Assignments with due dates |
| Whether you submitted, grade and feedback |
| Timeline of pending work / deadlines |
| Your grades in a course |
| Forums / announcements |
| Recent posts in a forum |
| Downloadable files in a course |
| Download files to |
All read-only. Nothing is submitted or modified on Moodle.
Related MCP server: mcp-moodle
Project skills under .claude/skills/:
/moodle-tasks — prioritized weekly pending work + an execution plan for
the next deadline (also cross-checks undated assignments and the "Avisos"
forum for announced dates).
/moodle-materials — download a course's PDFs/slides/notebooks and
analyze them by reading them natively.
/moodle-grades — grades across courses, current standing, and what's
needed to reach a target.
/moodle-digest — proactive briefing of what's new and what's coming
(announcements, deadlines, unsubmitted work, new grades); pairs with
/schedule or /loop.
/moodle-study — build a study guide (summary, flashcards, practice
questions) from a topic's materials.
Requires Python 3.10+. In the project folder:
python -m venv .venv
.\.venv\Scripts\Activate.ps1 # optional, recommended
pip install -e ".[browser]" # [browser] enables automatic token capture
python -m playwright install chromium # only needed for the --browser flowThe server needs a Web Services token for the official mobile-app service. Pick the method that matches how you log in to Moodle.
If you sign in to Moodle with a username and password it validates directly:
python -m moodle_student_mcp.token_helper --url https://your-moodle-site --username USER --password PASSSSO accounts have no local password, so use the browser flow — the same way the official Moodle app authenticates.
Automatic (recommended) — opens a browser and captures the token for you:
python -m moodle_student_mcp.token_helper --url https://your-moodle-site --browserA Chromium window opens; log in normally (your institution's login, MFA if any).
The script intercepts the moodlemobile://token=... redirect, validates the
token and writes it to .env. You'll see ✅ Token OK! Logged in as: <your name>.
Manual (no Playwright):
python -m moodle_student_mcp.token_helper --url https://your-moodle-siteIt prints a .../admin/tool/mobile/launch.php?... link. Open it (logged in),
finish the login; the browser then tries to open moodlemobile://token=....
Capture it via F12 → Network → Preserve log → launch.php → Location, and paste
it back. (--paste "moodlemobile://token=..." skips the prompt.)
Already have a token (e.g. from Moodle → Preferences → Security keys)? Pass it directly with
--paste <token>.
Create a .mcp.json at the project root (copy .mcp.json.example) pointing at
your venv's Python with an absolute path (on macOS/Linux use
.venv/bin/python):
{
"mcpServers": {
"moodle-student": {
"command": "<path-to-project>/.venv/Scripts/python.exe",
"args": ["-m", "moodle_student_mcp"]
}
}
}Reload the VS Code window (or reopen Claude Code) to pick up the server; approve
the project MCP server when prompted. The token is read from .env
automatically (resolved by absolute project path, independent of the cwd).
Edit %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"moodle-student": {
"command": "<path-to-project>/.venv/Scripts/python.exe",
"args": ["-m", "moodle_student_mcp"]
}
}
}Then ask things like "What's due in the next two weeks?", "Summarize the topics of course X and what I haven't completed", "Do I have any submitted but not-yet-graded assignments?".
The token is like a password. It lives in .env (git-ignored). Don't
commit or share it. To revoke: Moodle → Preferences → Security keys → remove
the mobile app token.
Read-only, your data only — every call still goes through your account's permissions on the server.
Acceptable use: automating access to your university's Moodle, even read-only with your own account, may conflict with the institution's IT policy. Use modest request volumes and check the rules. Admins can see token usage in the web service logs.
If the token stops working (password/SSO change, expiry, maintenance), just redo step 2.
Error | Likely cause |
| Token mis-pasted / expired — redo step 2 |
| Account is SSO (no local password) — use the browser flow |
| The mobile service was disabled by the admin |
| Web services disabled on the site |
Tool returns empty | Not enrolled / no data in that course |
.\.venv\Scripts\python.exe -m py_compile moodle_student_mcp\*.py # syntax check
.\.venv\Scripts\python.exe smoke_test.py # exercise tools on real dataDownload course files to ./materials// and return local paths.
Pass fileurls (from list_files) to download specific files, or omit it to
download every file in the course. The MCP client can then read the local
path of each result (e.g. open a PDF natively). Already-downloaded files
of the same size are reused (status "cached").
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| fileurls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: local storage path, caching behavior for already-downloaded files of same size, and return of local paths. No annotations exist, so the description carries the full burden. Could mention error handling or file overwrite behavior, but current detail is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no superfluous words. The key action and parameters are front-loaded, and caching detail is placed logically at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value and caching. It covers the main workflow but could mention error handling or prerequisites (e.g., course_id must exist). Overall, it is fairly complete for a straightforward download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for fileurls by linking it to list_files output. However, course_id is not described beyond being required, and its source (e.g., from list_courses) is not mentioned. Schema description coverage is 0%, so the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download course files'), the destination ('./materials/<course>/'), and the output ('return local paths'). It differentiates from sibling tools like list_files, which only list URLs without downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the optional fileurls parameter (to download specific files from list_files) and when to omit it (to download all files). This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sections/topics and activities of a course.
Use the id from list_courses. For each section, returns its activities
(name, type, url, description and completion state when Moodle exposes it).
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It partially discloses the return data (name, type, url, description, completion state) and its reliance on a valid course_id. However, it does not explicitly state it is a read-only operation or describe error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two brief sentences, each serving a clear purpose: stating the tool's function and providing usage context and return data details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description covers the main use case and return fields. It could be more explicit about the data structure (e.g., sections containing activities), but overall it is sufficient for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'course_id' has 0% schema description coverage. The description adds crucial meaning by stating it should come from list_courses, which clarifies the expected value source beyond the raw integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sections/topics and activities of a course, with a specific verb 'List' and a distinct resource. It differentiates from sibling tools that focus on specific content types (e.g., list_assignments, list_forums).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the 'id from list_courses', providing a clear prerequisite. It does not mention when not to use this tool or alternative tools, but the prerequisite is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the recent discussions of a forum.
Use the forum_id from list_forums. Good for checking teacher
announcements. Returns title, author, date and the opening message.
| Name | Required | Description | Default |
|---|---|---|---|
| forum_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions returning 'title, author, date and the opening message', which is useful. However, it does not clarify the limit parameter's role or sorting order, though limit is implied by 'recent'. More explicit details about default limit and ordering would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. Every sentence adds value without redundancy, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states the return fields. It covers the required parameter usage and a use case. However, it omits details about the limit parameter and does not mention if the results are paginated. Overall, it is fairly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It only mentions 'forum_id' in context, but does not explain the 'limit' parameter or its relationship to 'recent'. The description partially covers one parameter and misses the other entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'list the recent discussions of a forum', specifying the verb and resource. It differentiates from sibling tool 'list_forums' by focusing on discussions within a forum and adds context for teacher announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to use 'forum_id' from 'list_forums' and suggests a use case: 'Good for checking teacher announcements.' While it does not explicitly exclude other uses or mention alternatives, the guidelines are clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your grades in a course.
Use the id from list_courses. Returns each graded item with your grade,
the max, the percentage, the weight and feedback (only YOUR grades).
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the return format (grade, max, percentage, weight, feedback) and emphasizes 'only YOUR grades,' but it does not explicitly state that the operation is read-only or discuss permissions, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no extraneous information. Every word serves a purpose, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the return fields and scope. It could be more explicit about 'current user' and 'all graded items,' but it is largely complete for an AI agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful guidance by specifying that course_id should come from list_courses. This clarifies the parameter's origin and usage beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows grades for a specific course, using 'your grades' to distinguish from siblings like get_submission_status or list_assignments. It specifies the resource and action effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by instructing to use the id from list_courses, but it does not explicitly mention when not to use this tool or provide alternatives. It sets expectations for usage without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the status of YOUR submission for an assignment.
Use the assign_id from list_assignments. Tells whether you submitted,
the submission state, whether it is still editable, whether it was graded,
the grade and the teacher's feedback. A status other than "submitted"
means it has not been turned in yet.
| Name | Required | Description | Default |
|---|---|---|---|
| assign_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what information is returned (submission state, editable, graded, grade, feedback) and the meaning of the status. It correctly implies this is a read-only operation. No side effects are mentioned, but none are expected for a status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with the first sentence clearly stating the purpose. Every sentence adds value: source of parameter, list of information, status interpretation. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description comprehensively explains what the tool returns (submission state, editable, graded, grade, feedback) and how to interpret the output. It also provides the parameter source. This is complete for the agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `assign_id` is explained by referring to `list_assignments` as its source, adding context beyond the schema. Although the schema coverage is 0%, the description provides enough guidance for an AI agent to understand where to get the value. However, it does not specify constraints or format beyond being an integer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show the status of YOUR submission for an assignment.' It specifies the verb ('show'), the resource ('submission status'), and the scope ('YOUR submission'). This distinguishes it from sibling tools like get_grades or list_assignments which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to use the `assign_id` from `list_assignments`, providing a clear source for the parameter. It also explains how to interpret the status ('A status other than 'submitted' means it has not been turned in yet'). However, it does not explicitly state when to use this tool versus alternatives, but it is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your upcoming tasks and deadlines (Moodle's "Timeline").
Aggregates assignment due dates, quiz closings, etc., sorted by date.
days is the look-ahead window (default 30). This is the best single
source for "what do I have to do and by when".
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes aggregation and sorting, and parameter behavior, but does not explicitly state that it is a read-only operation or other behavioral traits like access scope (all courses vs. specific). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second explains parameter and adds guidance. Front-loaded, no unnecessary words. Maximally concise for the information needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is nearly complete. Could clarify scope (all courses?) but otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains the 'days' parameter meaning ('look-ahead window') and its default (30). Adds clear value beyond the schema's minimal type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists upcoming tasks and deadlines, aggregated from various sources (assignment due dates, quiz closings), sorted by date. References Moodle's 'Timeline', forming a distinct purpose from siblings like list_assignments or list_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly recommends as 'best single source' for deadlines, but lacks explicit when-not-to-use or alternatives. The guidance is adequate given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assignments with their due dates.
If course_ids is omitted, searches ALL your courses. Returns course,
assignment name, assign_id (for get_submission_status), due date, cutoff
date and max grade.
| Name | Required | Description | Default |
|---|---|---|---|
| course_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: omitting course_ids searches all courses, and it lists the return fields. However, it does not mention rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and efficiently explains parameter behavior and return fields without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies return fields and behavior for a simple list tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining the effect of omitting course_ids and listing return fields, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assignments with their due dates and specifies behavior when course_ids is omitted, distinguishing it from siblings like get_submission_status and get_upcoming_deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, including the effect of omitting course_ids, but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the courses you are enrolled in.
For each: id (use it in the other tools), name, short name, progress (%) and last access date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies that the tool lists only enrolled courses and returns specific fields, but does not disclose potential limitations like pagination, authentication requirements, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences with no extraneous information. The first states the core action, the second lists the return fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple input, the description provides enough context for the agent to use the tool. It explains what courses are returned and what data each course contains, but could mention if results are sorted or filtered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter information is needed. The description still adds value by detailing the output fields (id, name, short name, progress, last access), which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List the courses you are enrolled in', which is a specific verb+resource. It distinguishes from sibling tools like 'get_course_contents' or 'list_assignments' by focusing on enrollment status and providing course-level info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage guidance by noting 'id (use it in the other tools)', hinting that this tool is a precursor to other operations. However, it lacks explicit when-to-use, when-not-to-use, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the downloadable files of a course (PDFs, slides, notebooks, ...).
Use the id from list_courses. Returns, for each file: filename, mimetype,
size, the section/activity it belongs to, and the fileurl to pass to
download_files.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns specific file details and is a read operation, but does not mention potential limitations like file type filtering or authentication requirements. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a purpose: stating the function, providing usage context, and listing returned fields. It is front-loaded and concise with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers all necessary aspects: purpose, prerequisite (list_courses), returned data, and next step (download_files). It is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by indicating the parameter `course_id` should come from list_courses, which is not in the schema. With 0% schema coverage, this compensates well. However, it doesn't describe the parameter's format or constraints beyond the integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists downloadable files of a course, specifies file types (PDFs, slides, notebooks), and lists return fields (filename, mimetype, size, section/activity, fileurl). It differentiates from sibling tools like list_courses and download_files by mentioning the data flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to use the `id` from list_courses and that the returned `fileurl` is for download_files, providing a clear workflow. It does not explicitly state when not to use the tool, but the context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the forums in your courses (includes news/announcements).
If course_ids is omitted, scans all courses. Returns forum_id (for
get_forum_discussions), name, type and description.
| Name | Required | Description | Default |
|---|---|---|---|
| course_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool lists forums and returns specific fields (id, name, type, description). It also explains the parameter behavior. It could explicitly note that it is a read-only operation, but the listing nature implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the main purpose, and the second clarifies the parameter behavior. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is complete: purpose, return fields, parameter behavior. No output schema needed. Could mention relationship to get_forum_discussions, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (course_ids) with no description, and schema coverage is 0%. The description compensates fully by explaining that omitting course_ids scans all courses, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists forums in courses, includes news/announcements, and distinguishes from sibling tools like get_forum_discussions. It specifies the verb 'list', the resource 'forums in your courses', and notes that it returns forum_id, name, type, and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: if course_ids is omitted, it scans all courses. This guides when to provide the parameter. However, it does not explicitly state when not to use this tool or mention alternatives, though the sibling get_forum_discussions is implied as a follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm who you are on Moodle and that the token is valid.
Returns your name, user_id, site name, version and how many web service functions your token may call. Use it to diagnose the connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool returns name, user_id, site name, version, and function count. It implies no destructive actions. This is transparent for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose ('Confirm who you are'), and every word adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema, the description lists the return fields (name, user_id, etc.) and usage context. It fully covers what the agent needs to know to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100% (vacuous). The description does not need to add parameter info. Baseline for 0 parameters is 4, and the description adequately addresses the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Confirm who you are on Moodle and that the token is valid.' It uses a specific verb ('confirm') and identifies the resource (identity/token). Among siblings focused on data retrieval, whoami's purpose for authentication is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use it to diagnose the connection.' This indicates when to use the tool (diagnosis/verification). While it doesn't explicitly state when not to use, the simplicity and lack of alternatives make the guidance clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All 11 tools have clearly distinct purposes: listing resources, fetching details, downloading files, and identity check. No two tools overlap in functionality.
Consistent verb_noun pattern: list_ for collections, get_ for single resource details, download_files for action, and whoami for identity. Mix of get_ and list_ is a sensible and predictable pattern.
11 tools is appropriate for a student-facing Moodle MCP. It covers the essential workflows (courses, assignments, forums, files, grades, deadlines) without being excessive.
The set covers reading and listing well but lacks tools for student actions such as submitting assignments or posting in forums. This is a notable gap for a student assistant tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Notes, kanban tasks, and a capture inbox: read and create Flow data with a personal token.
Unofficial NTNU course data: search, timetables, grades, course info, and exam logistics.
Read-only access to your tabletop campaigns: codex, sessions, and session notes.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tcpassos/moodle-student-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
