Skip to main content
Glama
Sign In

Gymmy

by com.hellogymmy
OverviewDiscussionsAdmin

Class schedule

get_schedule
Read-onlyIdempotent

Upcoming classes of a Gymmy gym (next 14 days): time, duration, spots left, and a booking link with the class already picked.

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": {
      "gym": "<gym>"
    },
    "name": "get_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
gymYesGym identifier: the `gym` value from search_gyms (page slug or Gymmy id).
dateNoOnly this day (YYYY-MM-DD).
localeNoAnswer language: fr (default), en, pt, es or de. Pass en when the person writes in English.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / locale / description
      Previous value: -"Answer language: fr (default) or en. Pass en when the person writes in English."New value: +"Answer language: fr (default), en, pt, es or de. Pass en when the person writes in English."
    • changedInput schema / properties / locale / enum
      Previous value: -[
-  "fr",
-  "en"
-]New value: +[
+  "fr",
+  "en",
+  "pt",
+  "es",
+  "de"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / locale / description
      Previous value: -"Answer language. Default fr."New value: +"Answer language: fr (default) or en. Pass en when the person writes in English."
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive call, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the fixed 14-day forward window and the fact that each result carries a pre-filled booking link, which tells the agent this is a discovery-to-booking funnel step. It does not state result ordering or volume.

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

Conciseness5/5

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

A single front-loaded sentence that states scope, window, and return fields with no filler. Every clause earns its place, and the most decision-relevant information (gym schedule, 14-day window) comes first.

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?

For a simple three-parameter read tool with full schema coverage, complete annotations, and no output schema, the description covers purpose, window, and return contents adequately. The only gap is the unstated relationship between the default 14-day window and the optional single-day filter, which an agent must infer.

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

Parameters3/5

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, including the gym identifier's provenance from search_gyms and the locale enum with its default. The description adds only indirect meaning, since the 'next 14 days' window contrasts with the schema's single-day date filter without explaining that relationship. Baseline 3 is appropriate when the schema carries the load.

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 names a specific resource and scope: upcoming classes of a Gymmy gym over the next 14 days, plus the fields returned. An agent can tell this apart from a booking or a search tool by the word 'schedule' and the stated window. It stops short of explicitly contrasting itself with siblings such as search_classes or my_schedule.

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: fetch a gym's schedule for the next two weeks, optionally narrowed to a single day. There is no explicit when-to-use or when-not-to-use guidance, and no pointer to search_classes for criterion-based lookup or to my_schedule for the caller's own bookings.

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

All Gymmy 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