Skool by Cotlet

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

Adds real context beyond the annotations: append ordering, no notifications sent, reversibility via delete_group_link, and an explicit instruction that confirmation is unnecessary. That last point sits in mild tension with destructiveHint=true, but since the operation is additive and reversible the description is clarifying rather than contradicting the annotation. Return shape ('the whole new list') is also disclosed, though nothing is said about duplicate links given idempotentHint=false.

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 tight sentences with the action and its placement front-loaded, followed by the authorization and safety facts. The 'as Settings, Links, Add does' analogy is slightly wordy but does convey placement concretely; no sentence is 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 3-parameter mutation with no output schema, the description covers authorization, reversibility, notification side effects and the return value ('the whole new list'). Only the duplicate/non-idempotent case and any rate or quota limits are left unaddressed.

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 each of the three parameters carries its own description, including format and maxLength on url and label. The description adds no parameter-level detail beyond the notion of sidebar placement, so the schema is doing the work — baseline 3.

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?

A specific verb and resource ('Add a link to the group's sidebar') that an agent can immediately separate from update_group_link, delete_group_link and list_group_links in the sibling set. The append-position detail ('after the existing ones') further pins down what kind of add this is.

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?

States the authorization gate ('Admins only') and the rollback path ('undone with delete_group_link'), which tells the agent when this is safe versus when to reach for update/delete. It doesn't explicitly contrast with update_group_link for the case where a link already exists, so it falls just short of full when/when-not guidance.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is met, and the description still adds real signal: append-only ordering, the full list is returned, no one is notified, and 'runs without asking first' explicitly tells the agent no confirmation prompt is expected. The undo path via delete_group_rule reconciles destructiveHint with reversibility rather than contradicting 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?

Front-loaded with purpose and packed with useful context in a few clauses. There is mild redundancy between 'at the end of the group rules' and 'after the existing ones', and the UI analogy adds length without new 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?

No output schema exists, and the description compensates by stating that the whole new rule list is returned. Combined with the admin gate, notification behavior and undo path, everything needed to call this correctly and anticipate its effects is present.

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 per-field documentation for group, title (including the 30-char limit) and description, so the schema carries parameter meaning. The description adds nothing about parameter format or constraints, which is acceptable at this coverage level but is baseline only.

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?

States a specific verb+resource plus positional semantics ('at the end of the group rules', 'after the existing ones'), which cleanly separates it from update_group_rule and delete_group_rule. The 'Settings, Rules, Add' analogy pins the exact user-facing operation.

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?

Gives a hard prerequisite ('Admins only') and names the inverse operation ('undone with delete_group_rule'), so an agent knows the entry and exit points. It stops short of saying when to prefer update_group_rule over adding a new rule when a similar rule already exists.

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?

Goes well past the annotations: it discloses the admin-only requirement, the platform caps (3 questions, one email type), that answers surface in list_membership_requests, that it runs without confirmation, and that nobody is notified. The destructiveHint=true annotation is not contradicted, and the subscription/notification behavior is exactly the kind of context annotations cannot express.

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?

Front-loaded with the purpose, then prerequisites, limits, and return behavior in a tight sequence. Slightly dense and the "Adds a membership question, as Settings, Membership questions does" clause partly restates the opening, but there is no 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?

With no output schema, the description usefully says "Returns all questions," and it covers auth, limits, and side effects. It stops short of saying what happens on the 4th question or a second email question (error vs. silent ignore), which matters for a capped mutation.

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 group, question, type, and options. The description only indirectly adds meaning by noting "only one of type email"; it says nothing about the options array or type defaults beyond what the schema states. Baseline 3 is right.

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?

Specific verb plus resource ("Add a question people answer when they ask to join the group") and it anchors the concept to the UI equivalent (Settings > Membership questions), which disambiguates it from update_membership_question and delete_membership_question in the sibling list.

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?

"Admins only" gives the authorization prerequisite and "Skool asks up to 3 and only one of type email" gives the hard limits that determine whether a call will succeed. It doesn't explicitly route to update_membership_question when a question already exists, which is the one remaining gap.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description usefully adds the AutoDM side effect, the admin/moderator authorization requirement, and the default per-call confirmation. 'Waits for the owner's approval' is vague and sits awkwardly next to the confirmation sentence, leaving the actual wait/async behaviour unclear.

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 AutoDM sentence is duplicated verbatim, and the trailing 'Waits for the owner's approval.' is a dangling fragment that adds ambiguity rather than information. Signals are buried rather than front-loaded.

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 two-parameter mutation with a full schema and rich annotations, the description covers side effects and permissions, but the duplicated sentence and dangling wait clause leave the confirmation/waiting semantics genuinely ambiguous.

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%, so baseline is 3. The description adds a mapping note ('member_id is the id of the membership, the same as request_id'), but since no member_id parameter exists this is noise that could make an agent look for a nonexistent field.

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?

States a specific verb and resource: 'Approves one pending request, so the applicant becomes a member', with the analogous Skool 'Approve' button for grounding. It is distinguishable from decline_membership_request by implication, though that sibling is never named.

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?

Adds a permission gate ('Admins and moderators only') and a confirmation-behaviour note, but never states when to approve versus decline, nor what preconditions (e.g. how to obtain request_id) apply beyond the schema's pointer to list_membership_requests.

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?

Goes well beyond the annotations (destructiveHint, openWorldHint, idempotentHint=false) by disclosing that delete_recent_posts is irreversible, that a paid subscription is not cancelled, that each call is confirmed by default with an opt-out, and that the call waits for owner approval. These are exactly the operational traits an agent needs before invoking a destructive tool.

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?

Destructive scope and admin restriction are front-loaded, which is right, but the middle section is choppy and repetitive ('as Membership settings, Ban does') and the standalone fragment 'Admins and moderators.' reads as contradictory leftovers. Every sentence is informative, but the phrasing costs clarity.

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 destructive, approval-gated mutation with no output schema, the description covers irreversibility, side effects (subscription untouched), confirmation behavior, and approval latency. The only real gap is the unresolved whether-moderators-can-ban ambiguity and the member_id/membership_id relationship.

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%, so the baseline is 3, but the description adds real semantic weight beyond the schema: delete_recent_posts is irreversible and also removes comments, and the tool acts on a single member. It does not explain the member_id vs membership_id distinction, which remains a schema-only detail.

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?

States a specific verb and resource ('Ban a member from the group') plus the optional scope ('optionally deleting their recent posts'). It explicitly distinguishes itself from the sibling remove_member ('remove_member lifts a ban') and clarifies batch scope with 'Bans one member', so an agent can pick it without opening 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?

Gives a clear precondition ('Admins only') and names the contrasting alternative ('remove_member lifts a ban'), which is the key routing decision. It stops short of a full when-not-to-use rule and the later fragment 'Admins and moderators' muddies the permission condition it just set.

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?

Beyond the annotations, the description discloses important behavioral traits: the comment appears under your name, each comment is confirmed by default, confirmation can be switched off for this tool, and the action waits for owner approval. These details materially help an agent understand the interaction flow and approval gate.

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 front-loaded and efficient, starting with the core action and then explaining reply behavior and confirmation. The first two sentences overlap somewhat, but the structure remains easy for an agent to parse.

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?

Given four parameters, full schema coverage, and useful annotations, the description is complete enough to invoke the tool correctly. It covers reply behavior, identity, confirmation, and approval, though it does not describe what happens after approval or what response to expect.

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 are already documented. The description reinforces the meaning of parent_comment_id as a reply mechanism, but it adds little beyond what the schema already provides for body, group, and post_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 states a specific verb and resource: commenting on a post or replying to a comment. It clearly distinguishes between adding a top-level comment and adding a reply via parent_comment_id, so an agent can tell exactly 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?

It explains the key conditional behavior: set parent_comment_id to reply under an existing comment, otherwise comment on the post. It also notes default confirmation and owner approval, but it does not name alternative sibling tools or explicitly state when not to use this tool.

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?

Annotations already establish read-only, non-destructive, non-open-world behavior. The description adds useful context beyond that: authentication requirements, additional cost signal ('Free'), the status categories the response will contain, and the fact that a console link accompanies a recommended user step.

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 definition is compact and front-loads the returned status information, with prerequisites stated briefly afterward. The status list is dense but each clause carries meaning, and there is little wasted 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 read-only lookup with one optional filter, full schema coverage, and annotations covering safety, the description supplies the important behavioral and return-value context an agent needs. Remaining gaps are minor, such as not stating whether omitting the filter returns all apps.

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?

There is one optional parameter, and the schema fully documents it as 'Only this app, e.g. skool.' The description does not mention the filter parameter at all, but with 100% schema description coverage 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 states a specific resource (the user's workspace apps) and the exact status dimensions returned: access granted/requested, Cloud Browser account state, and next step with console link. It is clear what the tool reports, though it does not explicitly name or contrast with the sibling cotlet_request_apps 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 text gives prerequisites ('Free. Needs the user's Cotlet API key or sign-in.') but no when-to-use guidance or explicit alternatives. An agent must infer that this is the read-only counterpart to cotlet_request_apps, and there is no stated condition for selecting this tool over that sibling.

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?

Goes well beyond the destructive/openWorld/non-idempotent annotations by disclosing that the agent is acting as the logged-in user, that payment and sign-in flows are blocked, that the session accrues credit cost per started minute, and that the session closes after 3 minutes of inactivity. These are exactly the side effects and constraints an agent needs before clicking.

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?

Four short sentences, front-loaded with what the tool does and what it returns, followed by the refusal rules and cost/timeout constraints. Every sentence carries information the agent would otherwise have to guess.

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?

There is no output schema, and the description supplies the return shape (URL and title after the click). Combined with the refusal rules, the acting-as-user note and the session cost/timeout, nothing material is missing for a one-parameter click tool.

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 the single parameter already documents that it is 'the element's number in the element list of the current page'. The description restates that indexing scheme consistently but adds nothing further, such as where the element list comes from, so it sits 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?

States a specific verb (clicks), a specific resource (a link, button or other element of the current page), how the target is identified (its number in the element list), and what comes back (URL and title). That is enough to separate it from cotlet_browser_press, cotlet_browser_type and cotlet_browser_navigate without opening any 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?

Gives clear operating conditions: it acts as the user on the site, and clicks on pay/buy buttons or account/sign-in pages are refused, which tells the agent when this tool will fail. It also flags the per-minute credit cost and the 3-minute idle timeout. It never names a sibling alternative (e.g. press vs click), so it stops short of a full when/when-not routing statement.

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?

Annotations only declare the safety profile (non-read-only, idempotent, non-destructive). The description adds genuinely new behavior: state is preserved rather than destroyed ('keeps its cookies, goes to sleep'), billing stops, and the call returns minutes and credits. That is exactly the context annotations cannot convey.

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 clauses, front-loaded with the core action, then consequences and return value. No sentence is redundant.

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 no-argument tool with no output schema, the description covers what happens to state, what happens to cost, and what comes back. Nothing an agent needs in order to invoke it correctly is missing.

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 tool takes zero parameters, so there is nothing to disambiguate; baseline of 4 applies. The description correctly implies the session is identified implicitly (the user's browser) rather than by an argument.

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?

States a specific verb (ends) and resource (the session in the user's Skool Cloud Browser), which is unambiguous against the other cotlet_browser_* tools that manipulate a live page rather than terminate it. The agent can identify the operation without opening 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 billing note ('the per-minute charge stops') makes the motivating context clear: call it when finished browsing to stop cost accrual. It stops short of explicit exclusions (e.g., whether closing is safe mid-navigation, or an alternative to leave sessions open), so it is clear context without full when/when-not guidance.

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?

Goes meaningfully beyond annotations by disclosing billing behavior (every started minute costs credits) and session lifetime (ends on close or 3 minutes after the last call) — context the readOnlyHint/openWorldHint flags do not convey. It does not cover failure or redirect behavior, keeping it short of a 5.

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 tightly packed sentences, zero waste: what it does and returns first, scope restriction second, cost/session mechanics last. Front-loaded and every clause 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?

With no output schema present, the description correctly states the return values (final URL and title), plus cost and session-lifetime context. The only material omission is its relationship to the other browser tools, notably `cotlet_browser_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 coverage is 100% with a single documented `url` parameter, so the baseline is 3. The description only re-emphasizes the public http/https requirement and the Skool-pages restriction, adding little syntax or format detail beyond the schema.

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?

States a specific verb and resource (opens a public http/https address in the Skool Cloud Browser) and names what it returns (URL and title it ended on). It is clear on its own, but it never disambiguates against the sibling `cotlet_browser_open`, which an agent could easily confuse with navigation.

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?

Provides one real constraint — 'Only Skool pages open' — and mentions credit cost and session lifetime, which implicitly frames usage. But it gives no explicit when-to-use vs `cotlet_browser_open`/`cotlet_browser_close` guidance, leaving the sibling split to inference.

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?

The description adds substantial behavior beyond the annotations: the browser is a real Chrome signed in as the user, the user watches every step live, every started minute costs credits, and the session ends when closed or after three minutes without a browser call. It also states that the tool returns the page URL and title. These are critical operational details for a stateful, billable browser session.

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: it identifies the browser, explains when to use it, then covers URL opening, return values, live visibility, and billing/session lifetime. Every sentence adds relevant information without repetition.

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?

Given no output schema, the description explains what is returned: the page's URL and title. It also covers authentication context, use case, billing, and session termination, which is enough for an agent to invoke this browser-opening 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%, and the single optional url parameter is already documented with format and examples. The description adds only that the URL is opened when given, which is useful but does not go meaningfully beyond the schema.

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 action and resource: it wakes the user's Skool Cloud Browser, a real Chrome hosted on Cotlet and signed in as the user, and can open a URL. The 'wakes' framing distinguishes it from browser interaction siblings such as cotlet_browser_click or cotlet_browser_navigate, and the 'Skool tools do not cover' clause separates it from native Skool API tools.

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?

It gives clear usage context: use this for tasks the Skool tools do not cover, and it can open a URL when provided. It stops short of explicitly naming when to use cotlet_browser_open vs cotlet_browser_navigate or other browser siblings, so the alternative routing is only partially specified.

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?

Adds substantial context beyond the annotations: the return value (URL and title after the keypress), the account-page refusal rule, the credit cost per started minute, and the session lifetime (closed explicitly or 3 minutes after last call). Nothing here contradicts destructiveHint=true, which is consistent with keys that submit forms or dismiss dialogs.

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?

Front-loaded with purpose and key semantics, then return value, then constraints. Every sentence carries information, though the session-billing sentence is operational metadata that sits slightly apart from the keypress semantics.

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 single-param tool with no output schema, the description supplies the missing return shape, the refusal condition, and the session lifecycle. An agent can call this and understand the outcome without further lookups.

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 schema's own description is just 'The key.' with a 15-value enum, so the description carries real weight by explaining what Tab, Enter, Escape and the arrow keys actually do and by flagging that Enter is conditionally refused. It does not explain the remaining enum values (Backspace, Delete, Space, PageUp/Down, Home/End), so it adds meaning without fully covering the enum.

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?

States a specific verb and resource (press one key), the exact scope (current page, element with focus), and the browser instance (Skool Cloud Browser). The key-effect examples make it trivially distinguishable from cotlet_browser_type (text entry) and cotlet_browser_click.

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?

Gives concrete use cases per key (Tab to next field, Enter to send, Escape to close dialogs, arrows through suggestions) and an explicit exclusion: Enter is refused on account pages. It stops short of naming the sibling tool to use for typing text or clicking, so routing to alternatives 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?

Adds substantial behavioral context beyond the annotations: a hard 20,000-character limit, the fact that both text and links start near the current scroll position on long pages, explicit non-return of field values/cookies/storage, credit cost per started minute, and session termination after close or 3 minutes idle. These are exactly the operational details an agent needs and are not covered by the readOnly/openWorld annotations.

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?

Four sentences, each carrying distinct useful information: return payload, exclusion boundary, long-page behavior, and cost/session lifetime. It is front-loaded with what the tool returns and wastes no words.

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?

Given no output schema and zero parameters, the description is nearly complete: it explains return shape, limits, exclusions, scroll behavior, and session economics. It could be slightly more complete by naming alternatives for when reading is not appropriate, but for the tool itself nothing critical is missing.

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 tool has zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly focuses on output and behavioral constraints rather than inventing parameter guidance.

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?

States a specific verb ('Returns') and resource ('current page of the user's Skool Cloud Browser') and enumerates exactly what is returned: readable text up to 20,000 characters plus a numbered list of links, buttons, and fields. An agent can distinguish this from browser_screenshot or browser_click without opening any 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?

Usage is implied by the purpose—read the current page—but the description never explicitly says when to use this instead of siblings like cotlet_browser_screenshot, navigate, or click. It also doesn't give prerequisites such as needing an open browser session, though the cost note hints at session behavior.

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?

Goes well past the annotations (which already declare readOnly/idempotent/non-destructive) by disclosing the output format (JPEG, visible viewport only), the cost model ('every started minute of the session costs credits') and the session lifecycle ('ends when closed or 3 minutes after the last call'). Those are exactly the facts an agent needs to avoid surprise credit burn.

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, front-loaded with the return value and scope, then the cost/lifecycle caveat. No filler, and the ordering puts the call decision before the billing detail.

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?

With no parameters and no output schema, the description carries the burden and mostly meets it: format, viewport-only framing, and included URL/title are all covered. Minor gaps remain on image resolution or what happens if the browser isn't open, but nothing that would cause a wrong call.

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 tool takes zero parameters, so the baseline is 4; the description correctly implies a no-argument call and adds no misleading parameter talk. There is nothing further it could reasonably document on this axis.

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?

States a specific verb and resource plus the exact scope: 'Returns a JPEG image of the visible part of the current page in the user's Skool Cloud Browser', and adds that URL and title come with it. It functionally separates itself from the text-reading sibling by scoping to 'boards, canvases and layouts that the page text does not show', so an agent can tell which browser tool to call without opening either 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?

Gives a clear selecting condition — call this when the content is visual and 'the page text does not show' it — which implicitly routes text extraction to cotlet_browser_read. What's missing is an explicit naming of the alternative tool and any explicit 'don't use this when' exclusion, so the routing is inferred 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?

Goes well beyond the annotations by disclosing credit cost per started minute, session lifetime (ends on close or 3 minutes after last call), the lazy-loading behavior, and the return payload (URL, title, at_top, at_bottom). None of this is in the annotations, and there is no contradiction with readOnly/idempotent hints.

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?

Front-loaded with the action and its modes, then lazy-load behavior, then return and cost details; every sentence carries information. Slightly dense, with minor flavor ('as a person does'), but nothing is wasted.

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?

With no output schema, the description supplies the return shape, and it covers session lifetime, cost, and the lazy-content interaction that an agent must understand to chain this with reads. Nothing needed to invoke or sequence the call is missing.

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%, so each parameter is already documented, and the description mostly restates the schema's modes and the 0.8 default. It does clarify that `element` is matched against the element list and that screens applies to both up and down, but adds little beyond structured data.

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?

States a specific verb (scrolls) and resource (current page in the cloud browser) plus all three modes: relative by viewport heights, absolute to top/bottom, or until an element is in view. It is clearly distinguishable from siblings like cotlet_browser_navigate (which changes page) and cotlet_browser_read (which lists content), and even explains the scroll-load-then-read workflow.

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?

Gives clear context for use: load content that appears on scroll and then read it, which implicitly routes the agent to cotlet_browser_read afterward. It doesn't explicitly name alternatives or say when-not to use it (e.g., prefer navigate for a new URL), so it falls short of the full 5.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered; the description still adds value with the return value (URL and title), the refusal conditions, and the credit/session lifecycle (3 minutes after the last call). It stops short of saying what state is irreversibly changed or how to recover from a wrong selection.

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 core action is front-loaded in the first clause and every sentence carries information, but the final sentence about session credits is long and largely session-generic rather than specific to this 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?

With no output schema, the description correctly states what is returned (URL and title), documents both required parameters, and discloses refusals and cost. Complete enough to invoke correctly; only the exact failure behavior on refusal is unstated.

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%, so the baseline is 3. The description adds genuine meaning beyond the schema by clarifying that the option is matched by its label 'as read lists it (or its value)', which tells the agent both accepted forms of the second parameter.

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?

States a specific verb ('Chooses') and resource ('an option of a drop-down list'), plus the two coordinates it needs (list's number in the element list, option label/value). That is enough for an agent to tell it apart from cotlet_browser_click or cotlet_browser_type without opening 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?

Gives a real exclusion boundary: 'Card fields and account pages are refused.' It also implies usage context via the session/credit note. It does not, however, name a sibling alternative for when the target is not a select element, so no explicit 'use X instead' routing.

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?

Beyond the destructive/openWorld/non-idempotent annotations, the description discloses three real behaviors: refused field classes, credit cost per started minute, and a 3-minute idle session expiry. It doesn't say whether typing replaces or appends to existing field content, or what happens on an invalid element number.

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 tight sentences: action, return value, then safety/cost caveats. Front-loaded and no filler, though the cost/session clause is slightly crowded into the same sentence as the refusal rules.

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?

With no output schema, mentioning the returned URL and title is valuable, and the refusal plus billing/lifetime rules cover what an agent needs to invoke safely. The remaining gap is the precondition of how the element list is obtained, which matters for a page-dependent tool.

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 three parameters are already documented. The description restates element ('field's number in the page's element list') and submit ('presses Enter') without adding syntax, limits or edge cases beyond the schema; 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?

States a specific verb (types text), resource (a field on the current page in the Skool Cloud Browser), and the addressing scheme (element number in the page's element list). Easy to distinguish from siblings like cotlet_browser_click, cotlet_browser_press and cotlet_browser_select.

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?

Explicit exclusions are given ('Password, card and one-time code fields and sign-in pages are refused'), plus the submit/Enter condition. What's missing is positive routing: it never says to call cotlet_browser_read or cotlet_browser_screenshot first to obtain the element list, nor what to do when the field isn't already known.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, so the safety profile is covered. The description adds genuinely non-structured facts: a 10-file / 20 MB cap, the return payload ('URL and title'), a credit cost per started minute, and the session lifecycle ('ends when closed or 3 minutes after the last call'). It does not say whether an existing file in the field is replaced, which is the one behavioral gap left.

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?

Front-loaded with the action and the two target mechanisms, then the file format, then the return value and cost model. Nearly every sentence carries information. The trailing session/credit sentence is operationally relevant but appended rather than integrated, and 'Returns the URL and title after it' is slightly awkward phrasing.

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?

With no output schema, the description correctly fills that role by naming the returned URL and title, and it covers size/count limits plus session expiry — enough for an agent to call it correctly and plan follow-up calls before the 3-minute window lapses. Missing: what happens to a file already present in the field, and any explicit signal of whether the upload is async or awaited.

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 both 'element' and 'files' are already documented by the schema, and the baseline for that case is 3. The description reinforces the two file source shapes (url vs file_id) and adds a 20 MB per-file limit absent from the schema, but contributes no syntax or indexing detail beyond what is already structured.

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?

A specific verb ('puts files') plus two concrete target mechanisms: a file field on the current page or a file picker opened by an upload button, scoped to the Skool Cloud Browser and addressed by element number. That is far more than a restatement of the name. It misses explicit differentiation from the sibling cotlet_upload_file, so an agent must infer that this one operates inside a live browser session while the other targets Cotlet storage.

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 tells the agent the condition under which this tool applies ('into a file field of the current page... or into the file picker that an upload button opens'), which is a clear triggering context. It also hints at the sibling relationship by noting a file_id must be 'uploaded to Cotlet first', implicitly routing to cotlet_upload_file as a prerequisite step. No explicit exclusions or named alternative are given, keeping it below a 5.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes the status vocabulary and the polling context, but says nothing about behavior for an unknown or expired call_id, retention window, or whether repeated polling is rate-limited.

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, front-loaded with the resource and key, with the status set inlined rather than padded into separate sentences. The trailing 'answered with status pending or running' is slightly awkward phrasing but earns its place as scoping 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 one-parameter read tool with no output schema, the description supplies the crucial return-value information (the full status enum) that the structured fields omit. Only minor gaps remain, such as what accompanies the status in the response.

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?

There is a single required parameter with 100% schema description coverage, so the schema already carries the semantics. The description's 'by its call_id' merely restates the schema and adds no format or sourcing detail (e.g. where the call_id came from).

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?

States a specific resource (an earlier Cotlet call) and a specific retrieval (its status, keyed by call_id), and enumerates every terminal and intermediate state so the agent knows exactly what it will get back. No sibling tool overlaps this resource, so the lack of an explicit 'not for X' does not create ambiguity.

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 closing clause scopes it to calls whose prior response was pending or running, which effectively tells the agent this is a polling tool rather than a general history lookup. It stops short of naming an alternative or saying what to do once a terminal status is reached.

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?

Annotations already declare this is a non-readonly, non-destructive, non-idempotent write, so the description only needs to add context. It does: it states where the report goes, that error text and call_id are attached when available, that secrets are never included, and that an API key or sign-in is required. It does not mention what happens on duplicate submissions, consistent with idempotentHint=false but not explained.

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 dense sentences, front-loaded with the action and its goal, then the trigger scenarios, then the content and auth constraints. No filler and nothing repeated from the title or annotations.

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 mutation tool with no output schema, the description covers purpose, triggers, attached payload, secret handling and authentication, which is enough to call it correctly. It omits what the caller receives back or whether filing duplicates creates separate reports, a minor gap for a write tool.

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%, so enum values for `kind` and field meanings for `tool`, `app` and `call_id` are already documented in the schema. The description adds only marginal meaning, clarifying that call_id and error text are picked up automatically when present, which is the baseline expectation given full schema documentation.

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 names a specific verb and resource ('Sends a report straight to the Cotlet team') and enumerates the concrete situations it covers: failed or wrong-data tools, blockers, missing tools/fields/apps. It stops short of explicitly distinguishing itself from the sibling cotlet_request_apps, which plausibly overlaps with the 'app the task needed and Cotlet lacks' case.

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?

Clear contextual triggers are given ('failed or returned wrong data', 'an error you could not get past', 'needed and Cotlet lacks'), which is enough for an agent to decide when to file a report. It offers no explicit exclusion or pointer to cotlet_request_apps / cotlet_get_call, so edge-case routing is left to inference.

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?

Adds substantial behavior beyond the annotations: a live app is granted immediately, other requests go to the Cotlet team with a 72-hour response window, the operation is free, and authentication via Cotlet API key or sign-in is required. The mutation-like but non-destructive nature is consistent with the annotations.

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 tight sentences with the core action front-loaded, followed by outcome behavior, slug source, cost, and authentication. No wasted words.

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 request tool with no output schema, the description provides everything needed to call it correctly: what it does, how outcomes differ, where to get valid slugs, and what credentials are required.

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%, so the schema already documents the apps parameter and slug examples. The description adds useful context by pointing to https://cotlet.dev/api/v1/apps as the canonical slug list, though it does not mention the maxItems limit.

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?

States a specific verb and resource: request access to apps for the user's workspace. It distinguishes this from informational siblings like cotlet_apps and cotlet_balance by describing an action that submits an access request and explains the two possible outcomes.

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 clearly frames the tool as the programmatic equivalent of 'Request access' in the console, which implies when to use it. It does not explicitly say to use cotlet_apps first to discover slugs, so a small inference remains.

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?

The description adds substantial behavioral detail beyond the annotations: it returns a one-time upload_url and file_id, requires an HTTP PUT to upload_url, enforces a 25 MB limit, states the URL works only once, and notes the Cotlet API key/sign-in requirement. These details are consistent with the non-read-only, non-destructive annotation profile and materially help the agent understand the workflow.

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 most important fact—what is returned and how it is used—is front-loaded in the first sentence. The remaining sentences cover upload method, size limit, one-time behavior, and auth without wasted words.

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?

There is no output schema, and the description fully explains the return values, the upload workflow, the file size constraint, one-time URL behavior, and authentication needs. An agent has enough information to invoke and chain this 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%, with both name and content_type documented with examples in the schema itself. The description does not add parameter-specific syntax or constraints beyond that, 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.

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

The description states a specific verb and resource: it returns a one-time upload_url and file_id for a local file. It also clarifies the intended use cases (an image for a post, an attachment), but it does not explicitly distinguish this helper from sibling tools such as cotlet_browser_upload.

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 usage context: call this to obtain upload_url and file_id, PUT the file to upload_url, then pass file_id to any argument that accepts a file. It does not name when-not-to-use cases or alternative tools, so it falls short of the top score.

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?

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds genuine value beyond them: it declares the call is credit-free ('Free') and that authentication via the user's Cotlet API key or sign-in is required, which matters for failure handling. It does not say what shape/format the response takes, but the field list largely compensates.

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: the first front-loads the substantive return contents, the second carries the cost and auth facts. No filler, no restatement of the title, and every clause 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?

There is no output schema, so the description must carry the return contract — and it does, enumerating each field the agent will receive. Combined with the required-auth note, an agent has enough to call it correctly. Only minor gaps remain, such as how failures look when the key is missing or what access-status values are possible.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Nothing in the text conflicts with the empty schema.

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 names a concrete resource — the Cotlet account identity for this connection — and enumerates exactly what comes back (email, workspace, access status, API key/OAuth client scope, callable apps, credit balance). That is far more specific than the bare 'who am I' title. It stops short of explicitly distinguishing itself from siblings like cotlet_balance and cotlet_apps, which overlap on the balance and app-list portions of the response.

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?

Usage context is implied rather than stated: an agent can infer this is the pre-flight identity/permission check, and 'Needs the user's Cotlet API key or sign-in' plus 'Free' tells it the prerequisites and that no credits are consumed. However there is no explicit 'call this before cotlet_apps or cotlet_balance to verify access' routing, and no stated conditions under which this tool should be skipped.

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?

Adds genuinely useful context beyond annotations: admin-only auth, immediate visibility to members, no notifications fired, and Skool auto-assigning the category color. It does not address duplicate handling or whether re-invoking creates a second category, which matters since idempotentHint=false. The destructiveHint=true annotation sits oddly against a create operation, but the description itself does not contradict 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?

Front-loaded with the action and audience, then the admin gate and behavior notes in short clauses. Minor redundancy between "Add a category to a group's feed" and "Adds a feed category," and the final sentence is a dense run-on, but overall it is tight.

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 4-parameter create tool with no output schema, the description covers auth, visibility, notification side effects, and the one non-obvious parameter's meaning. Missing only what the call returns (e.g., the new category identifier) and duplicate-name behavior.

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%, so baseline is 3, but the description earns above baseline by explaining the semantic effect of who_can_post=admins (announcements-style posting restriction) rather than just restating the enum. It contributes nothing about sort or the color assignment being non-configurable in params, so not a 5.

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?

Specific verb + resource ("Add a category to a group's feed") with a concrete UI analogue ("as Settings, Categories, Add does") that removes ambiguity about what is created. It is clearly a creation tool, distinguishable from update_category/delete_category/list_categories by verb alone, though no sibling is named explicitly.

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?

States the admin prerequisite ("Admins only") and gives a decision rule for the who_can_post=admins variant (announcements-style, only admins post). It also licenses acting without confirmation. It stops short of naming update_category as the alternative for changing an existing category, so no 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.

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

Beyond the annotations, it discloses who can invoke it (admins), the visibility consequence of each state (drafts visible to admins only, published shows to members immediately), and where related settings are configured externally. It does not clarify reversibility or what is returned, but the annotations already cover the mutation/safety profile.

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?

Front-loaded and reasonably short, but the draft/published behavior is stated twice ('as a draft or published' then 'as a draft unless published is true'), and the clause 'as Classroom, New course does' is awkward filler referencing UI behavior. It could lose a sentence without losing 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 5-param mutation tool with full schema coverage and annotations present, the description covers authorization, state semantics, follow-up tooling, and external boundaries. No output schema exists, but the return value is not something an agent strictly needs here; the remaining gap is minor.

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%, so the baseline is 3, but the description adds the access model behind min_level ('Open to all members, or only from min_level up') and clarifies that published=true publishes immediately versus a default draft. It also bounds scope by noting that paid and time-unlocked configuration is done elsewhere, which is genuinely useful context not in the schema.

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?

States a specific verb and resource ('Add a course to the group's Classroom') with a clear scope ('as a draft or published'), and explicitly points to the sibling create_lesson for the next step. It does not distinguish itself from set_course_published, which is the nearest overlapping sibling, so it falls short of a 5.

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?

Gives a real precondition ('Admins only'), a sequencing instruction ('Add lessons with create_lesson'), and a decision rule for the main branch ('A draft is seen by admins only, so it runs without asking first'). It also notes that paid and time-unlocked behavior lives in Skool. No explicit comparison against set_course_published is offered.

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?

The description adds substantial behavior beyond the annotations: members see the event immediately, calls are confirmed by default, confirmation can be disabled for this tool, Skool reminds members before the event, and creation awaits owner approval. These are meaningful side-effect and workflow details for a mutation tool, and they do not contradict the annotations.

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 front-loaded with the core purpose and stays reasonably compact. Some phrasing is repetitive or potentially ambiguous, such as 'as Add event does,' but overall it is well structured and not bloated.

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 an 11-parameter creation tool with no output schema, the description covers the important operational context: admin restriction, one-time event behavior, visibility, reminders, confirmation, and approval. It could be more complete on the return or pending-approval behavior, but the core selection and invocation context is present.

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 description names the main concepts such as title, start, length, time zone, location, and visibility, but the input schema already documents all 11 parameters at 100% coverage. It adds little parameter-level detail beyond what the schema already provides, 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 gives a specific verb and resource: adding an event to a group's calendar, with admin-only and one-time scope. It is clearly a creation tool rather than an update or listing tool, but it does not explicitly differentiate itself from nearby siblings such as update_event or list_events.

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?

It states the key usage constraint that the caller must be an admin and that this creates a one-time calendar event. That gives clear context for selecting the tool, but it does not explicitly say when to use this versus update_event, list_events, or other sibling tools.

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?

Beyond the annotations it discloses auth requirements (admin only), default publication behavior, draft-course visibility, the absence of notifications, and that it runs without asking first. Those are exactly the behavioral traits an agent needs and that annotations do not convey.

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 first two sentences and the third sentence repeat the same information ('Add a lesson at the end of a course' / 'Adds a lesson page at the end of a course'). The content is front-loaded and useful, but that duplication wastes space.

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 six-parameter mutation tool with no output schema, the description covers auth, defaults, visibility, side effects, and media limitations well. It does not say what is returned or how failures (e.g., invalid course_id) are surfaced, which is a minor 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains where the video link appears ('Skool plays above it'), what published=true/false does in a draft course, and that the lesson is appended at the end. It adds more than the schema alone 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 and resource ('Add a lesson at the end of a course') and scopes the content (text plus optional video link). It clearly separates this from update_lesson and create_course by implication but never names the siblings, so it falls short of the top score.

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?

It gives a clear admin-only prerequisite, an explicit exclusion ('Uploaded videos and files are not supported'), and notes that it runs without confirmation. It does not explicitly route the agent to update_lesson for edits, which keeps it from a 5.

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?

Goes well beyond the annotations: category name is validated before approval and fails immediately with the group's categories listed, posts are text-only, poll_options creates a poll under the text, and by default the call is gated on the owner's approval (which can be switched off). This is exactly the operational context annotations cannot express.

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?

Opens with the purpose, but the first two sentences say substantially the same thing ('Publish a post to the community feed in a category, as you' / 'Publishes a post to the group's feed in one of its categories, under your name'). The approval behavior is also split across the first and last sentences rather than consolidated.

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 five-parameter write tool with no output schema, the description covers the important unknowns: approval gating, fail-fast category validation, and the text-only media constraint. It does not touch on post visibility or what the call returns on success, but those are secondary.

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%, so the baseline is 3; the description adds real meaning by explaining that category names are checked up front and errors return the group's category list, that poll_options renders a poll under the text, and whom the author is.

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?

States a specific verb and resource ('Publish a post to the community feed in a category'), and clarifies authorship ('as you', 'under your name'). Sibling differentiation is only implicit via the name (create vs update_post/comment_on_post); nothing in the text explicitly routes away from those tools.

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?

Implies usage (publishing a new post into one of a group's categories) and warns that images/files are not supported, which steers an agent away from a wrong assumption. However, it never says when to prefer update_post or comment_on_post, nor any prerequisite such as needing a valid category or group membership.

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?

The annotations already mark this as destructive and not read-only, and the description adds useful context about admin/moderator permission, per-call confirmation, and an approval wait. The phrase "Waits for the owner's approval" is behaviorally relevant but somewhat ambiguous.

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, stating the action first and then adding constraints and behavior. Every sentence contributes relevant context without unnecessary detail.

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 destructive action with full schema coverage and annotations, the description covers the essential permission and confirmation context. It could clarify the owner-approval wait and error/return behavior, but no output schema exists and the core invocation needs are met.

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 two parameters are already documented. The description does not add parameter-level 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.

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

The description uses a specific verb and resource: "Decline an applicant's request to join." It also clarifies that the action applies to one pending request, making the operation distinct from related membership tools such as approve_membership_request.

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?

It states the permission context clearly: "Admins and moderators only," and explains the default confirmation behavior. However, it does not explicitly name approve_membership_request or list_membership_requests as alternatives, leaving that routing to sibling names and schema hints.

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?

Goes well beyond the annotations: posts are preserved and relocated to move_posts_to or the group's first other category, at least one category must remain, admin rights are required, and the call blocks on owner approval. It also discloses the per-call confirmation prompt and that it can be disabled for this tool—operational context annotations cannot express.

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?

Front-loaded with purpose and consequences, then constraints, then approval behavior. The sentence 'Deletes a category, as Settings, Categories, Delete does' partially restates the opening clause, a small redundancy in an otherwise tight paragraph.

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 destructive mutation with no output schema, the description covers everything an agent needs: permissions, data-preservation semantics, the at-least-one-category invariant, approval/confirmation flow, and the fallback parameter behavior.

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%, so the baseline is 3, but the description adds behavior the schema only hints at: the fallback when move_posts_to is omitted is 'the group's first other category,' and posts are moved rather than destroyed. No syntax or format detail beyond that.

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?

Opens with a specific verb+resource plus the side effect ('Delete a feed category and move its posts to another'), and anchors it to the familiar UI path (Settings, Categories, Delete). Clearly distinct from create_category, update_category, list_categories and delete_post in the sibling list.

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?

States the audience restriction ('Admins only') and the safety invariant ('A group keeps at least one category'), which tells an agent when the call is valid. It does not explicitly contrast with update_category or list_categories, so the alternative-routing guidance 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?

Although annotations already mark this as destructive and non-idempotent, the description adds important behavior beyond structured fields: admin restriction, irreversibility, whole-series deletion for recurring events, default confirmation, and owner approval. These details materially affect how an agent should invoke the tool.

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 front-loaded with the destructive action and constraints, and most sentences carry useful information. There is minor redundancy between the title, first sentence, and second sentence, but it remains efficient for a destructive 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?

For a destructive mutation tool with no output schema, the description covers the key operational facts an agent needs: permissions, scope, irreversibility, recurring-event behavior, confirmation, and approval. Little relevant context is missing.

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 explains both group and event_id. The description does not add further parameter-level meaning, which is acceptable but leaves it at the baseline for well-documented parameters.

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: delete a calendar event. It also clarifies scope by distinguishing single-event deletion from the recurring-series behavior, which helps an agent distinguish it from update_event or create_event.

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?

It provides clear context: admins only, deletion is irreversible, and deleting a recurring event deletes the whole series. It also mentions the default confirmation and owner approval, though it does not explicitly name alternatives such as update_event for modifying an event.

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?

Beyond the annotations, the description discloses admin-only authorization, the index-reshifting side effect ('the links after it move up a number'), the return payload ('the whole new list'), an approval gate, and a per-call confirmation default that can be turned off. These are exactly the behavioral facts an agent needs before invoking a destructive tool.

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 destructive action and its effect are front-loaded and every sentence carries information. There is minor redundancy between the opening sentence and 'Removes one sidebar link', which keeps it from a perfect score.

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 two-parameter destructive tool with annotations but no output schema, the description covers authorization, side effects, return value, and the confirmation/approval flow. Nothing essential to correct invocation is missing.

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%, so both parameters are already documented, and the baseline is 3. The description adds only indirect meaning about 'number' being a positional index via the renumbering note; it does not explain the group identifier, bounds, or failure on an out-of-range index.

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 ('Remove a link from the group's sidebar') and reinforces it with the UI analogue 'Settings, Links, Delete'. An agent can readily distinguish it from add_group_link and update_group_link without opening any 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?

'Admins only' and the note about the default per-call confirmation give clear operating context before the call is made. It does not explicitly name alternatives or exclusions (e.g., when to use update_group_link instead), so it stops 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.

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

The description adds substantial behavioral context beyond the annotations: deletion is admin-only, rules renumber after deletion, it returns the whole new list, confirmation is on by default but can be disabled, and it waits for owner approval. These details align with destructiveHint=true and idempotentHint=false.

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, front-loaded with the action, and every sentence contributes useful operational context. There is no filler or repetition.

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 destructive two-parameter tool with full schema coverage and rich annotations, the description covers the important missing pieces: admin restriction, renumbering side effect, return value, confirmation behavior, and approval flow.

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 group and number are already documented in the schema. The description adds some semantic context around deleting one rule and renumbering later rules, but it does not add further syntax or mapping beyond what the schema 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 opens with a specific verb and resource: "Delete a group rule." This clearly separates it from sibling operations such as add_group_rule, update_group_rule, and delete_group_link without requiring 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?

It gives the key usage constraint ("Admins only") and explains the effect relative to the Settings UI. It does not explicitly name alternatives such as update_group_rule for modifying a rule instead of deleting it, but the use case is otherwise clear.

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?

Beyond the destructive annotation, the description discloses important behavior: later questions move up a number, the remaining questions are returned, deletion happens without confirmation, and nobody is notified. This is exactly the kind of side-effect context an agent needs before deleting.

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, front-loaded with the action, and every sentence adds useful information: permission scope, renumbering effect, return value, and confirmation behavior.

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 two-parameter destructive tool with annotations covering safety flags, the description supplies the missing operational context: admin restriction, renumbering side effect, return behavior, and lack of confirmation or notification.

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 explains both 'group' and 'number' in detail. The description does not add parameter-specific meaning beyond the schema 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 first sentence names a specific verb and resource: 'Remove a membership question.' This clearly distinguishes it from sibling tools such as add_membership_question and update_membership_question.

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?

It states 'Admins only,' which gives a prerequisite, but it does not explicitly say when to use this versus update_membership_question or what conditions should block deletion. Usage is implied by the verb but not fully guided.

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?

Annotations already declare destructiveHint/idempotentHint, but the description adds real value beyond them: deletion cascades to a post's comments, there is no trash so it is irreversible, a per-call confirmation is on by default and can be switched off, and the call blocks on owner approval. That is exactly the behavioral context an agent needs before a destructive write.

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?

Irreversibility is stated three times ('for good', 'Skool keeps no trash', 'cannot be undone'), and 'as Skool's Delete does' plus the trailing 'Waits for the owner's approval' are ambiguous filler. The key scope and permission facts are front-loaded, but the sentences do not all earn their 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 parameter-light destructive tool with no output schema, it covers permissions, cascade behavior, irreversibility, and the confirmation flow. It omits secondary effects (e.g. what happens to likes, notifications, or the parent post when a comment is deleted), which keeps it from being 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?

Schema coverage is 100%, so both parameters are already documented, and the description's 'pass its comment_id' mostly restates the schema's note that post_id may be a comment_id. Slight friction: it says to pass 'comment_id' while the only parameter is named post_id, which could confuse argument construction. 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?

States a specific verb and resource ('Delete a post or a comment') and immediately distinguishes the two modes: a whole post with its comments, or a single comment. It also separates itself from the many other delete_* siblings by naming the exact object type it removes.

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?

Gives clear usage context: your own posts/comments always, anyone's only when you are a group admin or moderator. It also explains the comment-deletion path. It does not name alternatives (e.g. update_post to edit instead of delete), so it stops short of full routing guidance.

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?

Annotations already declare a safe, read-only, idempotent operation, and the description adds useful behavior beyond that: pagination size (30 per page), cursor reuse, and the fields returned. It does not discuss rate limits or ordering, but the key behavioral traits for a read-only discovery tool are covered.

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 front-loaded with the core purpose and stays compact. It packs in search scope, returned fields, pagination and exclusions without obvious repetition, though it is a dense sentence cluster rather than crisply structured bullet-like guidance.

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?

There is no output schema, so the description usefully names the result fields and explains pagination. It also states the discovery-surface scope and exclusion of hidden private groups, leaving only minor gaps such as result ordering and authentication expectations.

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 both parameters already have descriptions, including that omitting query returns top groups. The description adds the page size and cursor mechanics, but most parameter meaning is already in the schema, so this is baseline territory.

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?

States a specific verb and resource: searching Skool's public directory of communities, with fields like members, price and rating. The 'public directory' scope clearly separates it in spirit from list_groups or search_group, though it never names those siblings explicitly.

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?

Gives clear context for use: discovering public communities via skool.com/discovery, as the site's search box does. It also notes that private groups hiding from discovery are not listed, which clarifies result scope, but it does not explicitly route the agent away from list_groups or search_group as alternatives.

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?

Annotations flag destructiveHint=true, but the description usefully narrows that: the effect is confined to your own notification subscription and is safe to run without confirmation. That is real context beyond the structured hints. It doesn't describe the response or whether re-following an already-followed post is a no-op, which is the remaining gap given idempotentHint=false.

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 clauses, front-loaded with the core action and behavior, with no filler. Every sentence carries information an agent needs.

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 3-parameter toggle with no output schema and full schema coverage, the description supplies the states, the default, and the permission posture — enough to invoke correctly. A note on what a successful call returns or whether follow is a no-op when already following would close the last 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 coverage is 100%, so `group`, `post_id`, and `following` are already documented. The description's "following false unfollows" largely restates the schema's "false stops the notifications" and adds no new syntax or edge-case 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?

The description opens with a concrete verb and resource ("Get notified of new comments on a post, or stop") and immediately grounds it in a known UI behavior ("as the post menu's Follow does"). This clearly distinguishes it from sibling interactions like comment_on_post or like_post.

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?

It states the toggle semantics ("following false unfollows") and a useful precondition ("You follow your own posts from the start"), plus consent guidance ("changes only your own notifications, so it runs without asking first"). It stops short of naming any alternative tool, though no real sibling alternative exists for this action.

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?

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds the admin-only auth requirement and the exact return contents. The placeholder-substitution note (#NAME#, #GROUPNAME#) is genuine behavioral context not in any structured field.

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?

Front-loaded with what the AutoDM is, then the return shape, then the placeholder note. Slightly redundant, since the first and second sentences restate 'the message Skool sends every new member and whether it is 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?

No output schema exists, and the description compensates by enumerating the returned fields (message text, sender, enabled state) and explaining placeholder interpolation. Nothing needed to call it correctly is missing.

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?

Single parameter with 100% schema description coverage, so the schema already explains the group URL name format. The description adds no further syntax or constraint detail beyond that 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?

Names the specific resource (the group's AutoDM), states it is the message sent to new members on approval, and lists what is returned (message text, sender, on/off). It is clearly distinguishable from write siblings like set_auto_dm, but it never names the counterpart explicitly.

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?

'Admins only' gives the permission precondition, and the read-only framing implies when to use it. However, it never says when to prefer this over set_auto_dm or other group-inspection tools, leaving the read-vs-write choice to inference.

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?

Annotations already declare readOnly, idempotent and non-destructive. The description adds real behavioral value beyond them: reading does NOT mark the conversation read, and the returned 'from' value is 'You' for your own messages, versus a member_id otherwise. It omits cursor/pagination behavior beyond the limit cap.

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 opening is well front-loaded, but the first sentence is essentially repeated ('The latest messages ... oldest first. Returns up to limit latest messages ... oldest first.'), which is an obvious redundancy. The remaining sentences are lean, but the duplication wastes prime space.

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 parameters, strong annotations and no output schema, the description is nearly sufficient: it covers ordering, the limit cap, the sender field and the lack of read side effects. It could say more about the message payload fields (text, timestamps) since no output schema exists.

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%: both limit (1-100, default 50) and conversation_id (from list_conversations or send_message) are documented in the schema. The description's 'latest ... oldest first' clarifies what limit truncates in results, but it adds little about the parameters themselves, 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?

States a specific action and resource: read the latest messages of one Skool Chat conversation, oldest first. This clearly separates it from list_conversations (conversation metadata) and send_message (writes), both of which are present in the sibling list.

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?

Implies the read path after list_conversations and points at that sibling for member names, so the workflow is inferable. It does not state exclusions, such as how much history to pull versus other message-related tools, but the context is clear enough for 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is covered; the description adds genuinely new behavior: exact return shape (title, description, published flag), ordering, and the quirk that folders arrive as kind 'folder' immediately followed by their lessons. The permission scoping (account-visible courses, admins see drafts) is context an agent cannot get from annotations. No pagination or not-found behavior is disclosed.

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 return shape is front-loaded, but content is duplicated: 'with its lessons and folders' in sentence one is restated by 'its lessons in order' in sentence two, and get_lesson is described twice (once for what it reads, again for text and video). Trimming those repeats would lose nothing.

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?

With no output schema, the description carries the burden of explaining the response and does so well, including the folder/lesson interleaving that would otherwise surprise a caller. For a two-param read tool this is close to complete; only large-course/pagination behavior and failure modes are unaddressed.

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 both parameters (group, course_id) are fully documented in the schema, so the baseline applies. The description adds no extra syntax, format, or constraint detail about either parameter.

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?

States a specific verb+resource (retrieves one course) and immediately bounds the scope: the course plus its lessons and folders in Classroom order. It also names the natural confusion point, get_lesson, and what that sibling returns instead, so an agent can distinguish the two without opening either 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?

Explicitly routes the agent to get_lesson when it wants a single lesson's text and video, and the access note ('Only courses this account can open; admins also see drafts') tells it when results may be empty or partial. It does not explicitly point at list_courses for obtaining the course_id, though the schema covers that.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral context by enumerating returned fields: title, description, UTC start/end, time zone, location, and visibility. It does not describe error behavior or permission requirements, but it goes beyond annotations for a read operation.

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 compact sentences and front-loads the core purpose. There is minor redundancy between the first sentence's 'full description, place and access' and the second sentence's explicit field list, but it remains efficient.

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 read tool with no output schema, the description is adequately complete. It explains the return payload in enough detail for an agent to understand what will be retrieved, and annotations cover the safety profile.

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 both required parameters (group and event_id) are already well documented. The description does not add further meaning to these parameters, 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.

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

The description clearly states that the tool retrieves a single calendar event with details, distinguishing it from list-style siblings by specifying 'one event of the group's calendar.' However, it does not explicitly name or contrast with sibling tools like list_events or update_event.

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 guidance on when to use this tool versus alternatives. It implies retrieval of a single event but never states prerequisites, when-not to use it, or that event_id should come from list_events (that hint appears only in the parameter schema).

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?

Annotations already carry readOnly, idempotent, non-destructive and closed-world, so what the description adds is the important field-visibility rule: admins receive pending_requests, reported_posts and membership questions, while others see these as 0/empty. That is real behavior beyond structured metadata, though it doesn't discuss auth requirements or error cases for a nonexistent group.

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 first sentence front-loads the field inventory and the admin-vs-non-admin caveat comes last, which is the right order. There is mild redundancy in restating the field list twice ('name, About text, privacy, price, counts…' then 'name, the About text, whether it is private, the price…'), but every sentence still carries useful content.

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?

With no output schema, the description must carry return-shape information, and it does — enumerating the fields returned plus the conditional admin-only fields. It stops short of describing the container structure or what happens for an invalid group slug, so it is strong but not exhaustive for a read tool.

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?

There is a single parameter with 100% schema description coverage ('Group URL name, e.g. yourgroup for skool.com/yourgroup'), so the schema already covers the semantics fully. The description adds no format or slug-resolution detail, which fits the baseline-3 case for well-annotated single parameters.

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 names a specific resource ('A group's name, About text, privacy, price, counts, owner and membership questions') and clarifies it returns exactly one group as its About page/Settings show it, which implicitly separates it from list_groups and get_group_stats. It never names a sibling tool or explicitly states the single-vs-list distinction, keeping it just under a 5.

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 tool is contextually intelligible — fetch a single group's profile/settings — but the description contains no 'use this when' phrasing and does not mention alternatives such as list_groups, search_group or get_group_stats. Usage must be inferred from the resource name and the returned fields.

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?

Beyond the readOnlyHint/idempotentHint annotations, it discloses a non-obvious latency profile (~15s due to background computation) and the exact error an unauthorized caller receives (APP_PERMISSION_DENIED). It also explains how members_new is derived differently for 7d/30d vs 90d, which is behavioral detail the annotations cannot carry.

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 metrics and admin restriction are front-loaded, and the sentences are dense with useful detail. The 'Admins only' statement is repeated at the end, which is a minor redundancy, though the second instance adds the error code.

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?

There is no output schema, so the description carries the burden of explaining return fields, and it does so field by field (members_total, members_new, members_churned, MRR in USD). Combined with the latency and permission notes, an agent has everything needed to call and interpret the result.

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 the enum is already documented, but the description adds real meaning by explaining that period changes the computation method for members_new rather than just a window size. That is semantics beyond the schema's 'Default: 30d' note.

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 opening sentence names the exact metrics returned (total/new/churned members and MRR) and the scoping dimension (a period). It is clearly distinguishable from siblings like list_members, get_group, and get_leaderboard, which do not aggregate revenue or churn.

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?

It states an explicit precondition (admins only) and reiterates the failure mode, which tells the agent when the call will work. It does not explicitly contrast with alternative analytics sources (e.g. list_members or get_group), so it stops short of full when-vs-what-else guidance.

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?

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuinely new behavior: one point per like received, a recount every few minutes, and updated_at as a freshness signal. Minor gap: no indication of how stale a rank can be before update or what a missing rank looks like.

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 opening sentence is well front-loaded with scope and periods, but the second sentence largely repeats it ('top 10 members by points earned in the period') before adding only the like-based scoring and updated_at. Roughly one sentence of the two is redundant.

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?

With no output schema, the description must describe the return, and it does: top 10 entries, your own rank and points only when you are on the board, plus updated_at. What is missing is the per-member entry shape (name, avatar, points fields), which an agent would need to consume the result reliably.

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 the period enum is fully described in the schema, so baseline is 3. The description goes beyond it by defining what 'points' actually mean (one point per like received), which is the semantic an agent needs to interpret the period parameter; the group parameter gets no additional clarification.

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?

States a specific verb and resource (get the group's leaderboard) plus its precise scope: top 10 members by points, three period options, and the caller's own rank. This clearly separates it from siblings like get_group_stats or list_members, which do not rank by points.

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 maps the tool to the 'Leaderboards tab' and implies when it applies, but never explicitly says when to prefer it over get_group_stats (aggregate stats) or list_members. No exclusions or alternatives are named, so selection between the three is left to inference.

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?

Annotations already establish read-only/idempotent behavior; the description adds non-obvious details: formatting is stripped while paragraph/list structure is kept, uploaded Skool videos and attached files are omitted, and only accessible lessons are returned. This materially improves invocation expectations without contradicting annotations.

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 no repetition; scope and return shape are front-loaded before caveats. Every sentence contributes to correct selection or interpretation.

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?

Because there is no output schema, the description carries return-value burden and does so: it describes text, video link, uploaded_video flag, omitted files, and access scope. For a three-ID read operation, that is enough to call and interpret 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?

All three parameters have complete schema descriptions pointing to group, course_id, and lesson_id sources, so the schema already does the work. The description does not add syntax or constraints for these inputs beyond what the schema 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 names a specific resource (one Classroom lesson) and states exactly what it returns: text and linked video. It is clearly a read-one operation, though it does not explicitly contrast with get_course or list_courses.

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 explicit when-to-use guidance or alternative routing; the only usage-related constraint is that it returns only lessons the account can open. An agent can infer it is for fetching a single known lesson_id, but the description does not say when to choose it over get_course or list_courses.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the exact returned surface (bio, role, level, points, online status, last-seen, time zone) and an explicit privacy boundary: 'Never their email or other private details.'

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?

Front-loaded with the purpose, but the field list is stated twice — first as 'name, bio, role, level, points and when they were last online', then restated in the second sentence with online status and time zone added. Merging these would lose nothing.

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?

With no output schema, the description appropriately fills the gap by describing the returned profile card in detail, and it flags the privacy scope. For a two-parameter read tool with full annotation coverage, an agent has enough 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 description coverage is 100% and both parameters are documented there, including the provenance of member_id. The description adds no additional meaning about the group or member_id formats beyond what the schema states, 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?

States a specific verb+resource ('One member's profile in a group') and enumerates the fields returned, which is far more informative than the title 'Get member'. It does not explicitly contrast itself with list_members/search_members, but the distinction between a single-profile fetch and enumeration is clear from the phrasing.

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?

Usage is only implied: the tool is for looking up a member you already have an identifier for. There is no explicit when-to-use/when-not guidance or named alternative in the description itself, though the input schema notes member_id comes from list_members, search_members or get_post, which partially compensates.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: results include your own vote, and voters=true is capped at 30 per answer because 'the vote count opens in Skool' — a real truncation the agent otherwise could not know.

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, front-loaded with the core return content, then the optional voters behavior. Dense and mostly waste-free; the closing clause 'as the vote count opens in Skool' is slightly cryptic but earns its place by explaining the 30-voter cap.

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?

With no output schema and only three parameters, the description carries the full burden of describing the return shape — answers with number, text, vote count, and your own vote. That is exactly what an agent needs to consume the result and chain into vote_on_poll.

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%, so baseline is 3. The description goes slightly beyond: it clarifies that the answer 'number' is the identifier consumed by vote_on_poll (a cross-tool semantic absent from the schema) and reiterates the voters cap as a data-shape constraint rather than just a flag description.

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 names a specific resource (a post's poll answers and vote counts) and a specific operation (retrieve them, optionally with voters). It also distinguishes itself from the sibling vote_on_poll by explaining that each answer's number is 'what vote_on_poll takes', making the read/write pairing unambiguous.

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?

Usage is implied rather than stated: an agent can infer this is the read path for a poll and that vote_on_poll is the write path, and it learns the voters=true option exists. However, there is no explicit when-to-use/when-not or a named alternative for retrieving voter data, so routing relies on inference.

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?

Goes well beyond the annotations, which only cover the read-only/idempotent safety profile. It discloses a hard cap ('up to 25 comments'), the nesting shape of replies, and an important exclusion ('Images and files attached to the post are not returned; links typed in the text are') that an agent could not otherwise know without an 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.

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

Front-loaded with the core fact and sized appropriately for a two-parameter read tool. The first and second sentences partially repeat the 'full text and comments, replies nested' idea, which is minor waste but keeps the framing clear.

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?

With no output schema, the description carries the return-shape burden and does so: fields, comment cap, nesting, and media exclusion are all covered. It does not say whether more than 25 comments can be retrieved or what happens when the post_id is invalid, leaving small gaps for a lookup tool.

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 both parameters are already documented in the schema, including 'post_id or slug'. The description restates the identifier option but adds no new syntax, format, or constraint information, 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?

States a specific verb and resource ('Returns one post by post_id or slug') and enumerates what comes back (title, full text, author, comments with nested replies). This clearly distinguishes it from list_posts, which the agent would otherwise have to infer.

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?

Implies usage by requiring an identifier 'from list_posts', which effectively says fetch a single known post rather than browse. It also routes the reader forward to comment_on_post with a concrete instruction ('Use comment_id as parent_comment_id'), but never explicitly states when not to use it or how it differs from list_posts in prose.

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?

Annotations already flag destructive/openWorld/non-idempotent, and the description adds real value beyond them: emails leave the platform, existing addresses are skipped by Skool, and a per-call confirmation is on by default. The closing sentence 'Waits for the owner's approval' is ambiguous and sits awkwardly against 'joins without a membership request', leaving the blocking/approval behavior unclear.

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?

Front-loaded with the action and the admin gate, and most sentences carry distinct information. The mid-sentence reference to 'as Invite people, Invite by email does' is UI-oriented filler that doesn't help an agent, and the approval clause is tacked on without explaining itself.

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?

No output schema exists, and the description covers the mutation's blast radius, external-recipient risk, skip-existing behavior, and confirmation default — enough to call it safely. What a call returns (partial success, skipped addresses) is left unstated.

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 already explains group, the 50-address cap, and course_ids. The description adds no parameter-level meaning and never mentions course_ids at all, so it neither compensates nor detracts — baseline 3.

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?

States a specific verb (email an invitation) and resource (people who join the group), plus the actor restriction 'Admins only' and the resulting effect (joins without a membership request). An agent can distinguish this from approve_membership_request or add_membership_question without opening 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?

Gives clear operating context: admin-only, invites people outside the group, and by default requires confirmation per call. It implicitly contrasts with the membership-request flow ('joins without a membership request') but never names a sibling tool to use instead for approving existing requests, so routing guidance is clear but not explicit.

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?

Goes well beyond the annotations: it discloses the leaderboard point awarded to the author, that the target gets notified, that rapid liking returns a rate_limited error, and that the action is reversible in one call. Annotations only supply destructiveHint/idempotentHint flags; this text explains the actual side effects and failure mode. Minor tension with destructiveHint=true and 'runs without asking first', but not a contradiction since unliking does remove existing state.

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?

Front-loaded with the core action and reversal, which is good, but 'as the heart under it does' is UI flavor that costs a sentence without informing the agent, and the reversibility point is split across the last two sentences.

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 mutation tool with no output schema, it covers the essentials an agent needs: both directions, the notification/points side effects, the rate-limit failure mode, and safe reversibility. Only a note on what the response returns or how to detect 'already liked' is missing.

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 the description's clarification that post_id may be a comment_id only restates what the schema text already says. The 'liked false' semantics also mirror the schema description of the liked parameter, so almost no value is added.

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?

States a specific verb (like) across two resource types (post OR comment) plus the reverse operation, so the full capability is visible in the first sentence. An agent can immediately tell this apart from siblings like vote_on_poll or follow_post without opening 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?

'Liked false takes the like back' and 'Runs without asking first: undone with one call' give clear operating context, including that no confirmation round-trip is needed. It stops short of naming alternatives (e.g. list_post_likes to check current state) or stating 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes beyond them by describing the return shape (name, who_can_post, sort, post_count) and ordering behavior ('in the order the group shows them'). With no output schema, this return-value disclosure is genuinely useful context.

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, front-loaded with the resource and its fields, then value domains, then the downstream usage hint. The phrase 'The feed categories of a group: name, who can post, sort order, post count' is a fragment but reads 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 single-parameter read tool with no output schema, the description covers the returned fields and their allowed values (members/admins; default/new/top_week/top_month/top_year), which is what an agent needs to interpret results. Only the ordering of categories versus posts could be clearer.

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?

There is a single 'group' parameter with 100% schema description coverage including an example, so the schema carries the semantics. The description adds nothing specific about the parameter itself, which matches the baseline 3.

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?

States a specific verb and resource ('Lists the categories a group's feed is split into') and enumerates the returned fields, so an agent knows exactly what it gets. It does not explicitly contrast itself with create_category/update_category/delete_category, but the read intent is unambiguous.

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?

Usage is only implied: the note that 'create_post and update_post take the name' hints this is a prerequisite lookup step. There is no explicit when-to-use/when-not statement or named alternative among the category CRUD siblings.

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?

Annotations already establish that this is a safe read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: most-recent-first ordering, the fields returned, and how pagination works.

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 front-loaded with the inbox value proposition, then covers listing scope, return fields, filtering, and pagination without wasted text. It is appropriately sized for a three-parameter list 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?

There is no output schema, but the description sufficiently explains the returned fields, ordering, filtering, and pagination required to call and interpret the tool. Annotations cover the safety profile, so the description is complete for this read-only list operation.

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%, so the schema already documents all three parameters. The description still adds practical meaning for unread_only and cursor, especially by clarifying that the next cursor is passed back as cursor for the next page.

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-resource pairing: it lists Skool Chat conversations across all groups, most recent first, and names the returned fields. This clearly distinguishes it from single-conversation and messaging siblings such as get_conversation and send_message.

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?

It gives clear usage context as the Skool Chat inbox and explains when to use unread_only to focus on conversations needing an answer. It also explains pagination via cursor, though it does not explicitly name alternatives or exclusions.

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?

Annotations already cover readOnly, idempotent, and closed-world, so the description's job is to add context — and it does: it explains that 'unlock' means the account can open the course or not, that the cause may be a level, purchase, or time lock Skool won't disclose, and that locked courses return no modules. It doesn't cover pagination or result-size limits, keeping it below 5.

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?

Front-loaded with the core purpose, but the ordering point is stated twice ('with the modules of open ones' and 'Lists the courses ... in its order'), and the closing sentence about welcome messages is vague and unearned without more context.

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 list tool with annotations and no output schema, the description covers the essential return shape — ordering, open/locked status, module links present only for open courses. Missing only minor operational details like whether locked modules can be fetched elsewhere.

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% with a single, well-documented 'group' parameter, so the schema carries the semantics. The description only reinforces this by tying results to 'the group's Classroom' and adds no format or edge-case detail beyond the schema.

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?

States a concrete verb and resource (list the courses of a group's Classroom) and specifies scope: open vs locked courses, plus modules for open ones. An agent can distinguish it from get_course (single course) and create_course without opening another schema, though no sibling is named explicitly.

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?

Usage is only implied by the enumeration of course states; there is no explicit 'use this when... instead of get_course when...'. The final sentence ('Use the module links in welcome messages') is a downstream hint about the output rather than guidance on when to invoke the tool.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description adds real behavioral context beyond that: recurring events appear once per date, results mirror the Calendar tab month view, UTC inputs with display in the calendar's timezone.

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, front-loaded with the resource and scope, then return fields, then sibling routing. Only waste is the dangling 'start and end' clause that doesn't map to any parameter.

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?

No output schema exists, so the description carries the return-value burden and does so by naming title, time, place and join eligibility, and by explaining the recurring-event expansion. Month-scoped listing makes pagination less of a concern, though result ordering and empty-month behavior go unmentioned.

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% (group URL name, YYYY-MM month with default), so the baseline is 3. The description adds timezone semantics for times, but it also references 'start and end are UTC' when no such parameters exist in the schema, which muddies rather than clarifies the two real params.

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?

States a specific verb and resource ('Events on a group's calendar in one month') plus the fields returned, and explicitly separates itself from siblings get_event (one event) and create_event (adds one). An agent can pick this apart from neighbors without opening a 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 closing clause routes the agent: get_event for a single event, create_event for creation. It gives clear positive context but never states an explicit exclusion or precondition (e.g., what happens if the group has no calendar or the month has no events).

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the 1-based numbering matches the order the group displays links in, which is the key fact an agent needs. It omits ordering stability and what happens with zero links, keeping it below a 5.

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 first two sentences restate each other almost verbatim ('links ... numbered as the group shows them' / 'links ... under the description, numbered from 1'). The valuable routing sentence is buried last instead of front-loaded, so the definition wastes roughly a third of its length.

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 single-parameter read tool with full annotation coverage and no output schema, the description conveys the return shape (an ordered, 1-based list of sidebar links) and how the result feeds other tools. Only pagination/empty-list behavior is unstated, which is minor here.

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?

Only one parameter and schema coverage is 100%, with the schema itself explaining the URL-name format. The description adds no syntax or edge-case detail about the 'group' argument beyond 'a group's sidebar', 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?

States a specific verb and resource ('lists the links the group shows in its sidebar') plus the distinguishing trait that they are numbered. That separates it from add_group_link, but it never explicitly says it is the read counterpart of update_group_link/delete_group_link — the relationship is only implied by the trailing sentence.

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 final sentence 'update_group_link and delete_group_link take the number' gives a concrete reason to call this tool: to obtain identifiers before mutating. It stops short of explicit when-not guidance or naming a search alternative, but the context is clear enough to act on.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those annotations: rules are numbered from 1 in the order the group displays them, and the returned numbers are the identifiers used by update_group_rule and delete_group_rule.

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, but the first two sentences repeat the same numbering concept. It is not wasteful overall, yet it could be tightened without losing 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 read-only list tool with one documented parameter and rich annotations, the description covers the key non-obvious behavior: numbering starts at 1 and follows the group's display order. No output schema exists, but the core return concept is explained adequately for this tool.

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?

There is only one parameter, and schema description coverage is 100%: the schema already explains that 'group' is the group URL name. The description does not add further parameter semantics, 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.

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

The description uses a specific verb and resource: it lists group rules. It also distinguishes this read operation from the sibling mutations update_group_rule and delete_group_rule by explaining that those tools take the rule number returned here.

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 clearly implies when this tool is needed: before calling update_group_rule or delete_group_rule, because those tools take the rule number. It does not explicitly state exclusions or alternatives beyond the update/delete relationship.

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?

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful operational context beyond them: a hard cap of 50 results, the role enumeration including pending, and the caveat that a pending group shows no posts or members yet. Missing only pagination/truncation behavior when more than 50 groups exist.

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?

Purpose and the 50-item cap are front-loaded, then field semantics, then the cross-tool usage hint. Slightly dense and repetitive in places (the 'groups you own/joined/asked to join' clause restates the ownership scope), but every sentence carries 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?

There is no output schema, so the description must carry the return shape, and it does: the fields (role, members, price), the role values, the 50-item ceiling, and pending-group behavior. An agent can call this and interpret the result without further guessing.

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 tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description does not need to compensate for any schema gap.

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?

States the specific resource ("Skool groups of your account") and immediately scopes it to owned/joined/requested groups, which separates it from discovery-oriented siblings like discover_groups and search_group. It also names the fields returned (role, member count, price), so an agent knows this is an account-scoped roster, not a lookup.

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?

Explicitly tells the agent the downstream pattern: "Use group as the group parameter of the other tools," which is real routing guidance. It does not name an alternative for the case where the agent wants to find a group it has not joined (discover_groups/search_group), so exclusion guidance is incomplete.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: the result is fixed at 9 levels, the title field is empty when no custom title exists, and share-of-members is included per level — details an agent cannot get from the annotations or schema.

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?

Short and front-loaded, with the returned fields enumerated up front. There is mild redundancy — the first sentence and second sentence both restate that there are 9 levels — but nothing is padded beyond that.

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?

With no output schema, the description carries the burden of explaining return values and does so: level number, Skool name, custom title (empty when none), and member share. Minor gap: it never specifies the format of 'share' (percentage vs. fraction), which an agent consuming the data would want.

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?

Only one parameter exists and it has 100% schema description coverage, which already explains the group URL format. The description adds no supplementary meaning about the group argument (e.g., must the caller be a member), so 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?

States a specific verb and resource (lists the group's 9 levels) and enumerates exactly what each entry contains: level number, Skool's internal name, admin-assigned title, and member share. It also explicitly separates itself from get_leaderboard, which ranks members rather than describing levels.

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?

It draws the key distinction against the closest sibling by noting 'get_leaderboard ranks the members,' so an agent can infer that this tool is for level definitions/membership distribution rather than member ranking. There is no explicit when-not-to-use clause, but for a simple read-only listing the routing context is clear.

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?

Annotations already cover the safe/read-only/idempotent profile, and the description adds real behavior beyond them: fixed 30-per-page pagination, newest-approved-first ordering, and the important caveat that joined_since only filters within the current page rather than the whole result set. Return fields (role, level, points, join date) are enumerated since there is 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.

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

Front-loaded with what the tool returns and how paging works, then parameter meanings. Slight redundancy ('newest first' in the opening clause and 'newest approved first' immediately after) and dense run-on sentences cost it a point.

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?

With no output schema, the description does the work of naming returned fields and explains pagination continuation. Minor gaps remain: it doesn't say whether a missing/empty next_cursor signals the last page, and the difference between active and cancelling for non-paid groups is only implied.

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%, so the baseline is 3, but the description adds semantics the schema lacks: joined_at means approval time, level is Skool's 1-9 level and points are the likes counting toward it, and crucially the member_id (person, used with send_message/get_member) versus membership_id (this group's membership, used with set_member_role/ban_member/remove_member) distinction, which tells the agent which ID to carry forward.

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?

States a concrete verb and resource (list members of one group) plus scope details: newest approved first, 30 per page, status tab selection. An agent can tell what it returns without opening the schema. It doesn't explicitly contrast itself with the sibling search_members, which is the main thing keeping it from a 5.

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?

Gives clear conditions for each parameter: status picks the tab (active/banned/churned/cancelling), role admin/moderator asks Skool for admins only, joined_since filters within the page, and cursor comes from the prior next_cursor. No explicit when-not-to-use or 'use search_members for a specific person' routing, which would be needed for a 5.

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?

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds real context beyond that: pagination shape (30 per page, oldest first), the permission failure code, and the fact that each entry carries applicant answers plus a request_id. It stops short of describing the response envelope or whether a missing cursor means no more pages.

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 opening sentence and the second sentence say substantially the same thing ('pending requests to join, with each applicant's Membership Questions answers' vs. 'lists requests to join a private group... with the answers each applicant gave'), which is wasted space. The valuable parts (permissions, denial code, pagination, downstream tools) are appended rather than front-loaded.