Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wellpass-mcp find yoga studios within 3 km of Munich with a sauna"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server to search the EGYM Wellpass fitness network — studios and classes — from any MCP client (Claude Desktop, Claude Code, etc.).
Unofficial. This project is not affiliated with, endorsed by, or supported by EGYM or Wellpass. It talks to Wellpass's own app/web APIs on your behalf, using your own account. Use it for personal use and at your own risk; respect Wellpass's Terms of Service. No warranty (see
LICENSE).
Studios (no login required):
search_studios — studios near a location, filtered by activities,
services, Plus1, studio type, amenities, open-now, radius. City name or
lat/lon.
get_studio_details — full details for one studio.
list_studio_filters — every valid filter value.
Classes (require login — an active Wellpass membership):
search_classes — classes for one studio or the online catalogue.
search_classes_near — classes across studios near a location, with
filters (date, category, teacher, availability, online). Optionally also list
nearby studios that offer classes without an in-app schedule.
book_class / cancel_booking — two-step (preview, then
confirm=true) booking. These WRITE to your account.
Related MCP server: aidoo-mcp-server
Python 3.11+
Optional: uv (faster installs)
git clone <your-fork-url> wellpass-mcp
cd wellpass-mcp
./scripts/setup.shThe script creates a virtualenv in .venv, installs the package, and creates
.env from .env.example.
Manual alternative:
python3 -m venv .venv
.venv/bin/python -m pip install -e ".[dev]"
cp .env.example .envStudio search needs no login. For class search/booking, edit .env:
WELLPASS_EMAIL=you@example.com
WELLPASS_PASSWORD=your-password.env is git-ignored. Credentials are read only from the environment and are
never written to any other file.
The server speaks MCP over stdio. Point your client at the venv's Python.
Claude Code:
claude mcp add wellpass -- /absolute/path/to/wellpass-mcp/.venv/bin/python -m wellpass_mcp.serverClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"wellpass": {
"command": "/absolute/path/to/wellpass-mcp/.venv/bin/python",
"args": ["-m", "wellpass_mcp.server"]
}
}
}Then ask your assistant things like:
"Find yoga studios within 3 km of Munich with a sauna."
"What classes are near me tomorrow morning with free spots?"
"Show Fitness First Marienplatz classes on Saturday."
Classes exist only for some studios. The class API covers studios whose
booking is native to the platform (e.g. large chains) plus the online class
catalogue. Most small studios use external booking the app only links to;
search_classes_near can list them separately but has no times for them.
Booking depends on the studio and an active membership. Many classes are check-in based (no reservation). Booking is built but may return an external error for non-reservable classes.
The APIs are reverse-engineered and may change without notice.
.venv/bin/python -m pytest -q # offline tests (from fixtures)
.venv/bin/python -m wellpass_mcp.server # run the serverSee AGENTS.md for architecture and conventions, and docs/api-contract.md
for the reverse-engineered API details.
MIT — see LICENSE.
Book the user into a class. TWO-STEP and WRITES to the real account.
Step 1 (confirm=false, default): returns the class details and cancellation window and does NOT book. Relay this to the user. Step 2 (confirm=true): actually books. Only send confirm=true AFTER the user has explicitly agreed to book this specific class.
Args: club_uuid: The class's club_uuid (from a search result). class_id: The class id (from a search result). confirm: Must be true to actually book. Default false (preview only). spot: Optional spot id, for studios with spot selection.
| Name | Required | Description | Default |
|---|---|---|---|
| spot | No | ||
| confirm | No | ||
| class_id | Yes | ||
| club_uuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does well: it discloses that the call writes to the real account, that the default is a non-mutating preview, and that the preview returns class details plus the cancellation window. It omits what happens on failure (already booked, class full, waitlist) and any auth/permission requirements, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the critical two-step rule before the Args block, and the numbered steps are easy to scan. There is minor redundancy between the step descriptions and the confirm arg line ('Must be true to actually book. Default false (preview only)'), which repeats step 1, but overall it is tight and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the essential unknowns: what the preview returns, what confirm does, and the consent gate. It is only missing failure-mode behavior (errors, waitlists, capacity) and any auth prerequisites an agent might need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it documents all four parameters: the origin of club_uuid and class_id ('from a search result'), confirm's semantics and default, and that spot is optional and only applies to studios with spot selection. It adds real meaning beyond the bare schema types, though it doesn't give format examples for the IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Book the user into a class') and immediately distinguishes itself from siblings like search_classes and cancel_booking by declaring it WRITES to the real account. An agent can tell what this does and that it is the terminal action of the search-then-book flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lays out a two-step protocol: confirm=false returns details without booking, confirm=true books only after the user explicitly agrees. This is exactly the when/when-not/alternative guidance an agent needs, including the gating condition (user consent) for the destructive step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel the user's booking for a class. TWO-STEP and WRITES to the account.
confirm=false (default) previews; confirm=true cancels. Only cancel after the user explicitly agrees. Check the cancellation window first.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| class_id | Yes | ||
| club_uuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it flags TWO-STEP, WRITES to the account, and that the default is a non-mutating preview. It doesn't state irreversibility, what happens if the cancellation window has passed, or auth/error behavior, but the safety profile is substantially disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action in the first sentence, then the two-step/safety guidance, then the preconditions. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param mutation tool with no annotations and no output schema, the description covers the risky path and the preview mode well. The remaining gap is where the required club_uuid and class_id come from (presumably search_classes), which an agent would need to infer from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains the critical 'confirm' parameter (default false previews, true cancels), but says nothing about class_id or club_uuid — not their format nor where to obtain them — leaving two of three parameters undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Cancel the user's booking for a class') and implicitly delimits itself against the sibling write tool book_class and the read-only search tools. An agent can tell immediately that this is the destructive counterpart to booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditional guidance ('confirm=false (default) previews; confirm=true cancels') plus a hard prerequisite ('Only cancel after the user explicitly agrees') and a pre-check ('Check the cancellation window first'). It stops short of naming any alternative tool, though cancellation has no real sibling substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for one studio by its slug (from search_studios).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but it says nothing about permissions, rate limits, or what 'full details' actually contains. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with the resource, the identifier, and its provenance — no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read lookup with no output schema and no annotations, the description is minimally adequate: it says how to obtain the slug. It does not describe the returned detail set, which the absent output schema leaves uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there is one required parameter, so the description must compensate. It does add meaning by indicating the slug comes from search_studios, which the bare 'Slug' string type does not convey, but it gives no format or validation detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get full details for one studio') scoped to a single entity identified by slug. It implicitly contrasts with the sibling search_studios (which returns many), though it does not explicitly name list_studio_filters or other siblings as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(from search_studios)' hints at where the required slug originates, which is genuine usage context. However, there is no explicit when-to-use versus search_studios or list_studio_filters, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every studio filter value: activities, services, toggles, categories.
This is the ground truth for the activities and services arguments of
search_studios. language picks the label language (de/en/fr/nl).
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | dach | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It implies a read-only enumeration and describes the return content (filter categories, label language), but says nothing about the `region` parameter's effect, permissions, or caching/rate behavior. Adequate for a low-risk listing tool, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with what is listed, then the purpose relative to search_studios, then the language note. No filler; only minor tightening possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of indicating what comes back (the four filter categories) and how the result connects to search_studios. It is nearly sufficient, with the unexplained `region` effect the one meaningful omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and neither parameter is documented in the schema, so the description must compensate. It does well on `language`, adding the de/en/fr/nl values that the bare string/enum-less schema omits, but `region` (default 'dach') is never explained, leaving half the parameters without meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every studio filter value') and enumerates the categories returned (activities, services, toggles, categories). It also positions itself against the sibling search_studios by declaring itself the ground truth for that tool's arguments, so an agent can distinguish it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: call this to discover valid values before invoking search_studios' activities/services arguments. That is strong contextual guidance, but it stops short of explicit when-not conditions or other alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookable Wellpass classes for a studio (or online), with filters.
Needs WELLPASS_EMAIL and WELLPASS_PASSWORD in .env (classes are gated).
Pick ONE target:
- studio_slug: a studio from search_studios (its classes).
- club_uuid: the club_uuid field from a search_studios result.
- online=True: the online / live-stream class catalogue.
Args:
studio_slug: Studio slug whose classes to list.
club_uuid: Netpulse club uuid (from search_studios club_uuid).
online: Search the online class catalogue instead of a studio.
date_from: ISO date/datetime for the window start. Default: now.
date_to: ISO date/datetime for the window end. Default: now + 7 days.
category: Keep classes whose activity matches (e.g. "yoga", "Body & Mind").
teacher: Keep classes by this instructor (substring, case-insensitive).
available_only: Keep only classes with a free spot.
limit: Max classes to return (1-100). Default 30.
Returns: A dict with the resolved club, the window, and a class list (soonest first). Each class has name, category, start/end, teacher, free spots, capacity, and online flag.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| online | No | ||
| date_to | No | ||
| teacher | No | ||
| category | No | ||
| club_uuid | No | ||
| date_from | No | ||
| studio_slug | No | ||
| available_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that classes are gated behind WELLPASS_EMAIL/WELLPASS_PASSWORD in .env, supplies default date window behavior, caps limit at 1-100, and describes the return payload. It does not state what happens if no target is supplied, nor any rate-limit or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by three labelled blocks (target selection, Args, Returns). Every line carries information an agent needs and there is no filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter tool with no annotations and no output schema, the description supplies auth requirements, targeting constraints, parameter semantics, defaults, and an explicit Returns summary. The one omission is behavior when none of the three targets is provided, given that the schema declares zero required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and all nine parameters are undocumented in the schema, so the description must compensate entirely — and it does, giving each an explicit meaning, plus defaults (date_from=now, date_to=now+7d, limit=30) and match semantics (teacher is a case-insensitive substring, category matches activity, available_only requires a free spot). This is the strongest section.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search bookable Wellpass classes for a studio (or online), with filters'), and the parenthetical scope '(or online)' signals the dual targeting mode. It does not explicitly differentiate itself from the sibling search_classes_near, which an agent would likely weigh against it, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Pick ONE target' with three enumerated mutually exclusive modes is clear when-to-use guidance, and it routes the agent to search_studios for the studio_slug and club_uuid values. It never states when to prefer this tool over search_classes_near, leaving the main sibling ambiguity unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find bookable classes NEAR a location, across studios, with filters.
Needs login (.env). Note: only a minority of studios expose structured classes (Netpulse-native, e.g. Fitness First); most small studios use external booking and are not included. Online classes are included by default. The first call near a new area is slower (it probes studios); later calls are fast (native studios are cached).
Args:
location: City/place. Default Munich. Ignored if latitude+longitude set.
latitude, longitude: Exact search point.
radius_km: Only studios within this distance. Default 5 km.
date_from, date_to: ISO date/datetime window. Default: now .. now+7d.
category: Keep classes whose activity matches (e.g. "yoga", "cardio").
teacher: Keep classes by this instructor (substring, case-insensitive).
available_only: Keep only classes with a free spot.
include_online: Also include the online class catalogue. Default true.
include_studios_without_times: Also list nearby studios that offer
classes but expose no in-app schedule (external booking). They come
back under studios_without_times, not as timed classes. Default
false (hide them).
limit: Max classes to return (1-100). Default 40. Soonest first.
Returns: Classes (soonest first), each with studio, distance_km, club_uuid, and a class id — pass club_uuid + id to book_class.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| date_to | No | ||
| teacher | No | ||
| category | No | ||
| latitude | No | ||
| location | No | Munich | |
| date_from | No | ||
| longitude | No | ||
| radius_km | No | ||
| available_only | No | ||
| include_online | No | ||
| include_studios_without_times | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely meets it: it discloses the auth requirement, a significant coverage limitation (only Netpulse-native studios expose structured classes), default online inclusion, and a first-call latency penalty due to studio probing followed by caching. It does not cover failure modes, rate limits, or pagination, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-sentence purpose followed by Args and Returns blocks; the latency/coverage caveat sits early where it matters. Every line carries information, though the multi-line caveat paragraph could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no annotations, no output schema, and no schema descriptions, the description supplies auth, coverage caveats, latency behavior, full parameter semantics, and even the return shape and booking handoff. Error/empty-result behavior is the only notable omission; with no output schema it otherwise stands alone well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 12 parameters, yet the Args block documents every one with defaults and semantics: location default and precedence over lat/lon, radius default 5 km, window default now..now+7d, substring/case-insensitive teacher matching, the non-obvious include_studios_without_times behavior returning `studios_without_times`, and the limit range (1-100). It fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: "Find bookable classes NEAR a location, across studios, with filters." It is clearly differentiated from booking tools by the closing handoff to book_class, but the sibling search_classes is never addressed, so an agent cannot tell from this text alone which of the two search tools to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: it explains coverage ("most small studios use external booking and are not included"), prerequisites ("Needs login (.env)") and the downstream call ("pass club_uuid + id to book_class"). However, it never says when to use this tool versus search_classes, and it offers no exclusions or alternative-selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search EGYM Wellpass studios (gyms) near a location, with filters.
Args: location: City or place name. Default "Munich". Ignored if latitude and longitude are both given. latitude: Optional exact latitude of the search point. longitude: Optional exact longitude of the search point. radius_km: Only return studios within this distance. Default 10 km. activities: Activity filters. Accept a slug ("activity-yoga"), a bare name ("yoga"), an activity type ("YOGA"), or a label ("Yoga"). Several activities are combined with OR. services: Service/amenity filters, same spelling rules (e.g. "sauna", "service-sauna", "free-parking"). Combined with AND across groups. plus_one: Only studios that allow a Plus1 guest. studio_types: Keep only these studio types (e.g. "PILATES", "WELLNESS"). gym_info: Require these gym-info flags (e.g. "COURSES_IN_ENGLISH", "ACCESSIBLE_TO_PREGNANT_WOMEN"). open_now: Only studios open at the current local time. limit: Max studios to return (1-50). Default 20. region: Catalog: "dach" (default), "all", "us", "fr-be", "dach-us".
Returns: A dict with the resolved center, applied filters, and a ranked studio list (nearest first). Call list_studio_filters for valid filter values.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| region | No | dach | |
| gym_info | No | ||
| latitude | No | ||
| location | No | Munich | |
| open_now | No | ||
| plus_one | No | ||
| services | No | ||
| longitude | No | ||
| radius_km | No | ||
| activities | No | ||
| studio_types | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses combination logic (activities OR'd, services AND'd across groups), ranking (nearest first), defaults, and the return shape (resolved center, applied filters, ranked list). It omits auth requirements, rate limits, and pagination behavior, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a one-line purpose, then a structured Args and Returns block where each entry earns its place. Slightly long, but the length is justified by 12 undocumented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the Returns section describes the resolved center, applied filters, and ranked list. Combined with per-parameter documentation, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 12 parameters, so the description must compensate entirely, and it does: every parameter gets meaning, defaults, and accepted value forms (slug/bare name/type/label for activities, region catalog values, limit range 1-50). This is well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (EGYM Wellpass studios/gyms) plus the core scoping dimension (near a location, with filters). It is clearly distinguishable from siblings search_classes and search_classes_near, which operate on classes rather than studios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context (location defaults to Munich, ignored when lat/long given) and routes the agent to list_studio_filters for valid filter values. It does not, however, state when to prefer this over search_classes_near or other studio-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0book_classcancel_bookingget_studio_detailslist_studio_filterssearch_classessearch_classes_nearsearch_studiosScored across 7 tools
Most tools have clearly distinct purposes: studio lookup, filter catalog, studio search, class search, booking, and cancellation. The only real overlap is search_classes vs search_classes_near, but the descriptions clearly differentiate per-studio vs location-wide searching.
All tools follow a consistent snake_case verb_noun pattern (get_*, list_*, search_*, book_*, cancel_*). No mixed conventions or vague verbs.
Seven tools is well-scoped for a studio/class discovery and booking domain, with each tool earning its place and no redundancy.
The surface covers search, detail, filters, class discovery, booking, and cancellation with sensible two-step write semantics. The main gap is the absence of a tool to list the user's existing bookings, which would help before cancelling or rebooking.
Manage fitness coaching clients, workouts, programs, chats and funnels from your assistant.
Look up Momence members, class schedules, bookings and memberships, and handle front-desk actions.
Talk to your own gym log. Reps is a free workout tracker for iPhone and Android; connect it to Claude, ChatGPT or any MCP client and ask about your workout history, personal records, exercise progression, weekly summaries, routines and training plan. The assistant can also save a new routine, edit one, save a whole plan, add custom exercises and exercise notes, always after you confirm in the chat. It cannot log a workout or delete your history. Requires a free Reps account created in the app; you sign in with a one-time email code.
Pace is a remote MCP server that exposes wearable and fitness data to Claude via the Model Context Protocol. It connects to Garmin, Oura, Whoop, Polar, Fitbit and 20+ devices and provides 15 tools for querying sleep, activity, recovery, and training data. Hosted on Google Cloud Run, OAuth 2.1 authentication, Streamable HTTP transport. Instructions: First you need to create an account at: https://pacetraining.co and connect your wearables. After that you can connect the remote Server via Custom Connector in Claude and OAuth 2.1 Flow startet.
