Skool MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: community info vs labels, member management actions are clearly separated (list, pending, approve, reject), posts have list/get/create/comment, and courses/lessons/notifications are separate. The generic skool_request is the only outlier but serves a clearly different purpose as a catch-all.
Naming Consistency5/5
All tools follow the skool_<resource>_<action> pattern consistently, e.g., skool_members_list, skool_posts_create, skool_courses_list. Even the generic request tool fits the prefix convention. No mixed casing or verb style deviations.
Tool Count5/5
14 tools is well within the ideal 3-15 range for a platform-specific server. The count covers the major areas (community, members, posts, courses, lessons, notifications) without being bloated or sparse.
Completeness3/5
The surface covers core read and some write operations, but there are notable gaps: no post update/delete, no member removal, no course creation/management, and lesson content is not fetched. The generic skool_request can fill some gaps but is not a substitute for dedicated tools.
Average 3.7/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation ('Get') and gives the endpoint, but does not disclose whether authentication is needed, what the response contains, or any error behavior. For a simple getter this is thin, especially with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words. It includes the endpoint and the action, making it concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema). The description plus parameter schema covers the basic action and how to find the groupId. However, the lack of return format details and no mention of authentication or limitations leaves some gaps, but it is adequate for a simple getter.
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 description coverage is 100% and the parameter description (groupId, find via skool_community_info) adds context. The tool description itself adds no parameter information beyond what the schema provides, so the baseline 3 applies.
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?
The description uses a specific verb ('Get') and resource ('category labels for a community') and includes the API endpoint. It clearly identifies what the tool does, but does not explicitly distinguish it from sibling tools like skool_community_info or skool_members_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related sibling tools. The description simply states the function without context about prerequisites, alternatives, or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Uses the Next.js classroom data route with course parameter,' which is an implementation detail but does not disclose whether this is a read-only operation, any side effects, auth requirements, or return format. For a list tool, stating that it retrieves data without mutations would be expected but is absent.
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 description is short and front-loaded with the core purpose. However, the second sentence about the Next.js route is arguably unnecessary for an AI agent and may be technical noise. It doesn't waste words, but the second sentence could be trimmed for greater clarity. Still, it is appropriately concise overall.
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?
Given the low complexity (2 params, simple list operation) and full schema coverage, the description is mostly complete. It tells the agent what the tool does and what it operates on. However, with no output schema and no mention of return value or behavior beyond the name, some information is left implicit. For a simple list tool, this is adequate but not exceptional.
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 the parameters are already fully described in the input schema. The description adds no semantic value beyond the schema, merely restating that a course parameter is used. Since schema does the heavy lifting, the baseline score of 3 is appropriate.
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 description clearly states 'List lessons/modules in a specific course,' which is a specific verb+resource+scope. This distinguishes it from sibling tools like skool_courses_list (lists courses) and skool_posts_list (lists posts). The mention of 'specific course' makes the target resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like skool_courses_list or any prerequisites (e.g., needing a courseSlug obtained from skool_courses_list). The only usage hint is that it requires a course parameter, which is already in the schema. There is no explicit when/when-not wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pagination behavior and the type of member info returned, which is useful. However, it does not clarify that this likely lists only active/approved members (given the sibling skool_members_pending), and there are no annotations to rely on for safety or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action ('List community members') and includes essential return info. There is no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives basic context (pagination, return fields) but omits details about pagination behavior (e.g., page size, response structure) and does not clarify the scope relative to pending members. Since there is no output schema, this leaves some ambiguity for the agent.
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?
The input schema covers 100% of parameters with clear descriptions (page, community). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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?
The description clearly states the tool lists community members with pagination and shows the returned fields (name, bio, role, online status). It names a specific verb and resource, but does not explicitly differentiate from the sibling skool_members_pending, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like skool_members_pending. The description only explains what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of explaining behavior. It only mentions that it 'Tries' the Next.js route, which hints at experimental behavior but does not disclose response format, error handling, authentication needs, or how 'recent' is defined. This is significant missing context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by a brief implementation note. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional param, no output schema), but without annotations, the description must explain return values and behavioral limitations. It fails to describe what the response contains or any constraints, making it under-specified for an agent to fully anticipate the tool's behavior.
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 for the sole parameter 'page' is 100% with a description, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides, which is acceptable given the high coverage.
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 description clearly states 'Get recent notifications' with a specific verb and resource. It is easily distinguishable from sibling tools which focus on members, posts, courses, etc. The implementation note about the Next.js data route adds context without obscuring the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement implies usage for retrieving notifications, but there is no explicit guidance about when to prefer this tool over alternatives or any exclusions. Since no other notification tool exists among siblings, the context is clear, but the description does not explicitly confirm when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the auth requirement ('Requires admin/moderator auth') but does not mention side effects, irreversibility, or consequences of rejection, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-param mutation tool, the description covers the core purpose and auth. However, it lacks information on return values or side effects, and given no annotations, a bit more detail would be expected.
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?
Both parameters are already described in the schema (100% coverage): memberId as the request UUID and groupId as the group UUID. The description adds no new semantic information beyond the schema, so 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?
The description clearly states the tool's function: rejecting a pending member by their membership request ID. The verb 'reject' and specific resource ('pending member') distinguish it from sibling tools like skool_members_approve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a pending membership request needs to be denied, and mentions an auth requirement. However, it does not explicitly contrast with alternative actions (e.g., approve) or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating 'Requires auth cookies' and 'Posts to api2.skool.com', but it does not disclose return values, error handling, permission scopes, or what happens on failure. The mutation side effect is clear from the word 'create', but additional behavioral details are sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately convey the primary purpose and key operational requirements. There is no redundant or filler content, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with complete parameter schema, the description is minimally adequate. However, because there is no output schema, the agent is left uninformed about the return value or error responses. The auth cookie mechanism is also not explained (e.g., how to provide cookies), which could hinder invocation in some environments. These gaps make it only partially complete.
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?
The schema provides descriptions for all four parameters (label, title, content, groupId), achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.
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 description clearly states the tool's function: 'Create a new post in a community.' The verb 'create' and resource 'post' are specific, and it distinguishes from sibling tools like skool_posts_list (read), skool_posts_get (read), and skool_posts_comment (comment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions that it requires auth cookies and posts to a specific endpoint, but does not explain when to prefer this over skool_request or other post-related tools, nor are any exclusions or alternative scenarios described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly mentions 'read access,' which is useful, but it does not disclose potential errors, authentication requirements, or rate limits. The 'Uses Next.js data route' detail adds little for an agent.
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 description is short and front-loaded with the core purpose. The second sentence about a Next.js data route adds some implementation detail but is not essential for agent decision-making, slightly reducing efficiency.
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?
The description lists expected return content (name, description, member count, settings) despite lacking an output schema. It is adequate for a simple read-only tool but does not cover error cases or environmental prerequisites.
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?
The schema fully documents the single parameter ('community') including an example and default behavior. The description does not add semantic meaning beyond the schema, so a baseline score of 3 is appropriate given 100% schema coverage.
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 description clearly states a specific action ('Get community details') and specifies key fields (name, description, member count, settings). This distinguishes it from sibling tools focused on members, posts, or courses, making the tool's purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving community-level details but does not explicitly state when to use this tool over alternatives (e.g., skool_members_list for members). No exclusions or alternative references are provided, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the auth requirement but does not disclose potential side effects, reversibility, or what happens after approval, which is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb, using only two sentences with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully described parameters, but the description lacks information about return values or error behavior, and there is no output schema to compensate. This makes it minimally viable but not fully complete.
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?
The input schema already documents both parameters with descriptions (100% coverage), and the description adds no significant new meaning beyond calling 'memberId' a membership request ID, which mirrors the schema. Therefore, the baseline of 3 is appropriate.
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 description clearly states the action ('Approve'), the target resource ('pending member'), and the identifier ('membership request ID'), distinguishing it from sibling tools like skool_members_reject. It is specific and unambiguous.
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?
The description provides clear context by indicating the approval use case and the admin/moderator auth requirement. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool returns full content and comments, and the name 'get' implies a read operation. However, it does not mention error handling, authentication requirements, or rate limits, which are important for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that fronts the action ('Get a single post...') and includes the necessary input instruction ('Provide the post slug...'). There is no redundant information or unnecessary length; every word earns its place.
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 read tool with complete schema coverage and no output schema, the description sufficiently communicates the tool's purpose, return value (full content and comments), and required input. It is adequately complete for the tool's complexity, though it omits edge-case behaviors like error responses.
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?
The schema covers 100% of parameters with detailed descriptions (postSlug and community). The description only repeats the post slug source ('name field from posts list'), which is already in the schema. Therefore, the description adds no additional parameter semantics beyond the schema, justifying the baseline score of 3.
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 description clearly states the tool's function: 'Get a single post with its full content and comments.' The verb 'Get' is specific, the resource is obvious, and the scope (single post vs. list) distinguishes it from sibling tools like skool_posts_list. It also explains the required input (post slug), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a single post's full content and comments, which is distinct from list or create tools, but it does not explicitly mention alternatives or when not to use this tool. The sibling tool names provide context, but the description itself lacks direct 'use this instead of...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the return fields (title, content preview, author, likes, comment count) and mentioning filtering/pagination support. However, it does not elaborate on pagination mechanics, rate limits, authentication, or error behavior, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: three sentences that are front-loaded with the exact purpose, followed by key features and return data. Every sentence contributes useful information without redundancy or fluff.
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 read-only list operation with four optional parameters and no output schema, the description is mostly complete: it states the resource, features, and return fields. It falls short only in not detailing pagination behavior (e.g., page size, total count) or error scenarios, which is a minor gap for a tool of this simplicity.
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 description coverage is 100%, so the baseline is 3. The description’s mention of 'category filtering and pagination' adds only marginal meaning beyond the existing schema descriptions for the parameters. No significant new parameter semantics are provided.
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 description clearly states 'List posts in a community feed' with a specific verb and resource, and highlights supporting features like category filtering and pagination. This distinguishes it from sibling tools like skool_posts_get (single post retrieval) and skool_posts_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for listing posts in a community feed, but it does not explicitly state when to use it versus alternatives such as skool_posts_get or skool_posts_create. There is no mention of exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the action ('List') which implies a read-only operation, and adds that it returns 'course names and metadata,' providing basic behavioral transparency. It does not mention side effects, auth, or rate limits, but for a list operation the core safety profile is evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler words. Every word earns its place, front-loading the action and resource, then adding the return type. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description's mention of 'course names and metadata' is helpful but still minimal. It does not explain the distinction between 'groupId' and 'community', nor any pagination or filtering behavior. For a simple list tool, this is adequate but leaves clear gaps in the agent's understanding of richer data via groupId.
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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond what the schema already provides for 'groupId' and 'community', so it does not exceed the baseline.
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 description uses a specific verb ('List') and resource ('courses in a community classroom'), making the tool's purpose clear. It also distinguishes from sibling tools like 'skool_lessons_list' by specifying 'courses' rather than 'lessons'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing courses in a classroom, but it does not provide explicit when-to-use guidance or contrast with alternatives such as skool_lessons_list or skool_posts_list. It is minimally viable but lacks clearer context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that cookies and User-Agent are injected automatically, which is useful. However, it does not warn that arbitrary requests can be destructive (POST/PUT/DELETE) or mention response format, rate limits, or error handling. 'Arbitrary' implies power, but the description stops short of fully explaining the behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and each sentence adds value: first states what and where, second gives use cases and a technical detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an arbitrary request tool with no output schema and no annotations, the description is minimally adequate. It identifies the core capability and key injected behavior, but lacks context on expected response format, side effects of non-GET methods, and safety caveats. The schema covers parameters, so the main gap is behavioral completeness for a flexible tool.
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?
The input schema provides complete descriptions for all 4 parameters (url, body, method, headers), covering 100% of schema properties. The description adds context about automatic cookies/User-Agent injection, which relates to headers, but does not add per-parameter details beyond the schema. Baseline 3 is appropriate.
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 description clearly states the tool makes arbitrary authenticated HTTP requests to any Skool URL, which is a specific verb+resource that distinguishes it from the sibling tools that target specific endpoints (posts, members, courses). It also states its intended use cases: API discovery and debugging.
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?
The description mentions it is 'Useful for API discovery and debugging', which gives clear context for when to use this tool over the specialized sibling tools. It doesn't explicitly exclude use for other purposes or name alternatives, but the purpose is clear enough that an agent would understand this is a low-level fallback tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth requirement ('Requires auth cookies') and the endpoint ('Posts to api2.skool.com'), which is helpful. However, it does not describe side effects, error behavior, or any post-condition beyond the action itself, so it remains moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three short sentences that front-load the main purpose and include essential operational details (auth and endpoint). Every word earns its place, and there is no redundancy or fluff.
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 mutation tool with fully described parameters and no output schema, the description covers the essential context: what it does, the auth prerequisite, and the target endpoint. It could mention the response format or edge cases, but given the low complexity, this is largely complete.
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 description coverage is 100% (all three parameters have descriptions). The tool description adds no additional parameter meaning, so the baseline of 3 applies. It does not introduce any syntax or formatting details beyond what the schema already provides.
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 description clearly states the action 'Add a comment to a post' with a specific verb and resource. It distinguishes from sibling tools like skool_posts_create (which creates posts) by focusing on commenting, making the purpose unambiguous.
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?
The description gives clear context for use: adding a comment to a post. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident given the sibling tool list. A score of 4 reflects the clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth requirement, which is a critical behavioral trait. It also implies a read-only operation via 'List'. It does not detail pagination or response format, but for a simple list operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences. It front-loads the core purpose and immediately gives the critical prerequisite. No wasted words.
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?
The tool is simple: one optional parameter, no nested objects, no output schema. The description explains the purpose and auth requirement, making it complete for the agent to understand when and how to use it. The absence of an output schema is not a significant gap since the name implies a list of requests.
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?
The input schema already provides 100% coverage for the single parameter 'community', including its default behavior. The description adds no additional parameter-specific semantics, so the baseline score of 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?
The description clearly states the action ('List') and the specific resource ('pending membership requests'). This clearly distinguishes it from sibling tools like skool_members_list (which lists members) and skool_members_approve/reject (which modify membership).
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?
The description provides a key usage condition: it requires auth cookies with admin/moderator access. This implies the tool is for privileged users. However, it does not explicitly mention alternatives or say 'use this instead of skool_members_list', but the resource name makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![skool-mcp MCP server](https://glama.ai/mcp/servers/louiewoof2026/skool-mcp/badges/card.svg)](https://glama.ai/mcp/servers/louiewoof2026/skool-mcp)

Score Badge

Copy to your README.md:

[![skool-mcp MCP server](https://glama.ai/mcp/servers/louiewoof2026/skool-mcp/badges/score.svg)](https://glama.ai/mcp/servers/louiewoof2026/skool-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/louiewoof2026/skool-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server