moodle-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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 Consistency2/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 5 of 5 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![moodle-mcp MCP server](https://glama.ai/mcp/servers/MarcosNahuel/moodle-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MarcosNahuel/moodle-mcp)

Score Badge

Copy to your README.md:

[![moodle-mcp MCP server](https://glama.ai/mcp/servers/MarcosNahuel/moodle-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MarcosNahuel/moodle-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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