Skip to main content
Glama
Sign In
deenesjakoruzh
Skool MCP

Skool MCP

by Solnest-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Skool MCP

Give Claude access to your Skool community. Posts, comments, members, classroom, and your DM inbox.

Ask Claude things like "what did people post this week?", "draft a reply to the last 5 DMs", or "pull my member list into a spreadsheet". It runs on your computer, using your own Skool login.

Unofficial. Not built by Skool, not affiliated with Skool.

What you can do with it

13 tools. The read ones are safe to fire off. The write ones post publicly under your name, so Claude should confirm the wording with you first.

Tool

What it does

Read or write

skool_whoami

Confirms your Skool login works and lists the communities you belong to. Run this first when something breaks.

read

skool_list_posts

Lists recent posts in your community feed: title, snippet, comment and upvote counts, author.

read

skool_get_post

Reads one full post and its comments.

read

skool_create_post

Publishes a new post to your community feed.

write

skool_comment_on_post

Adds a comment to a post.

write

skool_list_members

Lists members of your community: id, name, email, short bio.

read

skool_list_courses

Lists the classroom courses in your community.

read

skool_get_lesson

Reads a course's modules and lessons, and the content of one lesson.

read

skool_list_conversations

Your DM inbox: unread counts and last-message previews.

read

skool_get_conversation

Reads the messages in one DM conversation.

read

skool_send_message

Sends a DM into an existing conversation.

write

skool_mark_read

Marks a DM conversation as read.

write

skool_start_chat

Opens a new DM with a member.

write

Related MCP server: Socials MCP

Before you start

  • macOS or Windows. (Linux is untested.)

  • Claude Code or Claude Desktop.

  • A Skool account that is actually a member of the community you want to connect.

  • That's it. You do not need Python installed. The setup installs everything it needs.

Install

Step 1. Get the folder onto your computer. Either way works.

Option A, if you have git:

cd ~
git clone https://github.com/Solnest-AI/skool-mcp-community.git skool-mcp

That drops it at ~/skool-mcp, which is exactly where you want it.

Option B, the ZIP:

  1. Download the ZIP (on the repo page: green Code button, then Download ZIP).

  2. Unzip it.

  3. Rename the folder to skool-mcp and move it so it sits directly in your home folder.

Step 2. Put it in the right place. This matters more than it sounds like it should.

  • Mac: ~/skool-mcp (that is /Users/yourname/skool-mcp)

  • Windows: C:\Users\yourname\skool-mcp

Not Documents. Not Desktop. Not Downloads. macOS locks down those folders, and background tasks that try to read them fail in a way that is genuinely annoying to debug. Home folder, done.

Step 3. Point Claude at the folder and say "set this up".

In Claude Code:

cd ~/skool-mcp
claude

Then type: Set this up.

Claude reads SETUP.md and runs the whole thing: installs the tools, opens a browser so you can log into Skool yourself, verifies the connection, registers the server, and tests it. It stops and asks you when it needs you.

Setting up for Claude Desktop instead? Same thing. Run the setup from Claude Code (or by hand), and at the registration step tell Claude you want to use it in Claude Desktop.

How this works and what to know

Read this part. It is short and it is the honest version.

Skool has no official API. There is no developer program, no API key, no supported way in. So this does what your browser does: it uses your own logged-in session to talk to the same internal endpoints the Skool website uses.

Your login stays on your machine. During setup, a real browser window opens and you log into Skool yourself, exactly like normal (Google sign-in and 2FA both work). The script reads the session cookie out of that browser and writes it to a local file called .env. Nothing is sent to Solnest, to Anthropic, or anywhere else.

Never paste your cookie into a chat. Not to Claude, not to a friend, not to anyone online offering to help. That cookie is your entire Skool account: your posts, your DMs, your billing, your members. Anyone holding it is logged in as you. Setup is built so the cookie never has to appear in a conversation, and Claude is instructed to refuse if you offer it.

.env is your password file. Treat it exactly like one. Don't open it in a screenshare, don't screenshot it, don't paste it anywhere, don't drop it in Drive or Slack. The bundle is already set up to keep it out of any code you upload, so you mostly just have to not go out of your way to share it. If you ever think it leaked, log out of Skool everywhere and re-run setup.

The tools act as you. A post created by skool_create_post is your post. A DM is from you. It looks identical to typing it yourself, because functionally it is. Have Claude read the draft back to you before anything goes out.

Only use it on communities you actually belong to. These are your own credentials against your own memberships. Don't get cute.

Skool can break it. No official API means no stability promise. If Skool changes their site, tools can stop working overnight. When something breaks, run the doctor first:

cd ~/skool-mcp
uv run doctor.py

It tells you exactly which piece is broken and how to fix it. It never prints your cookie.

Your session expires eventually. The Skool login token lasts about a year, so this is rare. Re-run uv run connect_skool.py when the tools start failing with a login error.

