Skip to main content
Glama
Sign In
Skool MCP Server

Skool MCP Server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Add group rule

add_group_rule

Append a rule to a Skool group’s rules list as an admin and get the updated list back. Use it to update community guidelines without notifying members.

Instructions

Add a rule at the end of the group rules. Admins only.

Adds a rule after the existing ones, as Settings, Rules, Add does, and returns the whole new list. Admins only. Nobody is notified and it is undone with delete_group_rule, so it runs without asking first.

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>",
      "title": "<title>"
    },
    "name": "add_group_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
groupYesGroup URL name, e.g. 'yourgroup' for skool.com/yourgroup.
titleYesRule title, up to 30 characters.
descriptionNoWhat the rule means, shown under the title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond annotations: append-only ordering, returns the full new list, no one is notified, admin authorization required, and reversibility via delete_group_rule — which justifies bypassing confirmation. This is consistent with destructiveHint=false and non-idempotent hints. The only flaw is restating 'Admins only' twice.

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?

Short and front-loaded with the core action and placement first, then constraints. However 'Admins only' appears twice in four sentences, which is pure duplication and the one clear waste in an otherwise tight description.

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?

For a simple 3-parameter mutation with no output schema, it covers authorization, effect, ordering, return value, and undo path — everything needed to call it safely. Only minor gaps remain, such as how the returned list is shaped or whether title collisions are rejected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so group, title, and description semantics are already fully documented in the schema. The description adds no per-parameter guidance (no format hints, no note on optional description beyond what the schema says), so the baseline 3 applies.

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 ('Add a rule ... group rules') and pins the placement ('at the end', 'after the existing ones'). The UI analogy 'as Settings, Rules, Add does' makes it unambiguous which sibling it is versus update_group_rule, delete_group_rule, and list_group_rules.

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 real preconditions: admin-only access, and it should run without a confirmation prompt because it is non-notifying and reversible. It names delete_group_rule as the undo path, which effectively routes the agent to the right counterpart. It does not explicitly contrast with update_group_rule (editing an existing rule), which is the closest ambiguity.

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