Skip to main content
Glama
Sign In

Skool MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

List members

list_members
Read-onlyIdempotent

Members of a group with role, level, points and join date, newest first; also banned or churned. Lists members of one group, newest approved first, 30 to a page; pass next_cursor back as cursor for the next page. status picks Skool's tab: active members (admins included), banned, churned (left the group) or cancelling (paid groups). role admin or moderator asks Skool for the admins only. joined_at is when the member was approved. level is the Skool level (1 to 9) and points the likes that count toward it. on_trial marks a member on a paid group's free trial (in the active tab with everyone else). joined_since filters within the page, so read every page: Skool does not always sort by join date. member_id is the person (send_message, get_member); membership_id is their place in this group (set_member_role, ban_member, remove_member).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group": "<group>"
    },
    "name": "list_members"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoall, admin, moderator or member. Default: all.
groupYesGroup URL name, e.g. 'yourgroup' for skool.com/yourgroup.
limitNo1 to 30. Default: 30.
cursorNoNext page cursor from the previous call.
statusNoWhich members tab: active (default), banned, churned (left) or cancelling (paid groups).
joined_sinceNoOnly members who joined on or after this date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description goes further with genuinely non-obvious behavior: fixed 30-per-page size, Skool not always sorting by join date, on_trial members appearing inside the active tab, and role=admin/moderator collapsing to an admins-only query. These are caveats an agent could not infer from schema or annotations.

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?

Front-loaded with the resource and fields, then pagination, then filters, then ID disambiguation — a logical order. It is a dense semicolon-chained paragraph with no headers, which hurts scanability, but nearly every clause carries information an agent needs.

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?

No output schema exists, and the description compensates by enumerating the returned attributes (role, level, points, joined_at, on_trial, member_id, membership_id) plus pagination and sorting quirks. Nothing essential for calling or interpreting the result is 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 baseline is 3, but the description adds meaning the schema lacks: joined_at is approval time, level is Skool level 1–9 and points are the likes counting toward it, and on_trial is a free-trial marker inside the active tab. Minor cost: the role explanation ('admin or moderator asks Skool for the admins only') is ambiguous against the distinct enum values.

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?

States the resource precisely ('members of one group') with the returned fields (role, level, points, join date) and ordering (newest approved first), so an agent knows exactly what it gets. It does not explicitly contrast itself with search_members, which is the main ambiguity for a member-listing tool.

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?

Strong operational guidance: 30-to-a-page pagination with 'pass next_cursor back as cursor', status-tab semantics, and a warning that joined_since filters only within a page so every page must be read. It also routes between member_id (send_message, get_member) and membership_id (set_member_role, ban_member, remove_member). No explicit 'use search_members when looking for one person' exclusion, so 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.

All Skool MCP Server and API by Cotlet 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