Skip to main content
Glama
Sign In
Skool MCP Server

Skool MCP Server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Set member role

set_member_role
DestructiveIdempotent

Change a community member’s role to admin, moderator, or member; admins only. Use to grant or revoke moderation or admin permissions.

Instructions

Make a member an admin or moderator, or back to a member. Admins only.

Changes one member's role, as the member's Membership settings do: admin (full control), moderator (can remove posts and members) or member. Skool allows moderators only on the Pro plan. The group owner keeps their role. Admins only.

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>",
      "membership_id": "<membership_id>",
      "role": "<role>"
    },
    "name": "set_member_role"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleYesadmin, moderator or member.
groupYesGroup URL name, e.g. 'yourgroup' for skool.com/yourgroup.
membership_idYesmembership_id from list_members.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the mutation profile is known. The description adds genuinely non-obvious context: admin-level authorization is required, moderator assignment is plan-gated to Pro, and the owner's role is immutable — none of which appear in the annotations. It doesn't spell out the demotion consequence or the return value, keeping it from a 5.

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?

The lead sentence front-loads the action and the permitted transitions, and the supporting sentences each carry distinct constraints. The closing 'Admins only.' duplicates the opening one, a small redundancy that keeps it off a 5.

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 three-required-param mutation with full schema coverage and no output schema, the description covers the actions, authorization level, plan gating, and an important immutability edge case. An agent has enough to invoke it correctly and predict the permission outcome.

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 a 3 baseline applies, but the description goes further by explaining what each enum value actually grants ('admin (full control), moderator (can remove posts and members)'), which the schema only lists as bare values. It adds nothing on group or membership_id beyond what the schema documents.

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 first sentence states a specific verb ('Make a member an admin or moderator, or back to a member') on a specific resource, and names all three target states. The body clarifies scoping ('Changes one member's role'), which separates it from group-wide or bulk sibling tools like remove_member or ban_member.

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 gives a clear precondition ('Admins only') and an external constraint ('Skool allows moderators only on the Pro plan'), plus an exclusion ('The group owner keeps their role'). It does not name alternatives such as remove_member or ban_member for an agent weighing role-change vs. removal, so it stops short of explicit when-not/alternative routing.

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