The moodle-mcp server is an MCP adapter enabling AI agents to comprehensively manage Moodle LMS instances through idempotent Web Service calls. Key capabilities include:
Course & Section Management: Create, update, duplicate, archive, and list courses; retrieve full course context (sections, modules, enrollment stats); create, update, hide/show, and reorder sections.
Content Publishing: Publish markdown-based lessons (FichaClase) as Moodle sections with a preview-and-confirm workflow (hidden by default, teacher reviews via preview_url before release). All write operations are idempotent — republishing updates in place, never duplicates.
Quiz & Assessment: Publish quizzes (FichaExamen), configure them, and import questions via GIFT format.
Student & Enrollment Management: List students, enroll/unenroll via CSV, create groups, assign users to groups, change roles, and reset passwords.
Gradebook & Performance: Retrieve grades, course completion status, quiz attempts, and assignment submissions; perform manual grading.
Communication & Calendar: Send Moodle messages, create forum announcements, retrieve course logs and site info; create, list, update, and delete calendar events.
Badges: List badges earned by a user (read-only).
Raw Web Services (ws_raw): Call any Moodle Web Services function directly as an escape hatch when no high-level tool applies.
Note: Full functionality for content publishing and imports requires the companion PHP plugin (
local_italiciamcp) installed on the Moodle instance.
Provides tools for publishing and managing pedagogical content in Moodle courses via Web Services, including creating/updating sections, pages, resources, and activities with guaranteed idempotency.
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-mcp publish a preview of lesson /home/fichas/spanish/a1/u4/l2.md to course 15"
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.
Model Context Protocol (MCP) server for Moodle. Lets AI agents publish and manage pedagogical content — lessons, resources, activities — in Moodle via Web Services with guaranteed idempotency.
Status: wrapper v0.5.2 + plugin v0.5.0 — operate Moodle at ~80% from an LLM agent. (v0.5.0 release adds add_questions_gift contract fix; see CHANGELOG.)
moodle-mcp is a stdio-based MCP server that exposes 40 high-level facades plus one low-level ws_raw escape hatch to run almost the entire teaching workflow of a Moodle course from an AI agent: courses, sections, content (pages, urls, assignments, forums, videos), quizzes (with GIFT import), students (enrolment CSV, groups, roles, passwords), gradebook, messaging, calendar, and badges. Every write is upsert-by-idnumber, so republishing the same Ficha never creates duplicates.
Primary consumer: Claude Desktop driving the Italicia language-teaching workflow. But it is a generic open-source adapter — any MCP-capable agent + any Moodle 4.x/5.x instance with Web Services enabled can use it.
Plugin companion required for full feature set. Upsert of
page,url,assign,quiz, file uploads and GIFT imports go through the small PHP pluginlocal_italiciamcpthat ships alongside this repo inplugin-companion/. Install it once (as "Complemento local" in the Moodle admin UI) and expose its functions to the external service the token belongs to. Without the plugin, the read-only facades (list students, grades, calendar, site info) andws_rawstill work.
Related MCP server: Moodle MCP Server
ws_raw)Grouped by domain family. Each family lives under src/tools/<family>/.
crear_curso · actualizar_curso · duplicar_curso · archivar_curso · listar_mis_cursos · obtener_contexto_curso
crear_seccion · actualizar_seccion · ocultar_seccion · liberar_seccion · reordenar_secciones
publicar_ficha_clase · publicar_preview · confirmar_preview · generate_video (Gemini Veo)
publicar_ficha_examen (one-shot) · configurar_quiz · importar_gift
listar_alumnos · matricular_csv · dar_baja · crear_grupo · asignar_a_grupo · cambiar_rol · reset_password
obtener_calificaciones · obtener_completion · obtener_intentos_quiz · obtener_entregas_assign · calificar_manualmente
enviar_mensaje_moodle · crear_anuncio_foro · obtener_logs_curso · obtener_info_sitio
crear_evento_calendario · listar_eventos_calendario · actualizar_evento · eliminar_evento
listar_badges_usuario
ws_raw — call any Moodle WS function directly when no facade covers the case.
duplicar_seccion, crear_banco_preguntas, editar_preguntas_banco, liberar_quiz, ocultar_quiz, otorgar_badge.
# Via npx (recommended for Claude Desktop)
npx -y @nahuelalbornoz/moodle-mcp
# Or install globally
npm install -g @nahuelalbornoz/moodle-mcpRequires Node.js 20 or higher.
Variable | Required | Default | Description |
| yes | — | Full HTTPS URL of the Moodle instance. |
| yes | — | Web Services token with edit permissions. |
| no |
| Per-request timeout. |
| no |
| Retry attempts on transient failures. |
| no |
| Token-bucket rate limit. |
| no |
|
|
| no |
| Allow |
Add to claude_desktop_config.json (see examples/setup-claude-desktop.md for the exact path per OS):
{
"mcpServers": {
"moodle": {
"command": "npx",
"args": ["-y", "moodle-mcp"],
"env": {
"MOODLE_URL": "https://your-moodle.example.com",
"MOODLE_WS_TOKEN": "your-ws-token"
}
}
}
}Restart Claude Desktop. The five tools above should now be available to the agent.
// tool call
{
"name": "obtener_contexto_curso",
"arguments": { "course_id": 42, "incluir_ultimas_clases": 5 }
}Response (abridged):
{
"course": { "id": 42, "fullname": "Italiano A1", "shortname": "ITA-A1", "format": "topics", "startdate": 1700000000 },
"secciones": [{ "id": 100, "name": "Unidad 3", "section": 3, "visible": true, "modules_count": 6 }],
"ultimas_clases": [{ "seccion_id": 100, "seccion_name": "Unidad 3", "ficha_idnumber": "mcp:a9993e364706816aba3e2571" }],
"matriculados": { "total": 18, "docentes": 1, "alumnos": 17 }
}{
"name": "publicar_preview",
"arguments": {
"ficha_path": "/home/alicia/fichas/italiano/a1-2026/u3/c5.md",
"course_id": 42
}
}Response includes preview_url Alicia can open to review. Once approved:
{
"name": "confirmar_preview",
"arguments": { "seccion_id": 100, "recursos_ids": [501, 502, 503] }
}{
"name": "ws_raw",
"arguments": {
"function_name": "core_webservice_get_site_info",
"params": {}
}
}Response:
{ "data": { "sitename": "Aula Italicia", "release": "5.0.2+", ... } }Every resource created by this MCP carries a stable idnumber of the form:
mcp:<first 24 chars of sha1(ficha.id + "|" + component_id)>Republishing the same Ficha finds the existing resource by idnumber and updates it in place. Nothing gets duplicated. Safe to retry anywhere, anytime.
v0.1 is honest about its capability boundary. It reliably:
Looks up a course, its sections and modules.
Finds "owned" resources by the mcp: idnumber prefix.
Updates visibility of pre-existing modules (the preview → confirm workflow).
Surfaces structured Moodle errors with stable code fields.
Never logs tokens, never propagates stack traces.
v0.1 does not yet:
Upload asset files via multipart to the Moodle draft file area. Calls planned for asset upload are reported back in advertencias — seed them manually the first time.
Create brand-new sections or modules through Web Services. Where a module does not exist yet, the tool returns status "missing" plus an advertencia. Installing local_wsmanagesections (or equivalent) and wiring those endpoints is v0.2 work.
Both gaps are driven out by the integration suite in tests/integration/ when run against a real Moodle docker.
git clone https://github.com/marcosnahuel/moodle-mcp
cd moodle-mcp
npm install
npm run typecheck # tsc --noEmit
npm test # vitest unit suite
npm run test:coverage # with v8 coverage (≥80% enforced)
npm run build # tsup → dist/
# Integration — requires docker
docker compose -f tests/integration/docker-compose.test.yml up -d
export MOODLE_TEST_URL=http://localhost:8081
export MOODLE_TEST_TOKEN=<generate in Moodle admin>
export MOODLE_TEST_COURSE=<course id>
npm run test:integration
docker compose -f tests/integration/docker-compose.test.yml down -vThe token is never logged. Tokens appearing in any field of any log record are replaced with ***.
URLs in error messages are likewise redacted.
HTTPS is required unless MOODLE_ALLOW_INSECURE=true (dev-only).
The MCP only talks to Moodle via Web Services REST. No cookie auth, no web scraping, no direct DB access.
See CONTRIBUTING.md for issue, PR and commit conventions.
By participating in this project you agree to abide by the CODE_OF_CONDUCT.md.
MIT © 2026 Italicia — see LICENSE.
Make a previewed section (and optionally a subset of its modules) visible to students. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| seccion_id | Yes | ||
| recursos_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses idempotency (a key behavioral trait) and the optional nature of 'recursos_ids'. However, it misses critical details like required permissions, whether changes are reversible, or potential side effects on student access, which are important for a visibility-changing 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 extremely concise—one sentence plus a note on idempotency—with zero wasted words. It front-loads the core action ('Make visible') and efficiently covers key aspects. Every element earns its place, making it highly readable and focused.
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 annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on permissions, error conditions, return values, or how visibility changes affect students. For a tool that modifies student access, this leaves significant gaps in understanding its full impact and usage 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'seccion_id' and 'recursos_ids' (modules subset) but provides no semantic context—e.g., what a 'seccion_id' represents or how 'recursos_ids' relate to modules. This adds minimal value beyond the bare schema, failing to adequately address the coverage gap.
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 verb ('Make visible') and resource ('previewed section'), specifying the action of revealing content to students. It distinguishes from siblings like 'publicar_preview' by focusing on confirming visibility rather than initial publishing. However, it doesn't explicitly differentiate from all siblings, keeping it at 4 instead of 5.
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 implies usage when a section is previewed and needs to be made visible, with optional module selection via 'recursos_ids'. It mentions idempotency, suggesting safe repeated use. However, it lacks explicit when-not-to-use guidance or clear alternatives among siblings like 'publicar_ficha_clase', leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a compact radiograph of a Moodle course: metadata, sections with module counts, recent MCP-published lessons, and enrolment counts (teachers vs students). Call this before publishing a Ficha so the agent knows where it fits.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| incluir_ultimas_clases | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a read-only operation ('returns') and specifies the scope of data returned, which is helpful. However, it doesn't mention potential limitations like permissions needed, error conditions, or rate limits, leaving some behavioral aspects unclear for a tool with no annotation coverage.
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 front-loaded with the core purpose in the first sentence and follows with a clear usage guideline. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
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 moderate complexity (2 parameters, no output schema, no annotations), the description provides good context on purpose and usage. It explains what the tool returns and when to use it, which is sufficient for a read-only tool. However, without an output schema or annotations, it could benefit from more details on return format or error handling, slightly limiting 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?
With 0% schema description coverage, the description must compensate for undocumented parameters. It explains the purpose of the tool's output but doesn't directly describe the parameters. However, the context ('compact radiograph of a Moodle course') and the parameter names ('course_id', 'incluir_ultimas_clases') are intuitive, and the description implies the tool fetches course-specific data, adding some semantic value. Since there are only 2 parameters, this partial compensation earns a 4.
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 with specific verbs ('returns a compact radiograph') and resources ('Moodle course'), detailing exactly what information is provided (metadata, sections with module counts, recent MCP-published lessons, enrolment counts). It distinguishes this tool from siblings by explaining its preparatory role for publishing a Ficha, making it highly specific and differentiated.
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 states when to use this tool ('Call this before publishing a Ficha so the agent knows where it fits'), providing clear context and purpose. It distinguishes it from sibling tools by positioning it as a preparatory step for publishing operations, offering specific guidance on its role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a FichaClase markdown file as a Moodle section with component modules. Idempotent: republishing the same Ficha updates in place, never duplicates. Default modo is oculto (hidden). Use publicar_preview + confirmar_preview for the preview workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| ficha_path | Yes | ||
| course_id | Yes | ||
| section_id | No | ||
| modo | No | oculto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses idempotency ('republishing the same Ficha updates in place, never duplicates'), default behavior ('Default modo is `oculto`'), and workflow relationships. It doesn't mention error conditions or permissions, leaving some gaps.
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?
Three sentences, each essential: first states purpose, second covers idempotency and default, third provides workflow guidance. No wasted words, front-loaded with core functionality.
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 4-parameter mutation tool with no annotations or output schema, the description is strong but not fully complete: it explains key behaviors (idempotency, defaults, workflow) but lacks details on error handling, response format, or side effects. Given the complexity, it's above minimum viable but could be more comprehensive.
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 compensate. It explains the 'modo' parameter's default value and meaning ('oculto' means hidden), and implies 'ficha_path' refers to a markdown file. It doesn't detail 'course_id' or 'section_id' semantics, but the tool name and context provide some inference.
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 verb ('Publish') and resource ('a FichaClase markdown file as a Moodle section with component modules'), distinguishing it from siblings like 'publicar_preview' (preview workflow) and 'confirmar_preview' (confirmation step). It specifies the exact transformation from input to output.
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 explicitly provides when-to-use guidance: 'Use `publicar_preview` + `confirmar_preview` for the preview workflow' distinguishes this as the final publishing tool versus preview alternatives. It also mentions the default mode ('oculto') as a usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a FichaClase in hidden preview mode. Returns the same shape as publicar_ficha_clase plus preview_url the teacher can open to review. Students will not see anything until confirmar_preview is called.
| Name | Required | Description | Default |
|---|---|---|---|
| ficha_path | Yes | ||
| course_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 of behavioral disclosure. It effectively describes key behaviors: it's a mutation tool (implied by 'Publish'), returns a specific shape (similar to 'publicar_ficha_clase' plus a 'preview_url'), and has side effects (creating a hidden preview accessible only to teachers). However, it lacks details on permissions, error handling, or rate limits, which are important for a mutation tool without annotations.
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 highly concise and well-structured in two sentences. The first sentence states the core action and return value, while the second clarifies the preview state and next steps. Every word earns its place, with no redundancy or fluff, making it easy to parse and understand quickly.
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 complexity (a mutation with preview functionality), no annotations, no output schema, and low schema coverage, the description does a good job covering the core behavior and workflow. It explains the preview mode, return shape, and relationship to 'confirmar_preview'. However, it misses details like error cases or the exact return structure, which could be important for agent invocation without an output schema.
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 2 parameters with 0% description coverage, so the schema provides no semantic information. The description does not explain what 'ficha_path' or 'course_id' represent, their formats, or constraints beyond the schema's basic types. It adds no parameter-specific meaning, but since there are only 2 parameters, the baseline is slightly higher than minimal, though it fails to compensate for the lack of schema descriptions.
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 specific action ('Publish a FichaClase in hidden preview mode') and resource ('FichaClase'), distinguishing it from sibling tools like 'publicar_ficha_clase' (which likely publishes publicly) and 'confirmar_preview' (which confirms the preview). It explicitly mentions the preview mode and the target audience (teacher vs. students), making the purpose distinct and well-defined.
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 explicit guidance on when to use this tool: for publishing in 'hidden preview mode' that teachers can review, and it specifies an alternative ('confirmar_preview') for making it visible to students. It also implies when not to use it (e.g., for direct student access or final publication without preview), offering clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape hatch: call any Moodle Web Services function with arbitrary parameters. Returns { data } on success, structured meta.code + isError: true on failure. Prefer high-level facades when they cover your use case.
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It discloses behavioral traits: success returns '{ data }' and failures return structured 'meta.code' + 'isError: true'. It also implies this is a low-level, potentially risky operation ('escape hatch'), though it doesn't detail authentication needs, rate limits, or specific error conditions.
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 appropriately sized and front-loaded. The first sentence states the core purpose, the second explains return behavior, and the third provides usage guidance. Every sentence adds value with zero waste, making it efficient and well-structured.
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 complexity (low-level API access with arbitrary parameters), no annotations, no output schema, and 0% schema coverage, the description is reasonably complete. It covers purpose, behavior, and usage guidelines. However, it lacks details on authentication, error specifics, or parameter examples that would be helpful for such a flexible 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 compensate. It adds meaning by explaining that 'function_name' corresponds to 'any Moodle Web Services function' and 'params' are 'arbitrary parameters'. However, it doesn't provide examples, format details, or constraints beyond what the schema's pattern hint suggests. This partial compensation earns a baseline score.
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: 'call any Moodle Web Services function with arbitrary parameters.' It specifies the verb ('call'), resource ('Moodle Web Services function'), and scope ('any' with 'arbitrary parameters'). However, it doesn't explicitly differentiate from sibling tools, which appear to be more specific Moodle operations.
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 explicit usage guidance: 'Prefer high-level facades when they cover your use case.' This directly tells the agent when to use this tool (as an 'escape hatch' when other tools don't cover the need) versus when to use alternatives (the 'high-level facades'). The 'escape hatch' framing further clarifies this is a fallback option.
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. Dates show when Glama detected each change.
v0.1.0confirmar_previewobtener_contexto_cursopublicar_ficha_clasepublicar_previewws_rawEach tool has a distinct and non-overlapping purpose: obtener_contexto_curso provides course metadata, publicar_ficha_clase publishes a class file, publicar_preview publishes in hidden mode, confirmar_preview makes previews visible, and ws_raw serves as a low-level escape hatch. The descriptions clearly differentiate their roles, with no ambiguity in selection.
Naming is inconsistent with mixed conventions: obtener_contexto_curso and publicar_ficha_clase use Spanish verbs with snake_case, while confirmar_preview and publicar_preview mix Spanish verbs with English terms, and ws_raw is an English abbreviation. There is no uniform pattern across the tool set, making it chaotic and harder to predict.
With 5 tools, the count is well-scoped for the server's purpose of managing Moodle courses. Each tool serves a specific function in the publishing workflow (e.g., preview, confirmation, raw access), and none feel redundant or missing for the apparent scope, making the set appropriately sized.
The tool set covers core workflows for publishing and managing Moodle course content, including metadata retrieval, publishing with preview options, and confirmation. A minor gap exists in lacking direct update or deletion tools for existing content, but agents can work around this using the idempotent publishing tools and the ws_raw escape hatch for other operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your Moodle to AI assistants: courses, content, grading and reports from the chat.
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
AI-powered LMS course builder: 89 tools, 17 skills, SCORM/xAPI export, agentic UI
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarcosNahuel/moodle-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
