Skip to main content
Glama
Sign In

Cubite LMS: Learning Management System

by io.cubite
OverviewDiscussionsAdmin

List enrollments

enrollment_list
Read-only

List enrollment records on this site, newest enrollment first: who is enrolled or waitlisted in which course, and how far along they are. Narrow it to one learner by email or userId (every course they are in, or with courseId their single enrollment; an unknown email returns an empty list), by course, by exact status label, or to the waitlist queue (waitlisted:true) or everyone off it (waitlisted:false); status:"pending" with waitlisted:false finds enrolled learners who still see an enrollment step instead of Start/Continue (for example, ones unlocked from the waitlist in the dashboard). Course applications awaiting a decision are not enrollments: see application_list. Each row has courseId, userId, status, isWaitListed, enrolledAt, expiresAt, user {id, name, email, username}, progressPercentage (0 if not started) and completedAt (set when the learner first completes the course). Returns {total, enrollments}; page with offset until it reaches total. To change or revoke one learner's enrollment, pass their email straight to enrollment_update or enrollment_revoke.

Input Schema

NameRequiredDescriptionDefault
emailNoOnly this learner's enrollments, by account email (case-insensitive). An email with no account or no enrollment on this site returns an empty list.
limitNoMax rows (default 100; values above 500 are capped at 500).
offsetNoRows to skip (default 0); compare with total to page.
statusNoOnly rows with exactly this status label, e.g. "completed" (API enrollments, approved applications and payments; the only label that gives learners the Start/Continue button), "pending" (a learner who joined a waitlist, or one the dashboard added or unlocked) or "active" (learning-path enrollments). The label is about the enrollment, not course completion (see progressPercentage and completedAt).
userIdNoOnly this learner's enrollments, by user id (user.id in the rows).
courseIdNoOnly enrollments in this course (must be on this site). Combine with email or userId to get one learner's enrollment in it.
waitlistedNotrue = only waitlisted learners; false = only learners off the waitlist; omit for both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / courseId / description
      Previous value: -"Only enrollments in this course (must be on this site). Rows cannot be filtered by learner: to check one learner, pass their course and match user.email."New value: +"Only enrollments in this course (must be on this site). Combine with email or userId to get one learner's enrollment in it."
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Only this learner's enrollments, by account email (case-insensitive). An email with no account or no enrollment on this site returns an empty list.",
+  "type": "string"
+}
    • addedInput schema / properties / userId
      Added value: +{
+  "description": "Only this learner's enrollments, by user id (user.id in the rows).",
+  "type": "string"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, and the description adds substantial behavior beyond that: default sort order, the empty-list outcome for an unknown email, the pagination contract ({total, enrollments}, page with offset until total), the row field list, and the non-obvious semantics of the "pending" status label relative to waitlist unlocking.

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?

Purpose and default ordering are front-loaded, and nearly every clause carries information. The middle section is a dense single paragraph of semicolon-chained filter cases, which is harder to scan than a short list would be, but nothing is truly wasteful.

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?

There is no output schema, so the description carries that burden and does so: it enumerates row fields, states the envelope shape and pagination method, and warns that an unmatched email returns an empty list rather than an error. Nothing needed to call this tool correctly appears to be missing.

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 per-parameter baseline is 3; the description goes further by explaining cross-parameter behavior the schema cannot (email/userId + courseId yields the learner's single enrollment, status:"pending" with waitlisted:false isolates unlocked learners) and that status means the enrollment, not course completion.

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 and resource ("List enrollment records on this site"), names the default ordering (newest first), and characterizes the rows (who is enrolled or waitlisted in which course, and progress). It is immediately distinguishable from the sibling mutators enrollment_create/update/revoke and from application_list.

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 routes the agent: applications awaiting decision are not enrollments and should use application_list, and single-learner changes belong to enrollment_update or enrollment_revoke. It also spells out the when-to-use condition for each filter combination (email/userId with or without courseId, waitlisted true/false, status:"pending" + waitlisted:false).

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

All Cubite LMS: Learning Management System toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources