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

With no annotations, the description carries the full behavioral burden. It does disclose that this is a read operation via 'data route for read access,' which is useful. However, it does not mention failure behavior, authentication requirements, or output shape beyond the listed fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. It front-loads the purpose and returned contents, and adds the read-access context efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter, the description covers the main purpose and returned data. Since there is no output schema, slightly more detail about exact return shape or error handling would improve completeness, but it is largely sufficient.

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

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

The input schema already fully documents the single optional parameter, including the default-from-config behavior. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool gets community details, naming the specific fields returned (name, description, member count, settings). It is specific about the resource and the verb, though it does not explicitly contrast itself with sibling tools like skool_community_labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 sibling tools, nor any exclusions or alternative recommendations. The 'read access' phrase hints at safe usage but does not say anything about when this is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action and endpoint domain; it does not mention authentication needs, response format, error behavior, rate limits, or whether any side effects exist. The 'Get' verb implies read-only behavior, but that is not made explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the core operation clearly. The phrase 'from api2.skool.com' adds endpoint context but is not essential; still, it does not meaningfully hurt conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with full schema coverage, the definition is minimally viable: it says what the tool returns and where the parameter comes from. However, without an output schema or annotations, the description could usefully state the shape of the returned labels or any access restrictions, which are currently left to inference.

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

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

Schema description coverage is 100%, and the groupId parameter is already described as 'The group UUID (find via skool_community_info)'. The tool description adds no new parameter detail, but the schema sufficiently handles semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), scoped to a community, which clearly distinguishes it from siblings like skool_community_info, skool_members_list, and skool_posts_list. An agent can tell what this tool does without needing to inspect the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. The schema param note 'find via skool_community_info' helps locate the groupId, but it does not explain conditions, prerequisites, or situations where a different sibling tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description must carry the behavioral disclosure burden. It conveys that this is a read-style listing operation and states what is returned, but it does not mention authentication needs, pagination, or how groupId vs community impacts behavior beyond what the schema already states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no wasted words. The action is front-loaded, and the return-value sentence earns its place by giving the agent a preview of what the call produces.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter list tool, the description plus schema is mostly workable, but it is not fully complete: there is no output schema, no explicit read-only confirmation, and no guidance for choosing between this and the lessons/posts siblings. The description covers the basics but leaves several selection and behavior questions open.

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

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

Schema description coverage is 100%, so the schema already documents groupId and community clearly, including the api2.skool.com behavior and default config fallback. The description adds no parameter-level meaning beyond saying 'community classroom,' so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List courses'), the resource ('in a community classroom'), and the return payload ('course names and metadata'). It differentiates from siblings like skool_lessons_list and skool_posts_list by naming the course resource, though it does not explicitly contrast itself with a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to choose this tool over alternatives such as skool_lessons_list, nor does it mention prerequisites or the difference between listing courses vs lessons. Usage context is only implied by the verb and resource.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only mentions an implementation detail ('Uses the Next.js classroom data route') and does not disclose read-only behavior, pagination, error conditions, or prerequisites. The agent cannot anticipate behavior beyond the basic listing semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the core purpose and free of redundant filler. The second clause about the Next.js route is somewhat extraneous but does not bloat the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with two well-documented parameters, the description is minimally adequate. However, with no output schema and no annotations, it does not explain response format, error handling, or how courseSlug is obtained in context, leaving some gaps for an agent.

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

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description merely references 'course parameter,' which adds no meaning beyond the schema and uses slightly different terminology than courseSlug.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action and resource: 'List lessons/modules in a specific course.' This distinguishes it from course-level and post-level tools, though it does not explicitly name any sibling tool for contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use guidance, exclusions, or references to alternatives like skool_courses_list or skool_posts_list. The usage context is only implied by the purpose statement; adding a sentence about when to choose this over related tools would help.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explicitly discloses an admin/moderator auth requirement and conveys a state-changing approve action. It stops short of noting irreversibility or response behavior, but the core behavioral traits are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; the action and the auth requirement are front-loaded and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with two well-described parameters and no output schema, the description covers the required action and auth precondition. It could add a note about the outcome or error conditions, but nothing essential is missing for an agent to call it correctly.

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

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 reference to 'membership request ID' matches the schema's memberId description and adds no further semantic detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Approve'), a precise resource ('a pending member'), and the key identifier ('membership request ID'). This clearly distinguishes it from siblings like skool_members_reject and skool_members_pending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'pending member' tells the agent this tool is for accepting membership requests, and the auth requirement sets a clear precondition. It does not explicitly name alternatives, but the context of siblings makes the intended use unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 implies a read operation ('list ... returns') and names the returned fields plus pagination support, which is useful. But it stays silent on whether pending members are included, page size defaults, ordering, and how pagination terminates — meaningful gaps given the sibling skool_members_pending.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero filler: the action and resource are front-loaded, and the return-field enumeration earns its place. Nothing could be trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity read tool with two optional parameters, no annotations, and no output schema, the description covers the action, key return fields, and pagination — enough for an agent to invoke it correctly. The remaining gaps are page size/default limit and whether pending members are excluded, which are moderate for someone paging through a full member list.

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

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

Schema description coverage is 100%, with both page and community having inline descriptions. The description's mention of 'pagination' and 'community members' mostly echoes the schema rather than adding new semantic detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"List community members with pagination" states a specific verb and resource, reinforced by the return fields (name, bio, role, online status), which clearly separates it from posts, courses, and notifications siblings. However, it does not explicitly differentiate itself from skool_members_pending, so an agent must infer whether this covers all members or only approved ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus skool_members_pending, skool_members_approve, or skool_members_reject. The only operational note — 'Uses default from config if omitted' — lives in the schema, not the description, and concerns parameter behavior rather than tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full behavioral burden. It discloses the authentication and authorization requirement, which is valuable, but it does not mention output format, pagination, ordering, or empty-result behavior. Some behavioral context is provided, but gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. The primary action is front-loaded, and the important auth requirement is stated immediately after, making it easy to parse and act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with one optional parameter and no output schema, the description covers the essential invocation details: what it lists and the auth context. It could add pagination or response-shape notes, but the low complexity and the schema-covered parameter make the current description reasonably complete.

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

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

The input schema already documents the single 'community' parameter at 100% coverage, including its type and default behavior when omitted. The tool description adds no parameter detail beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and a precise resource ('pending membership requests'), making the tool's function immediately clear. This also distinguishes it from siblings like skool_members_list, which lists confirmed members rather than pending requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states an important usage context: it requires auth cookies with admin/moderator access. This tells the agent when the tool is callable and implies it is for moderation workflows, though it does not explicitly name alternative tools or exclusion conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 and that the target must be pending, but it does not mention side effects, reversibility, or what happens after rejection. This is acceptable but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no wasted words. The core action is front-loaded, and the auth requirement is placed in a separate, clear sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool, the description covers the action, the identifier, and the required permission level. It is not exhaustive about return values or side effects, but it provides enough context to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal extra meaning beyond clarifying that memberId refers to a membership request ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Reject'), the target object ('a pending member'), and the specific identifier ('membership request ID'). It is distinct from the sibling tool skool_members_approve, which handles the opposite action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: rejecting a pending member by their request ID. It also states an important precondition (admin/moderator auth). However, it does not explicitly name alternatives 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.

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. 'Tries the Next.js notifications page data route' hints at a fragile or unofficial implementation path, but it does not explain auth requirements, failure behavior, rate limits, or whether the operation is strictly read-only. The word 'Tries' signals unreliability without clarifying consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the primary purpose. The second sentence adds implementation context, though it is vaguer than ideal. Overall, it is efficient and has no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description is minimally sufficient, but it lacks details about what the returned notifications look like, how pagination behaves, and what happens when the Next.js data route fails. Since there is no output schema, some of this burden falls on the description.

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

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

Schema description coverage is 100% because the only parameter, 'page', is described as 'Page number'. The tool description adds no extra semantic detail about pagination or how the page parameter interacts with 'recent notifications', so the schema already carries the necessary information and the description adds little beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get recent notifications') and clearly identifies the tool's subject, distinguishing it from siblings like skool_members_list and skool_posts_list. The added 'Tries the Next.js notifications page data route' introduces some uncertainty but does not obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies the tool should be used when an agent needs recent notifications, but there is no explicit guidance about when to prefer it over alternatives or any preconditions. No sibling tool directly duplicates notifications, so the usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations exist, so the description carries the full disclosure burden, and it does contribute two useful behavioral facts: auth cookies are required and the call targets api2.skool.com. However, it never explicitly flags the write/mutation character or its side effects, and it says nothing about error behavior, rate limits, or reversibility. This is more than a bare statement but leaves meaningful gaps for a mutation with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the purpose front-loaded in the first and auth/endpoint details in the next two. There is no filler, no repetition of schema content, and nothing an agent would want to skim past. The size fits the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-string-param tool with fully documented schema properties, the description covers the what, the auth prerequisite, and the endpoint. But with no output schema and no annotations, an agent has no indication of the expected response shape or how failures surface. A sentence on return value or success/failure semantics would close the remaining gap.

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

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

