Provides tools for interacting with Moodle's REST API, enabling listing courses, retrieving users and enrolled users, fetching grades, SCORM modules, and completion reports.
Click on "Deploy 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 MCP Server show enrolled users in course 3"
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.
Serveur MCP (Model Context Protocol) qui expose des données Moodle (cours, utilisateurs, inscriptions, notes, SCORM, rapports de complétion) sous forme d'outils utilisables par Claude.
Deux modes de transport sont disponibles :
stdio — pour un usage local avec Claude Code ou Claude Desktop.
HTTP (Streamable HTTP) — pour déployer le serveur et l'ajouter comme connecteur personnalisé distant sur claude.ai.
Node.js 20+
Une instance Moodle avec le service web REST activé et un token utilisateur (MOODLE_TOKEN)
Related MCP server: moodle-mcp
npm install
cp .env.example .envRenseigne ensuite .env :
Variable | Obligatoire | Description |
| Oui | URL du endpoint REST Moodle, ex: |
| Oui | Token du web service Moodle |
| Non (mode HTTP uniquement) | Port d'écoute du serveur HTTP (défaut |
| Oui (mode HTTP uniquement) | Token d'accès au serveur HTTP — génère-le avec |
npm run dev # développement (tsx)
npm run build && npm run start # productionDans la config MCP de Claude Code/Desktop, pointe simplement vers node dist/index.js (après npm run build) avec les variables d'environnement MOODLE_URL/MOODLE_TOKEN chargées via .env.
npm run dev:http # développement (tsx)
npm run build && npm run start:http # productionLe serveur écoute sur POST /mcp (port PORT, défaut 3000). Chaque requête doit inclure le token d'accès en paramètre de requête :
https://ton-domaine.com/mcp?token=<MCP_ACCESS_TOKEN>C'est cette URL qu'il faut renseigner dans le champ URL du serveur MCP distant du formulaire "Ajouter un connecteur personnalisé" de claude.ai.
Sans MCP_ACCESS_TOKEN défini, le serveur refuse de démarrer (aucun mode non protégé possible). Une requête sans token, ou avec un token invalide, reçoit une réponse 401. GET/DELETE /mcp renvoient 405 (pas de sessions, le transport est sans état).
Le formulaire de connecteur claude.ai ne permet pas d'envoyer un en-tête HTTP personnalisé, seulement une URL — le token est donc transmis en paramètre de requête plutôt qu'en en-tête Authorization. Tout proxy inverse, CDN, load balancer ou autre infrastructure placée devant ce serveur et qui journalise les URLs complètes des requêtes capturera ce token dans ses logs. Avant un déploiement public :
désactive la journalisation des query strings sur tes proxies, ou redacte-les ;
traite MCP_ACCESS_TOKEN comme un secret critique, au même titre que MOODLE_TOKEN.
Le déploiement effectif (Docker, systemd, reverse proxy, certificat TLS) n'est pas couvert par ce dépôt — c'est une étape à part, propre à ton infrastructure.
Outil | Description |
| Liste les cours disponibles sur Moodle |
| Récupère une liste d'utilisateurs Moodle |
| Liste les utilisateurs inscrits dans un cours |
| Récupère les notes d'un utilisateur dans un cours |
| Liste les modules SCORM disponibles dans un ou plusieurs cours |
| Génère un rapport de complétion pour un module SCORM |
| Génère un rapport de complétion pour un cours |
src/moodleClient.ts — client HTTP vers l'API REST Moodle (avec cache).
src/tools/*.ts — définition des outils MCP (schéma Zod + handler).
src/server.ts — construction du serveur MCP (liste des outils, handlers tools/list/tools/call), partagée par les deux transports.
src/index.ts — point d'entrée stdio.
src/httpServer.ts — point d'entrée HTTP (Express, transport sans état, authentification par token).
Génère un rapport de complétion pour un cours.
| Name | Required | Description | Default |
|---|---|---|---|
| courseid | Yes | ID du cours |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It merely states the tool 'generates a completion report' without disclosing whether it is read-only, what permissions are required, or any side effects. This is insufficient for an agent to understand the tool's 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 extremely concise with one sentence. While there is no waste, it lacks necessary details (e.g., report contents, output format) that would make it more valuable. It is adequately concise but borderline under-specified.
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 has one parameter, no output schema, and no annotations, the description is too minimal. It does not explain what the completion report includes, how to interpret it, or any access requirements. The presence of a similar sibling tool ('moodle_get_scorm_completion_report') makes the lack of differentiation a gap.
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 100% for the single parameter 'courseid', which is described as 'ID du cours' in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Génère un rapport de complétion pour un cours' clearly states the tool generates a completion report for a course. It uses a specific verb and resource, but does not explicitly distinguish from the sibling tool 'moodle_get_scorm_completion_report', which also generates completion reports but for SCORM activities.
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 no guidance on when to use this tool versus alternatives like moodle_get_scorm_completion_report. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les cours disponibles sur Moodle.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'list'. There is no mention of read-only nature, authentication requirements, pagination, or what happens when the list is empty.
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 a single sentence, which is concise, but it lacks structure and front-loaded key information. It could be improved by adding a brief explanation of parameters or usage context without becoming verbose.
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 nested parameter, lack of output schema, and many sibling tools, the description is severely incomplete. It does not explain the return value, filtering capabilities, or how it differs from more specific get tools like moodle_get_scorms_by_courses.
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% and the description does not explain the 'options' nested object, its properties 'ids' and 'categoryid', or how they affect the list. This leaves the agent with no semantic help beyond the schema structure.
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 'Liste les cours disponibles sur Moodle' clearly states the verb (list) and the resource (courses), distinguishing it from sibling tools like moodle_get_users or moodle_get_grade_items which target different entities.
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 no guidance on when to use this tool versus alternatives. For example, it does not indicate that this tool lists all courses without filtering, while sibling tools may filter by user or grade context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les utilisateurs inscrits dans un cours.
| Name | Required | Description | Default |
|---|---|---|---|
| courseid | Yes | ID du cours |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the basic operation, lacking details on pagination, permissions, or side effects. The implication of a read operation is present but not explicit.
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 a single sentence, but it is too minimal. While concise, it lacks helpful context that could be included without being verbose.
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?
Despite the low complexity (1 parameter, no output schema), the description fails to mention the return format or any other details. A simple addendum about what the result contains would improve completeness.
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 100%, and the description does not add extra meaning beyond what the schema provides for 'courseid'. Baseline 3 is appropriate as no additional value is added.
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 (list) and the resource (users enrolled in a course). It distinguishes from sibling tools like moodle_get_users (all users) and moodle_get_courses (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?
No guidance is provided on when to use this tool versus alternatives. The description only states the function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les notes d'un utilisateur dans un cours.
| Name | Required | Description | Default |
|---|---|---|---|
| userid | Yes | ID de l'utilisateur | |
| courseid | Yes | ID du cours |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or rate limits. The tool's effect is implied but not explicitly stated.
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 a single concise sentence with no extraneous information. It is front-loaded and efficiently communicates the core purpose.
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 (2 params) and complete schema coverage, the description provides adequate context for the tool's primary function. However, it lacks details on output format, pagination, or error behavior, which could be important for an agent.
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 100%, with both parameters (userid, courseid) explained in the schema. The tool description adds no additional semantics beyond the schema, meeting the baseline for high 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 retrieves grades for a user in a course, using a specific verb and resource. It distinguishes from siblings like moodle_get_courses and moodle_get_users, which deal with different entities.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Génère un rapport de complétion pour un module SCORM.
| Name | Required | Description | Default |
|---|---|---|---|
| scormid | Yes | ID du module SCORM | |
| courseid | No | ID du cours (optionnel, pour filtrer les utilisateurs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'generates' a report but does not disclose permissions, side effects, or whether it is read-only. Since no annotations are provided, the description should compensate with behavioral details, which it lacks.
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 a single sentence, which is concise, but it omits important information. It earns its place by stating the purpose, but additional context would improve it.
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?
Without an output schema, the description should explain what the report contains (e.g., fields, format). It does not, making it incomplete for a report-generation 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?
Both parameters are fully described in the schema (100% coverage), so the description adds no extra meaning. The baseline of 3 is appropriate.
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 specifies that it generates a completion report for a SCORM module, which is a clear verb-resource pairing. However, it does not differentiate from the sibling tool 'moodle_get_completion_report', which likely serves a similar role for other activities.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., moodle_get_completion_report). The description only states what it does, without usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les modules SCORM disponibles dans un ou plusieurs cours.
| Name | Required | Description | Default |
|---|---|---|---|
| courseids | Yes | Liste des IDs de cours |
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 only states the basic function and does not disclose read-only nature, permission requirements, or any side effects. Minimal behavioral disclosure.
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?
A single sentence that conveys the core purpose without extraneous words. It is front-loaded and appropriately sized for a simple listing tool.
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?
No output schema exists, so the description should ideally explain return format or structure. It does not, and no annotations compensate. For a tool with one parameter and no complexity, the description is minimally adequate but lacks completeness regarding what data is returned.
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 100% for the only parameter (courseids). The description adds no additional meaning beyond the schema's parameter description. Baseline score of 3 applies as schema already documents parameter adequately.
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 available SCORM modules in one or more courses. It uses a specific verb ('Liste') and resource ('modules SCORM'), and distinguishes from sibling tools like moodle_get_scorm_completion_report and moodle_get_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?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, expected context, or when not to use. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère une liste d'utilisateurs Moodle.
| Name | Required | Description | Default |
|---|---|---|---|
| criteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention any aspects like pagination, rate limits, or whether it returns all users when no criteria are provided. Only the basic retrieval action is stated.
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 a single short sentence, which is concise but lacks necessary detail. It does not front-load critical information like parameter usage or output expectations, making it under-specified.
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 incomplete parameter documentation, the description leaves significant gaps. It does not clarify what the tool returns, how filtering works, or any constraints, making it insufficient for reliable agent invocation.
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 input schema has 100% missing description coverage (0% described), and the tool description does not explain the 'criteria' parameter at all. There is no mention that it expects an array of objects with 'key' and 'value', nor what each key (id, username, email) represents.
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 states a specific verb ('Récupère' - retrieves) and resource ('liste d'utilisateurs Moodle' - list of Moodle users), making the purpose clear. However, it does not differentiate from sibling tools like moodle_get_enrolled_users, which also retrieves users.
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?
There is no guidance on when to use this tool versus alternatives such as moodle_get_enrolled_users or moodle_get_courses. No context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.3moodle_get_completion_reportmoodle_get_coursesmoodle_get_enrolled_usersmoodle_get_grade_itemsmoodle_get_scorm_completion_reportmoodle_get_scorms_by_coursesmoodle_get_usersScored across 7 tools
Each tool targets a distinct entity or action: courses, users, enrolled users, grades, SCORM modules, SCORM completion, and course completion. No significant overlap.
All tool names follow a consistent 'moodle_get_<object>' pattern using snake_case, making them predictable and easy to understand.
Seven tools provide a focused set of operations for a Moodle integration, covering core reporting needs without excessive or insufficient granularity.
The tools are limited to retrieval operations, missing create/update/delete functionality. Key areas like assignments, forums, or quizzes are absent, indicating notable gaps for a full Moodle integration.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Model Context Protocol server for Studex tools, notifications, and profile integrations
