Skip to main content
Glama
Sign In

Skool MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Get poll results

get_poll_results
Read-onlyIdempotent

Answers and vote counts of a post's poll, optionally with who voted for what. Returns the poll under a post: each answer with its number (what vote_on_poll takes), text and vote count, and your own vote. voters true adds up to 30 voters per answer, as the vote count opens in Skool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group": "<group>",
      "post_id": "<post_id>"
    },
    "name": "get_poll_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
groupYesGroup URL name, e.g. 'yourgroup' for skool.com/yourgroup.
votersNoAlso list who voted for each answer, up to 30. Default: false.
post_idYespost_id or slug of the post with the poll.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

All Skool MCP Server and API by Cotlet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources