GymFlexa Gym Management

Look up class and service prices

list_services

Read-onlyIdempotent

Use this when someone asks what their gym charges for a class, personal training session or other service, or needs a service id to book it. Returns catalog service ids, names, prices and last edit times for one gym, alphabetical, 25 per page by default. Not for what a particular member bought or attended.

Input 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 4, 2026

changedOutput schema / properties / services / description

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

addedOutput schema / properties / services / items / properties / id

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[0-9a-f]{24}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The id book_appointment takes in serviceIds"
+}

changedOutput schema / properties / services / items / required

Previous value: -[
-  "name",
-  "price",
-  "lastEditTime"
-]New value: +[
+  "id",
+  "name",
+  "price",
+  "lastEditTime"
+]

Changed5 schema fields changedSep 28, 2026

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"
```

First observedSep 25, 2026

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-open-world and non-destructive, so the safety profile is covered. The description adds useful behavior beyond that: results are scoped to exactly one gym, ordered alphabetically, and paginated at 25 by default. It doesn't discuss error behavior for an invalid or unauthorized gymId, which is the main remaining gap.

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, front-loaded with the use case, then the return shape and paging, then the exclusion. No filler and no repetition of the 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?

For a read-only, three-parameter listing tool with full schema coverage and an output schema, the description supplies everything an agent needs to select and invoke it: trigger, scope, ordering, and page size. Return-field documentation is correctly left to the output schema.

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%, including the 24-hex format for gymId and the 25 default / 100 max for limit, so the schema already carries the parameter detail. The description's 'one gym' and '25 per page by default' restate schema facts rather than adding new semantics; only the alphabetical ordering is genuinely new, and that concerns output. 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?

States a specific verb ('look up' / returns) plus resource (catalog services: classes, personal training, other services) and the fields returned. The closing sentence explicitly separates it from member purchase/attendance data, so it is distinguishable from list_members, list_appointments and the purchase-oriented siblings without opening their schemas.

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?

The opening clause gives the exact triggering condition (user asking what their gym charges, or needing a service id to book), and the final sentence gives an explicit exclusion ('Not for what a particular member bought or attended'). Both when-to-use and when-not are present; a named alternative tool would be a bonus but none of the siblings covers the excluded case directly.

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

All GymFlexa Gym Management tools Inspect

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?