Skip to main content
Glama
csmediapro

moodle-mcp-server

by csmediapro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list_course_users

List enrolled users for a specific Moodle course or all courses in a category, returning names, emails, roles, and last access details.

Instructions

List enrolled users in a specific Moodle course or across all courses in a specific LMS category. Provide exactly one of courseid, coursename, or categoryid. Returns user ID, full name, email, department, institution, last access timestamps, and enrollment roles. Category mode deduplicates overlapping users across courses before returning results. Use an exact category ID from list_categories when working at category scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_siloNoINTERNAL: Silo filter injected by agent-edge. Not for direct use.
limitNoMaximum users to return
offsetNoPagination offset
courseidNoMoodle course ID
categoryidNoLMS category ID. Aggregates enrolled users across all courses in the category.
coursenameNoMoodle course name for partial matching

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.5
    • addedInput schema / properties / _silo
      Added value: +{
+  "description": "INTERNAL: Silo filter injected by agent-edge. Not for direct use.",
+  "properties": {
+    "field": {
+      "type": "string"
+    },
+    "value": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "field",
+    "value"
+  ],
+  "type": "object"
+}
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it enumerates the returned fields (ID, name, email, department, institution, last access, roles) and discloses non-obvious semantics such as category-mode deduplication of overlapping users. It omits pagination/result-cap behavior and any auth or rate-limit notes, so it is not fully complete.

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?

Four sentences, each earning its place: purpose, required-argument rule, return payload, and category-mode nuance. The most decision-relevant information (scope and the one-of constraint) 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?

With no output schema and no annotations, the description compensates by listing return fields and deduplication behavior, which is exactly what an agent needs. Minor gap: no guidance on limit/offset pagination or behavior when the 500-user cap is hit.

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 100%, so the baseline is 3, but the description adds a mutual-exclusivity constraint ('exactly one of courseid, coursename, or categoryid') that the schema does not express via anyOf/oneOf, plus clarification that coursename is partial-match and categoryid aggregates. That is real added 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?

States a specific verb+resource ('List enrolled users') with two explicit scopes (single course vs. whole category), which cleanly separates it from siblings like search_users and list_user_courses. An agent knows exactly what entity set is returned without opening the schema.

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?

Gives a concrete selection rule ('Provide exactly one of courseid, coursename, or categoryid') and routes the agent to list_categories for valid category IDs. It stops short of naming explicit alternatives to use instead (e.g. search_users for ad-hoc user lookup), so it is clear context without full when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools