Skip to main content
Glama

Glofox MCP Server and API by Cotlet

List classes in Glofox

glofox_list_classes
Read-onlyIdempotent

List classes in the user's own Glofox account from ChatGPT, Claude or any AI agent. Returns how to do it in Glofox step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's Glofox Cloud Browser. Glofox's official API: Glofox has a REST API for members, memberships, classes, bookings and payments, but the key and token come only on request to ABC Fitness, and its Zapier app needs the Elite plan (checked 8 Nov 2026).

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": "glofox_list_classes"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, but the description adds materially: the tool "opens nothing by itself" and returns screens, buttons and fields rather than performing the action. That is exactly the kind of behavioral disclosure an agent needs to plan a two-step browser workflow. It stops short of describing the response shape or whether the guide is static or account-specific.

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

Conciseness3/5

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

The critical behavior (returns a guide, does not act) is buried mid-sentence after generic marketing phrasing about "ChatGPT, Claude or any AI agent". The closing paragraph on Glofox's official REST API, ABC Fitness key requests and the Zapier Elite plan is relevant justification but is disproportionately long for the information it carries.

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 parameters, no output schema and rich annotations, the description covers what the agent most needs: the tool is read-only, performs no action, and must be followed by cotlet_browser_* calls. It could be stronger by stating what the returned guide looks like or whether it depends on the user's Glofox session state, but the essentials are present.

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?

The tool takes zero parameters, so there is no parameter meaning for the description to add; the baseline for a parameterless tool applies. Nothing in the description contradicts or confuses the empty schema.

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

Purpose3/5

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

The description opens with a specific verb and resource ("List classes in the user's own Glofox account"), which distinguishes it from account-agnostic siblings. However, it then says the tool "Returns how to do it in Glofox step by step" and "opens nothing by itself", so the agent cannot tell from the first sentence whether it gets class data or a how-to guide. That tension between the stated purpose and the actual output ambiguity keeps this below a 4.

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?

"Then do it with the cotlet_browser_* tools in the user's Glofox Cloud Browser" gives a concrete next step after calling, which is real usage guidance. There is no guidance on when to choose this over siblings like glofox_list_members, and no exclusions or preconditions beyond the implicit need for a Glofox Cloud Browser session.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources