GymFlexa Gym Management

by com.gymflexa

Overview Discussions Admin

Server Details

See your gym's open slots, services, how busy each day is and your payment totals.

Ownership verified

Status: Healthy
Uptime: 100.0% over 19 days
Last Tested: 2026-10-16 18:20
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-09-28 23:25 across 7 tools

Disambiguation4/5

Most tools have clearly distinct purposes (gym settings vs availability vs payments vs schedule), and descriptions explicitly state what each is 'not for'. The main overlap is show_gym_overview, which aggregates data from get_gym, get_gym_availability, get_gym_schedule_summary, and list_services, so an agent must choose between a dashboard and targeted queries.

Naming Consistency4/5

Names follow a predictable verb_noun pattern (get_gym, get_gym_availability, get_gym_payment_summary, get_gym_schedule_summary, list_gyms, list_services). The only deviation is show_gym_overview, which uses 'show' instead of 'get', but the overall scheme stays consistent and readable.

Tool Count5/5

Seven tools is well-scoped for a gym reporting server, with each tool earning its place across distinct resources (gyms, services, availability, payments, schedule) plus one overview convenience tool.

Completeness3/5

The surface is purely read-only reporting: there is no way to create, update, or delete gyms, services, or bookings, and no member-facing tool despite list_gyms referencing members. For a 'management' server, notable lifecycle operations are missing, though query coverage for reporting is decent.

Available Tools

7 tools

get_gymGet gym opening hours and settingsA

Read-onlyIdempotent

Inspect

Use this when someone asks for one gym's opening hours, timezone, currency or default session length. Returns the gym's scheduling settings with up to 14 opening-hour rows, Monday first; an id outside the organization returns not-found. Not for free session slots.

ParametersJSON Schema

Name	Required	Description	Default
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)

Output Schema

ParametersJSON Schema

Name	Required	Description
`gym`	Yes	Scheduling settings of the gym; null when not found. Address, phone, website, organization, billing, integrations, reminders, members and arbitrary metadata are excluded.
`status`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely new behavioral detail: return cardinality and ordering (up to 14 rows, Monday first) and error semantics (id outside the organization returns not-found).

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?

Three short sentences, each earning its place: trigger and scope first, then return shape, then error behavior. No redundancy or filler.

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?

An output schema exists, so return values need not be explained, and the description still adds ordering, row cap, and not-found behavior. For a single-parameter read tool, nothing an agent needs 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single gymId parameter is fully documented with format and source ('as the gym list returns it'). The description adds nothing about the parameter, so the baseline 3 applies.

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?

Names a specific verb+resource (get one gym's setting) and enumerates exactly what it returns: opening hours, timezone, currency, default session length. This is concrete enough to distinguish it from summary-style siblings like get_gym_schedule_summary.

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?

States a clear trigger ('when someone asks for one gym's opening hours...') and one explicit exclusion ('Not for free session slots'), which routes the agent toward get_gym_availability. It stops short of naming that sibling explicitly, so it is contextually clear but not fully exhaustive.

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

get_gym_availabilityFind free session slotsA

Read-onlyIdempotent

Inspect

Use this when someone asks when their gym has free slots or openings for a class or session, or which coming days are fully booked. Returns, per day, how many online-booking slots are open plus the first start and last end time, for the next 14 days that have openings, so a skipped day has none (no member or trainer names). Not for booking a session.

ParametersJSON Schema

Name	Required	Description	Default
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes	One row per day with open online-booking slots inside the gym's booking window, in date order. Slot counts and times only; members, appointments, trainers and the reason a time is unavailable are never exposed.
`timezone`	Yes
`availableDayCount`	Yes
`availableSlotCount`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations don't: it discloses the return shape (per-day open-slot count plus first start/last end time), the 14-day window, that skipped days mean no availability, and that names are omitted.

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?

Front-loaded with the use-case trigger and dense but purposeful. The second sentence is somewhat run-on in packing return shape, window, and exclusions together, but no sentence is wasted.

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?

For a single-parameter read-only tool with an output schema and full annotation coverage, the description supplies everything an agent needs: when to use, what is returned, the time window, and the booking exclusion. Nothing material is missing.

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 coverage is 100% and the single gymId parameter is fully documented in the schema, so the description adds no parameter-level detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb+resource ('find free session slots') and scopes it to gym availability. It is clearly distinguishable from siblings like get_gym_schedule_summary by emphasizing openings/booked days rather than a schedule, and the closing 'Not for booking a session' removes ambiguity.

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?

Opens with an explicit when-to-use trigger ('when someone asks when their gym has free slots... or which coming days are fully booked') and states a when-not ('Not for booking a session'). It does not name a specific alternative sibling tool, but the usage context is clear.

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

get_gym_payment_summarySummarize gym takingsA

Read-onlyIdempotent

Inspect

Use this when someone asks how much their gym took in, or how many payments succeeded, failed or were canceled. Returns payment counts by status and totals by currency; totals include every status. Covers up to 31 days and 100 payments and defaults to the next 7 days, which hold no payments yet. Not for moving money: it cannot charge, refund or transfer.

ParametersJSON Schema

Name	Required	Description
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)
`endTime`	No	End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start
`startTime`	No	Start of the range as an ISO 8601 date-time, matched against when each payment was recorded; defaults to now, so pass a past date for past takings

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes
`totals`	Yes	Amount totals per currency, summed over every status including FAILED and CANCELED payments. Payment and member ids, processor or card data, contacts, notes, discounts, decline reasons, services and individual transactions are never returned.
`statuses`	Yes	Payment counts per status, such as SUCCEEDED, FAILED, CANCELED or OTHER
`recordCount`	Yes
`totalsArePartial`	Yes	True when more than 100 payments fall in the range or any returned amount is missing or invalid
`recordCountIsLowerBound`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 genuinely new behavioral context beyond that: totals include every status, coverage is capped at 31 days and 100 payments, and the default 7-day-ahead window holds no payments yet — a real trap for callers. It stops short of mentioning auth or rate-limit behavior, so a 4 rather than 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.

Conciseness5/5

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

Three tightly packed sentences, front-loaded with the trigger, then the return shape, then the limits, then the exclusion. No filler and no repetition of the tool name or title.

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?

An output schema exists, so return values need no explanation here. The description supplies the trigger, the scope of aggregation, the size/time limits and the 'cannot move money' boundary — everything an agent needs to select and call this correctly against its siblings.

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 gymId, startTime and endTime are already fully documented in the schema, including their defaults and the 31-day maximum. The description only echoes the default window and the start/end relationship, adding no syntax or format detail beyond what the schema provides. Baseline 3 applies.

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 states a specific verb and resource ('summarize how much their gym took in') and enumerates the dimensions summarized: counts by payment status and totals by currency. It is clearly distinguishable from the sibling tools, which cover gym metadata, availability, schedules and services rather than payments.

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

Usage Guidelines5/5

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

It leads with an explicit trigger ('Use this when someone asks how much their gym took in...') and closes with an explicit exclusion ('Not for moving money: it cannot charge, refund or transfer'). Both the when-to-use and when-not-to-use conditions are stated rather than inferred.

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

get_gym_schedule_summaryCount bookings per dayA

Read-onlyIdempotent

Inspect

Use this when someone asks how busy their gym is or how many appointments or sessions are booked each day, past or upcoming. Returns booking counts per UTC day for one gym, whatever their status, for any window of at most 31 days (the next 7 by default); counting stops at 100. Not for counting cancellations or seeing which members are booked.

ParametersJSON Schema

Name	Required	Description
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)
`endTime`	No	End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start
`startTime`	No	Start of the range as an ISO 8601 date-time; defaults to now

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes	One row per UTC day that has bookings, canceled ones included. Aggregate counts only: appointment ids and times, member information, services, notes, trainer data and attendance history are never returned.
`range`	Yes
`recordCount`	Yes
`recordCountIsLowerBound`	Yes	True when more than 100 bookings fall in the range

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add behavior they cannot express: counting includes all booking statuses, the window is capped at 31 days, the default window is the next 7 days, and counting stops at 100. The result cap and default window in particular are operationally important and appear nowhere in 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.

Conciseness5/5

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

Three sentences, trigger condition front-loaded first, followed by scope/limits and then negative scope. Every clause carries information (window limit, default, cap, exclusions) with no filler.

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?

An output schema exists, so return-shape explanation is unnecessary; the description instead supplies the behavioral facts an output schema cannot (per-UTC-day aggregation, status-agnostic counting, 100-count cap, 31-day window). 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents startTime/endTime defaults and the 31-day constraint, so the description contributes no additional parameter detail beyond what the agent will read anyway. Baseline 3 is appropriate when the schema does the heavy lifting.

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 pairs a concrete verb and resource ('Returns booking counts per UTC day for one gym') and constrains the scope ('whatever their status', 'any window of at most 31 days'). Combined with the title, an agent can distinguish this from get_gym_availability or get_gym_payment_summary 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.

Usage Guidelines4/5

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

It gives an explicit trigger ('when someone asks how busy their gym is or how many appointments or sessions are booked each day, past or upcoming') and explicit exclusions ('Not for counting cancellations or seeing which members are booked'). It stops short of naming which sibling to use instead for those cases, so it is clear context without full alternative routing.

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

list_gymsList your gymsA

Read-onlyIdempotent

Inspect

Use this when someone asks which gyms or studios they run in GymFlexa, or a gym's id is needed. Returns gyms with id, name, currency, default language and last edit time, alphabetical, 25 per page by default. Not for finding a member.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of gyms to return (default 25, maximum 100)
`cursor`	No	The nextCursor of the previous page of this listing; absent for the first page

Output Schema

ParametersJSON Schema

Name	Required	Description
`gyms`	Yes	Gyms in the signed-in organization, alphabetical. Organization, address, contact, billing, integration and member data are never returned.
`hasMore`	Yes
`nextCursor`	Yes	Cursor for the next page; null on the last page

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine beyond-annotation behavior: alphabetical ordering, a default page size of 25, and pagination via the returned cursor. It does not restate the read-only nature.

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?

Two tight sentences: usage trigger front-loaded, then return/pagination facts, then a one-clause exclusion. No filler and nothing out of order.

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?

An output schema exists, yet the description still supplies ordering and default page size, plus the when-to-use trigger and the member-search exclusion. An agent has everything needed to select and call it correctly.

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 limit and cursor are already fully documented with defaults and maximums. The description's '25 per page by default' repeats the schema, and only the alphabetical-sort detail adds anything, so the baseline 3 is warranted.

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?

States a specific verb and resource ('which gyms or studios they run') and enumerates the returned fields (id, name, currency, default language, last edit time). It explicitly distinguishes itself from the single-gym siblings by noting it is 'not for finding a member' and by returning a list rather than an overview.

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?

Gives a clear trigger ('when someone asks which gyms or studios they run... or a gym's id is needed') and one explicit exclusion ('Not for finding a member'). It does not name the sibling to use for a single gym's details (get_gym), so routing to alternatives is implied rather than spelled out.

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

list_servicesLook up class and service pricesA

Read-onlyIdempotent

Inspect

Use this when someone asks what their gym charges for a class, personal training session or other service. Returns catalog service names with price and last edit time for one gym, alphabetical, 25 per page by default. Not for what a particular member bought or attended.

ParametersJSON Schema

Name	Required	Description
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)
`limit`	No	Maximum services to return (default 25, maximum 100)
`cursor`	No	The nextCursor of the previous page of this listing; absent for the first page

Output Schema

ParametersJSON Schema

Name	Required	Description
`hasMore`	Yes
`services`	Yes	Service catalog entries, alphabetical. Service ids, member history, notes, staff commissions, organization ids and arbitrary metadata are excluded.
`nextCursor`	Yes	Cursor for the next page; null on the last page

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the safe read-only/idempotent profile, so the bar is lower; the description nonetheless adds behavioral detail the annotations lack: alphabetical ordering, default page size of 25, and that results are catalog entries rather than per-member records. It does not discuss rate limits or pagination termination, but the essentials 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.

Conciseness5/5

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

Three tight sentences with zero filler, front-loaded with the use case, then return shape/paging, then the exclusion. Every sentence earns its place.

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?

Complete for a paginated read-only listing: scope, output contents, ordering, page size and the distinguishing exclusion are all stated, and an output schema exists so return-value detail need not be repeated.

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 gymId, limit and cursor are fully documented in the schema; description merely restates the 25-per-page default already in the limit parameter. Baseline 3 applies since the schema carries the parameter burden.

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?

States a specific verb and resource ('list...catalog service names with price and last edit time for one gym') and clearly separates itself from the gym-metadata siblings by scoping to services/prices. The closing clause distinguishes it from purchase/attendance lookups.

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?

Gives an explicit trigger ('when someone asks what their gym charges for a class, personal training session or other service') and an explicit exclusion ('Not for what a particular member bought or attended'). It does not name a specific alternative tool, though no sibling overlaps this catalog role.

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

show_gym_overviewShow gym overviewA

Read-onlyIdempotent

Inspect

Use this when someone wants a quick overview or dashboard of one gym. Returns an overview card with the gym's details, booking counts for the next 7 days, open online-booking slots across up to 14 days with openings and up to 12 services with prices (no member, trainer or payment data). Not for a single member or booking.

ParametersJSON Schema

Name	Required	Description	Default
`gymId`	Yes	Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)

Output Schema

ParametersJSON Schema

Name	Required	Description
`gym`	Yes	Gym metadata; null when not found. The overview never reads or returns member records, individual appointments or payments, attendance or service history, trainers, notes or health and fitness details.
`services`	Yes
`scheduleDays`	Yes
`serviceCount`	Yes
`scheduleRange`	Yes
`appointmentCount`	Yes
`availabilityDays`	Yes
`availableDayCount`	Yes
`availableSlotCount`	Yes
`serviceCountIsLowerBound`	Yes
`appointmentCountIsLowerBound`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine behavioral context beyond them: the exact transparency boundaries (no member, trainer or payment data) and the windowing limits (7 days of booking counts, 14 days of slots, 12 services with prices). It says nothing about permissions or result caps beyond those limits, but this is solid added value.

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?

Three sentences, front-loaded with the selection trigger, then the payload description, then the exclusion. Dense but every clause carries either scope or content information; only the long enumerations push it toward terseness fatigue.

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?

Because an output schema exists, the description need not explain return values, yet its summary of the card's contents and the explicit data exclusions make the tool's boundaries unambiguous. For a one-parameter read tool with full annotations, nothing essential is missing.

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?

The single gymId parameter is fully documented in the schema (format pattern, source of the value), and the description adds no further syntax or sourcing guidance. With 100% schema coverage, the schema carries this dimension and the description correctly stays out of the way.

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?

States a specific verb and resource ('quick overview or dashboard of one gym') and enumerates what the overview card contains, which sets it apart from narrower siblings like get_gym_availability. However, it never names the overlapping gym siblings (get_gym, get_gym_availability, list_gyms) it should be chosen over, so the differentiation is by content rather than by explicit contrast.

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?

Gives a clear trigger ('use this when someone wants a quick overview or dashboard of one gym') and an explicit exclusion ('Not for a single member or booking'). It stops short of naming the alternative tool to call for those excluded cases, so routing for sibling gym tools 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 28, 2026

Changedget_gym_payment_summary1 field changed

changedOutput schema / properties / totalsArePartial / description

Previous value: -"True when more than 100 payments fall in the range"New value: +"True when more than 100 payments fall in the range or any returned amount is missing or invalid"

7 tool updatesSep 28, 2026

Changedget_gym3 fields changed

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

changedOutput schema / properties / gym / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "appointmentDuration": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "countryCode": {
-        "anyOf": [
-          {
-            "pattern": "^[A-Z]{2}$",
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "currency": {
-        "anyOf": [
-          {
-            "pattern": "^[A-Z]{3}$",
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "defaultLocale": {
-        "anyOf": [
-          {
-            "maxLength": 16,
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "firstDayOfTheWeek": {
-        "anyOf": [
-          {
-            "enum": [
-              "Monday",
-              "Tuesday",
-              "Wednesday",
-              "Thursday",
-              "Friday",
-              "Saturday",
-              "Sunday"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "id": {
-        "pattern": "^[0-9a-f]{24}$",
-        "type": "string"
-      },
-      "lastEditTime": {
-        "anyOf": [
-          {
-            "maxLength": 32,
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "name": {
-        "maxLength": 200,
-        "type": "string"
-      },
-      "openingHours": {
-        "items": {
-          "additionalProperties": false,
-          "properties": {
-            "close": {
-              "anyOf": [
-                {
-                  "pattern": "^\\d{2}:\\d{2}$",
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ]
-            },
-            "day": {
-              "enum": [
-                "Monday",
-                "Tuesday",
-                "Wednesday",
-                "Thursday",
-                "Friday",
-                "Saturday",
-                "Sunday"
-              ],
-              "type": "string"
-            },
-            "open": {
-              "anyOf": [
-                {
-                  "pattern": "^\\d{2}:\\d{2}$",
-                  "type": "string"
-                },
-                {
-                  "type": "null"
-                }
-              ]
-            }
-          },
-          "required": [
-            "day",
-            "open",
-            "close"
-          ],
-          "type": "object"
-        },
-        "maxItems": 14,
-        "type": "array"
-      },
-      "timezone": {
-        "anyOf": [
-          {
-            "maxLength": 64,
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      }
-    },
-    "required": [
-      "id",
-      "name",
-      "currency",
-      "defaultLocale",
-      "timezone",
-      "countryCode",
-      "firstDayOfTheWeek",
-      "appointmentDuration",
-      "openingHours",
-      "lastEditTime"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "appointmentDuration": {
+        "description": "Default session length in minutes",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "countryCode": {
+        "anyOf": [
+          {
+            "pattern": "^[A-Z]{2}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "currency": {
+        "anyOf": [
+          {
+            "pattern": "^[A-Z]{3}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "defaultLocale": {
+        "anyOf": [
+          {
+            "maxLength": 16,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "firstDayOfTheWeek": {
+        "anyOf": [
+          {
+            "enum": [
+              "Monday",
+              "Tuesday",
+              "Wednesday",
+              "Thursday",
+              "Friday",
+              "Saturday",
+              "Sunday"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "id": {
+        "pattern": "^[0-9a-f]{24}$",
+        "type": "string"
+      },
+      "lastEditTime": {
+        "anyOf": [
+          {
+            "maxLength": 32,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "name": {
+        "maxLength": 200,
+        "type": "string"
+      },
+      "openingHours": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "close": {
+              "anyOf": [
+                {
+                  "pattern": "^\\d{2}:\\d{2}$",
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "day": {
+              "enum": [
+                "Monday",
+                "Tuesday",
+                "Wednesday",
+                "Thursday",
+                "Friday",
+                "Saturday",
+                "Sunday"
+              ],
+              "type": "string"
+            },
+            "open": {
+              "anyOf": [
+                {
+                  "pattern": "^\\d{2}:\\d{2}$",
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            }
+          },
+          "required": [
+            "day",
+            "open",
+            "close"
+          ],
+          "type": "object"
+        },
+        "maxItems": 14,
+        "type": "array"
+      },
+      "timezone": {
+        "anyOf": [
+          {
+            "maxLength": 64,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "required": [
+      "id",
+      "name",
+      "currency",
+      "defaultLocale",
+      "timezone",
+      "countryCode",
+      "firstDayOfTheWeek",
+      "appointmentDuration",
+      "openingHours",
+      "lastEditTime"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / gym / description

Added value: +"Scheduling settings of the gym; null when not found. Address, phone, website, organization, billing, integrations, reminders, members and arbitrary metadata are excluded."

Changedget_gym_availability2 fields changed

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

addedOutput schema / properties / days / description

Added value: +"One row per day with open online-booking slots inside the gym's booking window, in date order. Slot counts and times only; members, appointments, trainers and the reason a time is unavailable are never exposed."

Changedget_gym_payment_summary6 fields changed

changedInput schema / properties / endTime / description

Previous value: -"Range end as an ISO 8601 value; defaults to seven days later"New value: +"End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start"

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

changedInput schema / properties / startTime / description

Previous value: -"Range start as an ISO 8601 value; defaults to now"New value: +"Start of the range as an ISO 8601 date-time, matched against when each payment was recorded; defaults to now, so pass a past date for past takings"

addedOutput schema / properties / statuses / description

Added value: +"Payment counts per status, such as SUCCEEDED, FAILED, CANCELED or OTHER"

addedOutput schema / properties / totals / description

Added value: +"Amount totals per currency, summed over every status including FAILED and CANCELED payments. Payment and member ids, processor or card data, contacts, notes, discounts, decline reasons, services and individual transactions are never returned."

addedOutput schema / properties / totalsArePartial / description

Added value: +"True when more than 100 payments fall in the range"

Changedget_gym_schedule_summary5 fields changed

changedInput schema / properties / endTime / description

Previous value: -"Range end as an ISO 8601 value; defaults to seven days later"New value: +"End of the range as an ISO 8601 date-time, after startTime and at most 31 days later; defaults to 7 days after the start"

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

changedInput schema / properties / startTime / description

Previous value: -"Range start as an ISO 8601 value; defaults to now"New value: +"Start of the range as an ISO 8601 date-time; defaults to now"

addedOutput schema / properties / days / description

Added value: +"One row per UTC day that has bookings, canceled ones included. Aggregate counts only: appointment ids and times, member information, services, notes, trainer data and attendance history are never returned."

addedOutput schema / properties / recordCountIsLowerBound / description
```
Added value: +"True when more than 100 bookings fall in the range"
```

Changedlist_gyms3 fields changed

changedInput schema / properties / cursor / description

Previous value: -"Opaque pagination cursor from a previous call"New value: +"The nextCursor of the previous page of this listing; absent for the first page"

addedOutput schema / properties / gyms / description

Added value: +"Gyms in the signed-in organization, alphabetical. Organization, address, contact, billing, integration and member data are never returned."

addedOutput schema / properties / nextCursor / description

Added value: +"Cursor for the next page; null on the last page"

Changedlist_services5 fields changed

changedInput schema / properties / cursor / description

Previous value: -"Opaque pagination cursor from a previous call"New value: +"The nextCursor of the previous page of this listing; absent for the first page"

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

addedOutput schema / properties / nextCursor / description

Added value: +"Cursor for the next page; null on the last page"

addedOutput schema / properties / services / description

Added value: +"Service catalog entries, alphabetical. Service ids, member history, notes, staff commissions, organization ids and arbitrary metadata are excluded."

addedOutput schema / properties / services / items / properties / price / description
```
Added value: +"Price in the gym's currency"
```

Changedshow_gym_overview2 fields changed

changedInput schema / properties / gymId / description

Previous value: -"Owned GymFlexa gym id to render"New value: +"Id of one of the user's gyms, as the gym list returns it (24 lowercase hex characters)"

addedOutput schema / properties / gym / description

Added value: +"Gym metadata; null when not found. The overview never reads or returns member records, individual appointments or payments, attendance or service history, trainers, notes or health and fitness details."

7 tool updatesSep 25, 2026
- First observedget_gym
- First observedget_gym_availability
- First observedget_gym_payment_summary
- First observedget_gym_schedule_summary
- First observedlist_gyms
- First observedlist_services
- First observedshow_gym_overview

Related MCP Connectors

DoctoFam Medical Clinic A
com.doctofam
See your clinic's free slots, doctors, rooms, service prices and how busy each day is.
Biology & Medicine Calendar Management
101
Veterical Vet Clinic A
com.veterical
See your vet clinic's free slots, vets, service prices, payments and how busy each day is.
Biology & Medicine Payments & Billing
111
HairDora Salon Scheduling A
com.hairdora
See your salon's free slots, appointments, stylists, services, clients, quotes and payments.
Calendar Management CRM Payments & Billing
141
LegitFitOAuth
com.legitfit
Access your LegitFit business data: revenue, payments, bookings, attendance, clients, memberships.
Finance ERP Systems
1

Related MCP Servers

GymCam Analytics
Fitness Tracking Health & Wellness
axelfreeman
A
license
A
quality
A
maintenance
Enables AI agents to query gym analytics—class attendance, trainer performance, and revenue insights—from existing CCTV camera feeds without new hardware.
Updated a month ago (2026-09-18 23:37 UTC)
4
3
MIT
Weekly Planning Assistant MCP
Calendar Management Workplace & Productivity
anastasiakrause
F
license
A
quality
D
maintenance
Provides intelligent weekly schedule analysis from Google Calendar, including day-by-day breakdowns, workout suggestions, office day detection, and scheduling problem identification through natural language queries.
Updated 9 months ago (2026-01-18 20:13 UTC)
4
-
booking-gap MCP Server
Calendar Management
h-kazuki-pixel
A
license
A
quality
A
maintenance
Measures the shape of idle time in a booking calendar. Separates gaps that can actually be sold from structurally unsellable dead time, accounting for turnover time and the booking start grid. Fully offline, no API key required.
Updated 2 months ago (2026-08-07 23:08 UTC)
4
MIT
bookings-mcp
Calendar Management CRM
satviksriv
A
license
A
quality
C
maintenance
Enables Claude to manage a service business front desk by searching customers, checking real-time availability, creating and canceling appointments without double-booking, and generating revenue reports from actual data.
Updated 21 days ago (2026-09-25 10:14 UTC)
9
MIT

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

Need Help?