A 403 is a different problem, and logging in again will not fix it. Skool's API sits behind a firewall (AWS WAF) that can refuse your computer before Skool ever sees the request. Your login is completely fine when this happens. There are two versions of it, and they need opposite fixes:

  • Your connection's fingerprint. The firewall inspects the technical signature of the connection itself, and plain Python does not look like a browser. The bundle handles this automatically now by borrowing Chrome's signature. Changing networks does nothing for it.

  • Your IP address. The firewall refuses the address you are coming from, usually a VPN, a proxy, or an address you share with a lot of other people. Only changing your network fixes it.

You do not have to work out which one you have. Run:

cd ~/skool-mcp
uv run net_check.py

It needs no login, takes five seconds, and tells you which of the two it is and exactly what to do. Do not start by reconnecting your Skool login, that cannot fix either one.

Getting help

Run uv run doctor.py (or uv run net_check.py for anything that looks like a 403 or "blocked"), then paste the output into Claude and ask it to fix what failed. The output is safe to share: it prints check results, cookie lengths, and expiry dates, never the cookie itself.

Still stuck? Start a fresh Claude chat, paste the doctor output, and say what you were trying to do. Never paste your .env.

License

MIT. See LICENSE.

Available Tools

13 tools
skool_comment_on_postA

Add a comment to a post. post_id is the real post id (the id field from skool_list_posts/skool_get_post, not the slug). Writes publicly — confirm first.

Inputs: content (required), post_id (required).

skool_create_postA

Publish a NEW top-level post to your community feed. Writes publicly — confirm wording with the user first. Returns the new post id.

Inputs: title (required), content (required).

skool_get_conversationA

Read the messages in one DM conversation (read-only). Get the channel_id from skool_list_conversations. Returns sender, content, timestamp per message.

Inputs: channel_id (required), limit.

skool_get_lessonA

Read a classroom course (read-only). course_id from skool_list_courses returns the course's modules/lessons (id + title). Pass a lesson_id (a child id) to also pull that lesson's content/metadata (note: many lessons are video- only, so the text content may be empty).

Inputs: course_id (required), lesson_id.

skool_get_postA

Read one full post and (by default) its comments. post_name is the slug from skool_list_posts (the name field, e.g. 'big-change-...'), not the id.

Inputs: post_name (required), with_comments.

skool_list_conversationsA

Your DM inbox (read-only): conversations with channel_id, unread count, and last-message preview. Use a channel_id with skool_get_conversation to read it.

Inputs: limit.

skool_list_coursesA

List the classroom courses in your community (read-only): id, title, description. Use a course id with skool_get_lesson to read its lessons.

Inputs: no named parameters.

skool_list_membersA

List members of your community (read-only): id, name, email, short bio. Use member ids with skool_start_chat to open a DM.

Inputs: limit.

skool_list_postsA

List recent posts in your community feed (read-only). Returns each post's id, name (slug), title, a content snippet, comment/upvote counts, author. Use the name with skool_get_post to read a full post + its comments.

Inputs: limit.

skool_mark_readA

Mark a DM conversation as read. Get the channel_id from skool_list_conversations.

Inputs: channel_id (required).

skool_send_messageA

Send a DM into an existing conversation. Writes — confirm wording first. Get the channel_id from skool_list_conversations.

Inputs: content (required), channel_id (required).

skool_start_chatA

Open a new DM with a member (by their user_id from skool_list_members). Returns the new conversation so you can then skool_send_message into it.

Inputs: user_id (required).

skool_whoamiA

Confirm the Skool cookie works and list the communities you belong to. Call this first if other tools error — it isolates auth/cookie problems.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    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

    TDQS

    A4.2/5.0

    Scored across 13 tools

    Disambiguation5/5

    Each tool addresses a distinct resource and action: posts, comments, members, courses, conversations, and messages. The read/write tools are clearly separated (list/get vs create/send), and the whoami diagnostic is unique. No two tools appear to overlap in purpose.

    Naming Consistency5/5

    All tools follow a consistent skool_<verb>_<noun> pattern (e.g., skool_list_posts, skool_get_post, skool_send_message). Even the outlier skool_whoami is a common convention for auth checks. The naming is predictable and groups resources and actions logically.

    Tool Count5/5

    13 tools is well within the ideal 3–15 range and matches the server's breadth: community posts, comments, member directory, course content, and DM messaging. Each tool serves a clear purpose with no redundancy. The count feels appropriately scoped for a community platform.

    Completeness4/5

    Core workflows are covered: reading/writing posts, commenting, listing/reading conversations, sending DMs, and browsing course lessons. Minor gaps exist—there is no tool to update or delete posts/comments, and no search across posts or courses—but these are not critical for typical usage and may reflect API limitations.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Resources

    Related MCP Connectors

    Related MCP Servers