Skip to main content
Glama
Sign In

Skool MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Open the browser

cotlet_browser_open
Read-only

Starts the user's Skool Cloud Browser (a real Chrome on Cotlet, signed in to Skool as the user; use it for what the Skool tools do not cover) and opens url. Call it first. Only Skool pages open. Answers the page after it: the elements and text in view, with the same numbers. In Skool it serves these actions: List members, Approve membership request, Create post, Reply to comment, Send DM, Get members, churn and MRR, Create calendar event, Add course lesson, Ban member, Edit categories and rules.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cotlet_browser_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoA public http or https address, e.g. https://example.com.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"A public http or https address, e.g. https://example.com. In an app's browser, a page of that app."New value: +"A public http or https address, e.g. https://example.com."
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, non-idempotent, non-destructive, so the safety profile is covered; the description adds real value on top: the browser is a real signed-in Chrome instance, only Skool pages will open, and calls are session-starting. It does not state whether an existing session is reused or reset, which matters given idempotentHint=false, but nothing contradicts 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.

Conciseness4/5

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

The essential operations are front-loaded ('Starts ... opens url. Call it first.'), and the following sentences add scope and return behavior. The trailing Skool action list is long and reads as marketing enumeration, but it does aid tool selection, so it mostly earns its place.

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

Completeness4/5

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

With no output schema, the description usefully compensates by describing the return: elements and text in view, numbered consistently for follow-up calls. The phrase 'with the same numbers' is cryptic about the reference numbering, and the session-reuse behavior is unstated, leaving minor gaps for a session-establishing tool.

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% and the schema describes `url` as a public http/https address, so baseline would be 3. The description adds a meaningful constraint the schema does not: 'Only Skool pages open,' which tells the agent the accepted URL space is narrower than the schema implies.

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

Purpose4/5

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

The description states a specific verb and resource: it starts the user's Skool Cloud Browser (real Chrome signed in as the user) and opens `url`, plus the sequencing rule 'Call it first.' It doesn't address the closely named sibling `cotlet_browser_navigate`, so an agent must infer the split between this and plain navigation.

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

Usage Guidelines4/5

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

'Call it first' and 'use it for what the Skool tools do not cover' give explicit when-to-use guidance, and the action list shows what Skool workflows it enables. It lacks explicit when-not-to-use framing, particularly versus `cotlet_browser_navigate` or `cotlet_browser_close`.

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