Helper documentation

Helper turns a Skool community into tools an AI assistant can call. There are two ways to use it: add the MCP server to an LLM client (Claude, or any Model Context Protocol client), or call the REST API directly from code. Both run the same actions and use the same API key.

Overview

Every request is authenticated with an API key (sk_live_…) and scoped to your account and the Skool communities you've connected. Helper holds an encrypted Skool session for each community, so you never pass cookies or passwords on individual calls.

• Base URL — https://tryhelper.co
• MCP endpoint — https://tryhelper.co/mcp
• Auth — Authorization: Bearer sk_live_… (or OAuth 2.1 for MCP clients that support it)
• Content type — application/json

1 · Get an API key

Register an account, then copy the key shown once on the confirmation screen. You can also mint additional keys later.

Create an account →

Or mint a key over HTTP with your account email + password:

curl -X POST https://tryhelper.co/v1/api-keys \
  -H "content-type: application/json" \
  -d '{"email":"you@example.com","password":"…","name":"my-key"}'

# → { "success": true, "id": "...", "token": "sk_live_..." }  (token shown once)

2 · Connect a Skool community

Tell Helper which community to manage and provide the Skool admin login for it. Helper logs in once, encrypts the session, and refreshes it automatically. The groupSlug is the last path segment of the community URL — skool.com/my-community.

curl -X POST https://tryhelper.co/v1/groups/connect \
  -H "authorization: Bearer sk_live_..." \
  -H "content-type: application/json" \
  -d '{"groupSlug":"my-community","email":"admin@example.com","password":"…"}'

Connect an MCP client

Add Helper as a custom connector so an assistant can call the tools directly. In Claude: Settings → Connectors → Add custom connector, then paste the MCP URL:

When the client asks how to authenticate, choose one of:

• API key — send header Authorization: Bearer sk_live_….
• OAuth 2.1 — clients that support it can use the built-in authorization flow (PKCE, dynamic client registration). Endpoints: /authorize, /oauth/token, /oauth/register.

Once connected, the model sees 36 tools. A typical run: it calls skool_list_groups to find your groupSlug, then skool_groups_info for category/label ids, then an action like skool_posts_create. Just ask in natural language — “approve everyone pending and DM them a welcome.”

Programmatic MCP clients speak streamable HTTP / JSON-RPC at the same URL. A tools/call looks like:

POST https://tryhelper.co/mcp
authorization: Bearer sk_live_...
content-type: application/json

{
  "jsonrpc": "2.0", "id": 1,
  "method": "tools/call",
  "params": {
    "name": "skool_posts_create",
    "arguments": {
      "groupSlug": "my-community",
      "title": "Welcome!",
      "content": "Glad you're here.",
      "labelId": "<from skool_groups_info>"
    }
  }
}

Call the REST API

Prefer raw HTTP? Every tool maps to a single endpoint: POST /v1/execute with an action, a groupSlug, and the action's params.

curl -X POST https://tryhelper.co/v1/execute \
  -H "authorization: Bearer sk_live_..." \
  -H "content-type: application/json" \
  -d '{
    "action": "posts:list",
    "groupSlug": "my-community",
    "params": { "maxPages": 2 }
  }'

# → { "success": true, "data": { "items": [ ... ], "pagination": { ... } } }

List pending members and approve one:

# 1. find pending join requests
{ "action":"members:list", "groupSlug":"my-community", "params":{ "t":"pending" } }

# 2. approve by the membershipId returned above
{ "action":"members:approve", "groupSlug":"my-community", "params":{ "membershipId":"123" } }

Action parameters

The MCP tool name and the REST action are two faces of the same call. The tool's input schema is the action's params (minus groupSlug, which is always top-level). For example the tool skool_posts_create ↔ action posts:create takes title, content, and labelId. Most calls follow a read-then-write pattern:

• Get a community's label/category ids & metadata → group:get (skool_groups_info).
• Get post ids → posts:list; member membershipIds → members:list.
• Then act with the id (posts:edit, members:ban, calendar:edit…).

Tool / action list

35 community actions, plus skool_list_groups (lists the communities connected to your account). MCP tool name on the left, REST action in the middle.

Responses & errors

Every action returns a JSON envelope:

// success
{ "success": true, "data": { /* action-specific */ } }

// failure
{ "success": false, "error": "rate limited", "errorCode": "RATE_LIMIT" }

• 200 — call ran (check success).
• 401 — missing/invalid API key.
• 403 — FORBIDDEN: the connected account lacks rights, or the groupSlug isn't yours.
• 429 — RATE_LIMIT: slow down and retry.

Auth & rate limits

• Keys are scoped to your account and only the communities it owns — a key can never touch another tenant's data.
• Rate limits apply per account + community, with stricter ceilings on heavy actions (bans, removals, exports). Both the MCP and REST paths share the same limiter, so neither bypasses it.
• Credentials are stored in an encrypted vault — cookies under the master key, the Skool password under a separate wrapping key. Sessions refresh automatically.
• Audit — every action is logged for 30 days. Review it from your dashboard.

Get started →   Back to home