Moodle Downloader MCP

by stojandev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
The authentication tools (moodle_setup, moodle_probe, moodle_config, moodle_whoami, moodle_init) have overlapping responsibilities around setup and token verification, which could cause confusion. Course and wiki tools are clearly distinct, but the auth cluster blurs boundaries.
Naming Consistency2/5
Tool names mix verb-first patterns (moodle_setup, moodle_sync_all) with noun-first patterns (moodle_courses_list, moodle_wiki_scaffold). Some names use nouns as actions (moodle_course_tree, moodle_wiki_status), breaking a consistent verb_noun convention.
Tool Count5/5
With 13 tools, the server is well-scoped for its purpose of downloading Moodle courses and managing wiki scaffolding. Each tool addresses a distinct step in the workflow, and the count feels neither sparse nor bloated.
Completeness4/5
Core workflows are covered: authentication, course listing, downloading, syncing, and wiki generation. Minor gaps exist, such as no explicit logout or local download management tool, but agents can likely work around these.
Average 3.5/5 across 13 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only notes that the operation is long-running, but omits effects (e.g., what syncing does, whether it downloads content, modifies state, requires authentication, or is reversible). This is insufficient for a sync operation.
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: two short sentences ('Sync all enrolled courses. Long-running.') with no wasted words. It is well-structured and easy to parse.
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?
For a long-running sync operation with no annotations and undocumented parameters, the description is incomplete. It lacks context about what syncing involves, potential side effects, duration expectations, or how to handle the operation. The presence of an output schema does not compensate for the missing behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters ('out', 'site') with 0% description coverage and no descriptions in the schema. The description adds no meaning to either parameter, leaving the agent without any understanding of how to use them.
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 states a specific action ('Sync') and resource ('all enrolled courses'), clearly distinguishing from a single-course sync tool like moodle_course_sync. However, it does not explicitly differentiate from siblings or elaborate on what 'sync' entails, though the scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The phrase 'Long-running' hints that it is heavy, but there is no explicit when-to-use, prerequisites, or exclusions. Sibling tools like moodle_course_sync are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states that the tool verifies a saved token and returns user/site info, which suggests a read-only operation. However, it does not address edge cases like missing/expired tokens, network dependencies, or whether the 'site' parameter modifies any stored state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff and front-loaded action. It is under-specified for what it needs to convey, but from a pure conciseness standpoint it is appropriately brief.
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?
The tool has an output schema, so return format is covered, but the description lacks essential context about the optional 'site' parameter, usage scenarios, and fallback behavior. Given the zero annotations and minimal description, the tool is not fully specified for an agent to use correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter ('site') with 0% schema description coverage, and the description does not mention this parameter at all. The description fails to explain what 'site' is for, what values it accepts, or its effect when omitted (default null).
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 action ('Verify saved Moodle token') and the expected output ('return current user/site info'). It distinguishes itself from sibling tools like moodle_courses_list and moodle_setup by focusing on authentication status and current identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like moodle_probe or moodle_init. It implies usage for checking saved token validity, but does not state exclusions or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states that the tool 'shows' status, implying a read-only operation, but does not explain what 'ready' vs 'pending' means, whether it requires a local setup, or any other side effects or dependencies. No annotations exist to compensate.
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 a single concise sentence, front-loaded with the core action and resource. Every word earns its place, with no redundant information or filler.
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 the tool has 3 optional parameters, no annotations, and exists within a large sibling set, the one-sentence description is insufficient. It lacks parameter explanations, usage context, and behavioral details. The presence of an output schema mitigates return value documentation, but the description still fails to cover essential aspects for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does not explain the purpose of parameters like 'out', 'course_id', or 'course_dir'. The only indirect connection is 'local course', but no explicit mapping is provided. The parameter names offer some inference, but the description adds no semantic value.
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 function with a specific verb ('Show') and resource ('wiki cards'), and distinguishes ready vs pending states. It is unambiguous and differentiates from sibling tools like moodle_wiki_scaffold and moodle_wiki_rebuild_index, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives. The description only describes what it does without mentioning conditions, prerequisites, or exclusions. The context implies it's for checking wiki status, but there is no explicit 'when to use' or 'when not to use' information.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the key scope that only 'enrolled' courses are returned, which is a useful behavioral constraint, but it doesn't elaborate on other behaviors like pagination, ordering, or error handling. Given the output schema exists, some structure is already covered.
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 a single concise sentence that directly states the action, resource, and output fields, with no wasted words or redundancy. It is efficiently structured and front-loaded.
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?
Although the tool is simple and has an output schema, the description omits any explanation of the 'site' parameter, provides no usage context, and doesn't indicate how this tool fits with its siblings. This leaves a significant completeness gap for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'site' has zero schema coverage (no description in the schema) and the description does not mention it at all. This leaves the parameter's purpose completely unclear, and the description fails to compensate for the lack of schema documentation.
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 uses a specific verb ('List') with a clear resource ('enrolled Moodle courses') and even specifies the return fields (id, shortname, fullname), making the tool's purpose immediately understandable. This clearly differentiates it from sibling tools like moodle_course_tree or moodle_course_download, which have different actions or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any mention of prerequisites or context. It simply states the action without any usage direction, leaving the agent to infer when to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Rebuild' implies overwriting the existing index, but side effects like destructive replacement, error conditions on incomplete frontmatter, or return behavior are not disclosed.
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?
A single clear sentence that is front-loaded with the action verb. No filler or redundant wording; it earns its place despite being sparse.
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?
The core action and source are clear, but the description omits parameter semantics and usage context for three optional parameters. With no annotations and no parameter documentation, the tool is under-specified for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of 'out', 'course_id', or 'course_dir'. The description fails to compensate for the schema's lack of parameter documentation, leaving the agent without any guidance on how to supply arguments.
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?
Description uses specific verb 'Rebuild' and names the exact resource '_wiki/INDEX.md' and data source 'filled card frontmatter'. This clearly distinguishes it from sibling tools like wiki_scaffold or wiki_status.
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 phrase 'from filled card frontmatter' implies the tool should be used after cards have been filled, but there is no explicit guidance on when to use it versus alternatives. No exclusions or alternative recommendations are provided.
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?
Annotations are absent, so the description must convey behavioral traits. 'Show' clearly implies a read-only operation, but the description does not mention prerequisites, potential errors, or side effects, leaving some ambiguity. Despite this, it is not misleading and adequately signals a safe retrieval.
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 a single, front-loaded sentence that immediately conveys the action and object. There is no redundant or extraneous text, making it optimally concise.
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 simple nature and the presence of an output schema, the description covers the core purpose. However, the unexplained 'site' parameter and lack of any error-condition context mean it is not fully complete, though adequate for basic usage.
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?
With schema description coverage at 0%, the description must compensate. It clarifies course_id as the target identifier, but provides no explanation for the optional 'site' parameter, leaving a gap in understanding for multi-site setups. This partial compensation is insufficient for full parameter clarity.
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 states a specific verb ('Show') and resource ('sections and modules with file counts') for a given course id, making its function clear. It distinguishes from sibling tools like course_download or courses_list by focusing on the structural view of one course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to prefer this tool over alternatives such as moodle_course_download or moodle_course_sync. It lacks any exclusions or context on typical use cases, offering only a bare functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only mentions the action 'Create/update' without explaining side effects (e.g., whether existing stubs are overwritten), prerequisites beyond a downloaded course, or what a wiki stub is. This is insufficient for a mutation 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 a single, front-loaded sentence with no redundant phrases. Every word earns its place, making it highly concise.
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?
For a tool with 3 optional parameters, no schema descriptions, and no annotations, this description is too sparse. It fails to explain what wiki stubs are, how they are created/updated, and the purpose of the 'out' parameter. While an output schema exists, it does not compensate for the lack of essential 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 'by path or course_id' which maps to course_dir and course_id, but the 'out' parameter is left unexplained. Thus it partially covers the parameters but misses one, providing inadequate semantics for a tool with zero schema help.
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 action ('Create/update _wiki stubs') and its target resource (downloaded course, identified by path or course_id). This specific verb+resource combination distinguishes it from sibling tools like moodle_wiki_status and moodle_wiki_rebuild_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it operates on a downloaded course, so the course must be downloaded first. This gives a clear prerequisite but does not explicitly mention alternatives or when not to use the tool, falling short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states 'No credentials required' but does not explicitly confirm that the tool is read-only or has no side effects. The verb 'Check' implies observation, but this is not explicit enough for full transparency.
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 exceptionally concise: two sentences, front-loaded with the core purpose, and every word adds value. 'No credentials required' is a useful addition without unnecessary detail.
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?
The tool is simple and has an output schema, so return values are covered. The description captures the essential purpose and credential requirement. It lacks explicit when-to-use guidance, but given the tool's low complexity and output schema, this is adequate.
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 has 0% description coverage, so the description must compensate. It adds meaning by clarifying that 'url' is a 'Moodle base URL' and that the 'service' relates to 'Mobile token login'. However, it does not explain parameter formats, acceptable values, or how the default service is used.
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 uses the specific verb 'Check' and clearly identifies the resource (Moodle base URL) and what is being checked (availability of Mobile token login). This distinguishes it from sibling tools like moodle_setup or moodle_courses_list, which perform different operations.
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?
Usage is implied as a preliminary connectivity/login-availability check before using other Moodle tools, but the description does not explicitly state when to use it vs. alternatives or provide exclusions. 'No credentials required' offers some context, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It describes providing setup schema and auth status but does not mention potential side effects, permissions, or whether it is read-only. The caution about username formats is user guidance, not a disclosure of tool behavior.
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, delivering purpose, usage guidance, and a caution in three short clauses. It is front-loaded and every sentence earns its place.
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 has no parameters and an output schema exists (so return values are covered), the description adequately covers what the tool does and when to use it. It could mention whether the tool has side effects, but the simplicity of the zero-parameter setup reduces the need.
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?
The tool has zero parameters, so there is nothing to document beyond the empty schema. Per the baseline for no parameters, a score of 4 is appropriate; the description does not need to add parameter information.
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 it provides a universal setup schema and auth status for any Moodle school, positioning it as a first-step tool. It distinguishes from siblings by emphasizing 'universal' and 'call first,' though it lacks an explicit action verb like 'retrieve' or 'initialize.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call first when unauthenticated' explicitly specifies when to invoke the tool, and 'Never invent username formats' indicates users should rely on this tool's data. However, it does not name alternative tools or explicitly state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a key behavior: 'skip unchanged files by size', indicating an incremental sync that avoids redundant work. However, it does not disclose potential side effects (e.g., overwriting local files, requiring network access) or the broader sync behavior beyond skipping unchanged files.
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 only two sentences, front-loaded with the main action and a parenthetical detail, followed by a precise usage recommendation. Every word earns its place with no filler or redundancy.
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 simple sync tool, the description captures the core functionality, the incremental behavior, and a specific use case. An output schema exists, so return values need not be described. It does not mention prerequisites or side effects, but given the tool's apparent simplicity and the presence of an output schema, it is reasonably complete.
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?
The schema description coverage is 0%, and the description adds no explicit parameter explanations. It implicitly references 'one course' which aligns with the required course_id, but gives no meaning for the optional parameters 'out' and 'site'. The description does not compensate for the lack of schema info.
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 a specific verb and resource: 'Incremental sync one course' (sync action on a course), and specifies the distinguishing feature 'skip unchanged files by size'. It also gives a use case, 'repair incomplete downloads', which differentiates it from sibling tools like moodle_course_download and moodle_sync_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use context: 'Use this to repair incomplete downloads'. It does not explicitly mention alternatives or when-not-to-use, but the stated purpose gives meaningful guidance on when this tool is appropriate, setting it apart from generic downloads or full sync.
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. It does disclose that tokens are redacted, which is a valuable behavioral detail. However, it does not state whether any side effects or prerequisites exist (e.g., requires a valid config), leaving some uncertainty about behavior.
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 a single, well-structured sentence that is front-loaded with the action ('Show') and the object. No wasted words; every part adds value.
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 simplicity (zero params) and the presence of an output schema, the description adequately covers purpose and a key behavioral trait (token redaction). It could mention prerequisites or failure modes, but these are not critical for a read-only config display tool.
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?
The tool has zero parameters, so the schema trivially covers all inputs. The description adds context about the output (config path and site profiles) and the redaction behavior, which is useful beyond the empty schema. This meets the baseline for zero-parameter tools.
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 uses a specific verb 'Show' and clearly identifies the resource ('moodle-agent config path and site profiles'). It distinguishes itself from siblings like moodle_courses_list (courses) and moodle_whoami (user identity), making the tool's purpose unmistakable.
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 (viewing configuration) but provides no explicit when-to-use guidance or alternatives. It is clear enough that an agent would know when to invoke it, but no exclusions or sibling comparisons are offered.
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?
Given no annotations, the description discloses security-relevant behaviors: 'password is not stored' and 'Password goes only via env to the child process.' This adds meaningful context beyond the schema. However, it omits other side effects like overwriting existing tokens or modifying configuration files.
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 concise sentences, each carrying distinct information. It is front-loaded with the core action and avoids redundancy, making it easy to parse.
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?
Despite a clear purpose, the tool has 9 parameters and the description ignores most of them. It doesn't explain setup-related options (out_dir, name_style, course_dir_style, force). While an output schema exists, the description is still incomplete for a complex initialization 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 coverage is 0%, so the description must compensate. It clarifies username format, password env handling, and token preference. But many parameters (force, out_dir, site_name, name_style, course_dir_style) remain unexplained, leaving gaps in how they affect behavior.
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 action: 'Log in to ANY Moodle site and save webservice token'. It specifies scope (ANY site) and the primary outcome, distinguishing it from sibling tools like moodle_probe or moodle_whoami which focus on inspection rather than initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical usage guidance: 'Prefer token if available' and 'Username format is school-specific — pass exactly what the user uses on the portal.' This gives context for parameter selection, though it does not explicitly name alternatives or when-not-to-use the tool.
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?
No annotations provided, so description carries full burden. Discloses output default, force re-download behavior, and time expectation. Doesn't mention error conditions or side effects, but covers core behavior well.
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?
Two sentences, front-loaded, no redundancy. Perfectly sized.
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?
Adequate for a download tool with output schema. Includes key behavioral details (duration, force), but doesn't cover prerequisites or site param. Overall sufficient.
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 coverage is 0%. Description explains --out default and force semantics, and implies course_id. Does not explain 'site' parameter, leaving an optional parameter ambiguous. Adds value for most parameters but incomplete.
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?
States 'Full download of one course' – specific verb (download), resource (course), and scope (full). Distinguishes from sibling sync/list tools. Clear that it's a per-course download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: one course, output destination, force behavior, and duration. Doesn't explicitly name alternatives, but the utility is clear. Force guidance is useful.
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-downloader-mcp MCP server](https://glama.ai/mcp/servers/stojandev/moodle-downloader-mcp/badges/card.svg)](https://glama.ai/mcp/servers/stojandev/moodle-downloader-mcp)

Score Badge

Copy to your README.md:

[![moodle-downloader-mcp MCP server](https://glama.ai/mcp/servers/stojandev/moodle-downloader-mcp/badges/score.svg)](https://glama.ai/mcp/servers/stojandev/moodle-downloader-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/stojandev/moodle-downloader-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server