Schema description coverage is 100% — postId (post UUID), content (comment text), and groupId (group UUID) are each already meaningfully documented. The tool description adds nothing param-specific beyond the word 'post,' which maps to postId. Since the schema does the heavy lifting, baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb (Add) with a concrete resource (a comment on a post), so the operation is immediately identifiable. This implicitly distinguishes it from sibling tools like skool_posts_create (which creates the post itself) and skool_posts_list/get (which read posts). No other sibling handles comments, so an agent can confidently select this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case — posting a comment to an existing post — is clear from the purpose statement, but there is no when-not-to-use guidance and no named alternatives. The 'Requires auth cookies' remark is the only practical precondition offered. The agent is left to infer how this differs from skool_posts_create or what conditions make it inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden. It adds useful behavioral details: 'Requires auth cookies' and 'Posts to api2.skool.com,' which inform the agent about authentication and the target endpoint. However, it does not disclose side effects, reversibility, error behavior, or what happens on success. The added context is valuable but far from comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short, front-loaded sentences with no redundant words. The purpose statement comes first, followed by two concise behavioral details. Every sentence earns its place, and the structure is easily scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four parameters (three required), no output schema, and no annotations. The description covers purpose, authentication, and endpoint, but it does not explain the expected response, how to obtain the optional label, or whether content supports formatting. While the schema covers parameter semantics, the lack of return-value information and behavioral expectations makes this minimally complete but with clear gaps.

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

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

Schema description coverage is 100%, so all four parameters have meaning in the schema. The tool description adds no additional parameter-level information. Per the baseline rule, a 3 is appropriate when the schema fully documents parameters and the description does not compensate further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Create a new post in a community.' This clearly distinguishes it from sibling tools like skool_posts_list, skool_posts_get, and skool_posts_comment, whose names imply different actions on posts. No ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating a post, but it does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tools. The only contextual hint is the prerequisite 'Requires auth cookies,' which is a precondition rather than selection guidance. The verb and resource make the intended use reasonably inferable, so it earns a 3.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral disclosure burden. It does usefully state that the response includes full content and comments, but it omits other behavioral context such as what happens when the slug is invalid, whether community defaults matter, or any rate/error behavior. The 'get' verb implies read-only safety, but no explicit safety statement is made.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences: first states the action and outcome clearly, second provides the required input. There is no filler or repetition; every sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter get operation with no output schema, the description is largely complete: it states what is returned (full content and comments), where to obtain the required slug, and the schema covers the optional community parameter. It could be slightly richer by mentioning default community behavior or error/not-found handling, but these are minor gaps for this tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents both postSlug and community. The description only repeats the slug source ('name field from posts list') already present in the schema, adding no new semantic information about the community parameter or value formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a single post with full content and comments, using the specific verb 'get' and resource 'single post'. It naturally distinguishes itself from sibling tools like skool_posts_list by emphasizing 'single', and it specifies the required identifier ('post slug').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: you use it when you need a single post's full content and comments, and you need to have the post slug from a posts list. However, it does not explicitly name alternatives or state when not to use it, such as 'use skool_posts_list to browse posts first'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations available, the description carries the behavioral disclosure burden. It clearly communicates a read-only list operation, explicitly identifies the response contents (title, preview, author, likes, comment count), and notes pagination support. It stops short of mentioning auth requirements or pagination response structure, but for a simple list tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each with a distinct job: state the operation, state filtering/pagination, and state the returned fields. There is no filler, repetition, or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with four documented optional parameters and no output schema, the description plus input schema covers what the tool does, how to filter and page, and what response fields to expect. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% and every parameter already has a descriptive comment: page is 1-based, sort defines enum meanings, category is a UUID, and community is a slug with a config default. The description's mention of filtering and pagination adds no semantic detail beyond the schema, so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List posts in a community feed.' It adds scope with filtering and pagination and enumerates the returned fields, which clearly distinguishes it from sibling tools like skool_posts_get, skool_posts_create, and skool_posts_comment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to call the tool — whenever a post feed listing with optional filtering is needed — but it provides no explicit guidance about when to prefer it over alternatives such as skool_posts_get for full post details, or 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.

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

It discloses useful behavioral details: the request is authenticated, and cookies and User-Agent are injected automatically. However, it does not mention side effects of DELETE/PUT/PATCH, error behavior, response format, or any limits. Without annotations, the description carries a fairly heavy burden and only partially covers it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The primary action is front-loaded, and the automatic authentication behavior is stated in a separate clear sentence. It is appropriately scoped for a generic request tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema makes the request constructible, and the description explains its purpose and authentication behavior. However, with no output schema and no guidance on when to use this tool versus the specialized siblings, the description is minimally sufficient but not fully complete.

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

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

The input schema provides full descriptions for all four parameters (100% coverage), so the description adds no additional parameter meaning. This is exactly the baseline case where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Make an arbitrary authenticated HTTP request') and the resource ('any Skool URL'). It differentiates itself from the specialized sibling tools by emphasizing its general-purpose nature and explicitly mentions 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case ('API discovery and debugging') but does not explicitly say when to prefer it over specialized siblings or when not to use it. Usage is implied rather than stated with dosage or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.