Moodle Student MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
All 11 tools have clearly distinct purposes: listing resources, fetching details, downloading files, and identity check. No two tools overlap in functionality.
Naming Consistency5/5
Consistent verb_noun pattern: list_ for collections, get_ for single resource details, download_files for action, and whoami for identity. Mix of get_ and list_ is a sensible and predictable pattern.
Tool Count5/5
11 tools is appropriate for a student-facing Moodle MCP. It covers the essential workflows (courses, assignments, forums, files, grades, deadlines) without being excessive.
Completeness3/5
The set covers reading and listing well but lacks tools for student actions such as submitting assignments or posting in forums. This is a notable gap for a student assistant tool.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description must disclose behavior. It mentions returning 'title, author, date and the opening message', which is useful. However, it does not clarify the limit parameter's role or sorting order, though limit is implied by 'recent'. More explicit details about default limit and ordering would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. Every sentence adds value without redundancy, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states the return fields. It covers the required parameter usage and a use case. However, it omits details about the limit parameter and does not mention if the results are paginated. Overall, it is fairly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 add parameter meaning. It only mentions 'forum_id' in context, but does not explain the 'limit' parameter or its relationship to 'recent'. The description partially covers one parameter and misses the other entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'list the recent discussions of a forum', specifying the verb and resource. It differentiates from sibling tool 'list_forums' by focusing on discussions within a forum and adds context for teacher announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to use 'forum_id' from 'list_forums' and suggests a use case: 'Good for checking teacher announcements.' While it does not explicitly exclude other uses or mention alternatives, the guidelines are clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies that the tool lists only enrolled courses and returns specific fields, but does not disclose potential limitations like pagination, authentication requirements, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences with no extraneous information. The first states the core action, the second lists the return fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple input, the description provides enough context for the agent to use the tool. It explains what courses are returned and what data each course contains, but could mention if results are sorted or filtered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter information is needed. The description still adds value by detailing the output fields (id, name, short name, progress, last access), which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List the courses you are enrolled in', which is a specific verb+resource. It distinguishes from sibling tools like 'get_course_contents' or 'list_assignments' by focusing on enrollment status and providing course-level info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage guidance by noting 'id (use it in the other tools)', hinting that this tool is a precursor to other operations. However, it lacks explicit when-to-use, when-not-to-use, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It partially discloses the return data (name, type, url, description, completion state) and its reliance on a valid course_id. However, it does not explicitly state it is a read-only operation or describe error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two brief sentences, each serving a clear purpose: stating the tool's function and providing usage context and return data details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description covers the main use case and return fields. It could be more explicit about the data structure (e.g., sections containing activities), but overall it is sufficient for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'course_id' has 0% schema description coverage. The description adds crucial meaning by stating it should come from list_courses, which clarifies the expected value source beyond the raw integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sections/topics and activities of a course, with a specific verb 'List' and a distinct resource. It differentiates from sibling tools that focus on specific content types (e.g., list_assignments, list_forums).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the 'id from list_courses', providing a clear prerequisite. It does not mention when not to use this tool or alternative tools, but the prerequisite is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the return format (grade, max, percentage, weight, feedback) and emphasizes 'only YOUR grades,' but it does not explicitly state that the operation is read-only or discuss permissions, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no extraneous information. Every word serves a purpose, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (one parameter, no output schema), the description adequately covers the return fields and scope. It could be more explicit about 'current user' and 'all graded items,' but it is largely complete for an AI agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful guidance by specifying that course_id should come from list_courses. This clarifies the parameter's origin and usage beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows grades for a specific course, using 'your grades' to distinguish from siblings like get_submission_status or list_assignments. It specifies the resource and action effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by instructing to use the id from list_courses, but it does not explicitly mention when not to use this tool or provide alternatives. It sets expectations for usage without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes aggregation and sorting, and parameter behavior, but does not explicitly state that it is a read-only operation or other behavioral traits like access scope (all courses vs. specific). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second explains parameter and adds guidance. Front-loaded, no unnecessary words. Maximally concise for the information needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is nearly complete. Could clarify scope (all courses?) but otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains the 'days' parameter meaning ('look-ahead window') and its default (30). Adds clear value beyond the schema's minimal type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists upcoming tasks and deadlines, aggregated from various sources (assignment due dates, quiz closings), sorted by date. References Moodle's 'Timeline', forming a distinct purpose from siblings like list_assignments or list_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly recommends as 'best single source' for deadlines, but lacks explicit when-not-to-use or alternatives. The guidance is adequate given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns specific file details and is a read operation, but does not mention potential limitations like file type filtering or authentication requirements. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a purpose: stating the function, providing usage context, and listing returned fields. It is front-loaded and concise with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers all necessary aspects: purpose, prerequisite (list_courses), returned data, and next step (download_files). It is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by indicating the parameter `course_id` should come from list_courses, which is not in the schema. With 0% schema coverage, this compensates well. However, it doesn't describe the parameter's format or constraints beyond the integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists downloadable files of a course, specifies file types (PDFs, slides, notebooks), and lists return fields (filename, mimetype, size, section/activity, fileurl). It differentiates from sibling tools like list_courses and download_files by mentioning the data flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to use the `id` from list_courses and that the returned `fileurl` is for download_files, providing a clear workflow. It does not explicitly state when not to use the tool, but the context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: local storage path, caching behavior for already-downloaded files of same size, and return of local paths. No annotations exist, so the description carries the full burden. Could mention error handling or file overwrite behavior, but current detail is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no superfluous words. The key action and parameters are front-loaded, and caching detail is placed logically at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value and caching. It covers the main workflow but could mention error handling or prerequisites (e.g., course_id must exist). Overall, it is fairly complete for a straightforward download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for fileurls by linking it to list_files output. However, course_id is not described beyond being required, and its source (e.g., from list_courses) is not mentioned. Schema description coverage is 0%, so the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download course files'), the destination ('./materials/<course>/'), and the output ('return local paths'). It differentiates from sibling tools like list_files, which only list URLs without downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the optional fileurls parameter (to download specific files from list_files) and when to omit it (to download all files). This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses what information is returned (submission state, editable, graded, grade, feedback) and the meaning of the status. It correctly implies this is a read-only operation. No side effects are mentioned, but none are expected for a status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with the first sentence clearly stating the purpose. Every sentence adds value: source of parameter, list of information, status interpretation. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description comprehensively explains what the tool returns (submission state, editable, graded, grade, feedback) and how to interpret the output. It also provides the parameter source. This is complete for the agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `assign_id` is explained by referring to `list_assignments` as its source, adding context beyond the schema. Although the schema coverage is 0%, the description provides enough guidance for an AI agent to understand where to get the value. However, it does not specify constraints or format beyond being an integer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Show the status of YOUR submission for an assignment.' It specifies the verb ('show'), the resource ('submission status'), and the scope ('YOUR submission'). This distinguishes it from sibling tools like get_grades or list_assignments which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to use the `assign_id` from `list_assignments`, providing a clear source for the parameter. It also explains how to interpret the status ('A status other than 'submitted' means it has not been turned in yet'). However, it does not explicitly state when to use this tool versus alternatives, but it is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: omitting course_ids searches all courses, and it lists the return fields. However, it does not mention rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and efficiently explains parameter behavior and return fields without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies return fields and behavior for a simple list tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining the effect of omitting course_ids and listing return fields, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assignments with their due dates and specifies behavior when course_ids is omitted, distinguishing it from siblings like get_submission_status and get_upcoming_deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, including the effect of omitting course_ids, but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool lists forums and returns specific fields (id, name, type, description). It also explains the parameter behavior. It could explicitly note that it is a read-only operation, but the listing nature implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the main purpose, and the second clarifies the parameter behavior. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is complete: purpose, return fields, parameter behavior. No output schema needed. Could mention relationship to get_forum_discussions, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (course_ids) with no description, and schema coverage is 0%. The description compensates fully by explaining that omitting course_ids scans all courses, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists forums in courses, includes news/announcements, and distinguishes from sibling tools like get_forum_discussions. It specifies the verb 'list', the resource 'forums in your courses', and notes that it returns forum_id, name, type, and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: if course_ids is omitted, it scans all courses. This guides when to provide the parameter. However, it does not explicitly state when not to use this tool or mention alternatives, though the sibling get_forum_discussions is implied as a follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool returns name, user_id, site name, version, and function count. It implies no destructive actions. This is transparent for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose ('Confirm who you are'), and every word adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema, the description lists the return fields (name, user_id, etc.) and usage context. It fully covers what the agent needs to know to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100% (vacuous). The description does not need to add parameter info. Baseline for 0 parameters is 4, and the description adequately addresses the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Confirm who you are on Moodle and that the token is valid.' It uses a specific verb ('confirm') and identifies the resource (identity/token). Among siblings focused on data retrieval, whoami's purpose for authentication is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use it to diagnose the connection.' This indicates when to use the tool (diagnosis/verification). While it doesn't explicitly state when not to use, the simplicity and lack of alternatives make the guidance clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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-student-mcp MCP server](https://glama.ai/mcp/servers/tcpassos/moodle-student-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tcpassos/moodle-student-mcp)

Score Badge

Copy to your README.md:

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

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