Cubite LMS: Learning Management System

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

TableJSON Schema

Name	Required	Description
`email`	No	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.
`limit`	No	Max rows (default 100; values above 500 are capped at 500).
`offset`	No	Rows to skip (default 0); compare with total to page.
`status`	No	Only 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).
`userId`	No	Only this learner's enrollments, by user id (user.id in the rows).
`courseId`	No	Only enrollments in this course (must be on this site). Combine with email or userId to get one learner's enrollment in it.
`waitlisted`	No	true = only waitlisted learners; false = only learners off the waitlist; omit for both.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 6, 2026

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"
+}

AddedOct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With readOnlyHint=true and openWorldHint=false already covering the safety profile, the description adds substantial non-obvious behavior: newest-first ordering, an unknown email returning an empty list rather than an error, the counterintuitive status:"pending" + waitlisted:false case (learners unlocked from the waitlist who still see an enrollment step), and offset-until-total pagination. This is exactly the extra context annotations cannot carry.

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 the alternative-tool pointer are front-loaded, and there is no filler. However, the body is a single dense semicolon-chained paragraph and repeats some status detail already documented in the schema, which slightly hurts scanability for a 7-parameter tool.

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?

Although there is no output schema, the description fully specifies the return contract — {total, enrollments} plus every row field (courseId, userId, status, isWaitListed, enrolledAt, expiresAt, user object, progressPercentage, completedAt) — and explains how to page with offset. An agent has everything needed to call and consume the result.

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 goes beyond the per-field schema by explaining cross-parameter semantics the schema states only in isolation — the status:"pending" plus waitlisted:false interaction and the email/userId+courseId combination rule. It also clarifies that the status label describes 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?

Opens with a specific verb+resource ("List enrollment records on this site") and immediately scopes it ("who is enrolled or waitlisted in which course, and how far along they are"), including the default sort ("newest enrollment first"). It also draws a hard boundary against the closest sibling by stating applications are not enrollments and pointing to 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: application_list for applications awaiting a decision, and enrollment_update/enrollment_revoke to change or revoke a single learner's enrollment. It also enumerates the filter combinations (email alone = every course, email+courseId = the single enrollment, waitlisted true/false/omit) so the agent knows which call shape to build.

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 tools Inspect

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

Need Help?