Yoga, pilates, barre, aerial, hoop and pole studios by city.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 6 tools
Each tool targets a distinct action and resource: single listing retrieval, text/place/category search, category listing, place listing, source listing, and aggregate stats. There is no meaningful overlap between search_listings and get_listing because one is query-based and the other requires a slug.
All tool names follow a consistent snake_case verb_noun pattern: get_listing, get_stats, list_categories, list_places, list_sources, search_listings. The verbs accurately reflect the operations.
Six tools are well-scoped for a read-only studio directory. Each tool earns its place by covering discovery, lookup, facets, provenance, and summary statistics without bloat.
The surface covers the core read-only workflows: search, single lookup, categories, places, sources, and stats. Minor gaps exist, such as no explicit list-all-studios operation or dedicated category/place detail endpoints, but agents can work around these through search and list tools.
Get one published studio by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope by saying only 'published' studios are returned, which is context beyond annotations. It does not describe not-found behavior, so a 3 is appropriate.
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 sentence, front-loaded with the action and resource, with zero wasted words.
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 one-parameter read tool with full schema coverage and annotations covering safety and idempotency, the description supplies what an agent needs to call it. The only minor gap is not stating what happens when the slug does not match a published studio.
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 100% and the slug parameter is fully documented with a pattern and length bounds. The description's 'by its slug' adds no format or syntax details beyond the schema, so the baseline 3 applies.
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 (Get), resource (one published studio), and lookup key (slug). It does not explicitly name search_listings as the alternative for multi-result lookups, so it is clear but not fully differentiated from its siblings.
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 phrase 'by its slug' implies use when a slug is already known, but there is no explicit when-not or named alternative. An agent must infer that search_listings handles discovery and that this tool is for direct slug retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published studios, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful context about what data is counted and that freshness is returned, but it does not discuss return formatting, auth, or rate limits.
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?
It is a single front-loaded sentence with no redundant or filler text. Every element, counts and last-changed time, directly describes the result.
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 zero-parameter stats tool with no output schema, the description sufficiently states the returned metrics and freshness information. Annotations already cover the read-only and idempotent behavior.
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?
The tool has zero parameters, so there are no parameter semantics to explain. Per the baseline for parameterless tools, a 4 is appropriate.
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?
The description names a specific verb and resource set: retrieving counts of published studios, places, and categories plus the last-changed timestamp. This aggregate-purpose wording clearly distinguishes it from sibling listing tools such as list_categories and list_places.
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 is implied by the wording: agents can infer this is for aggregate counts rather than listing or searching records. However, the description does not explicitly say when to use it versus get_listing, list_* tools, or search_listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their studio counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful behavioral fact that counts are included in the result, but says nothing about ordering, pagination, or count semantics.
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?
One short sentence with zero waste, front-loading the verb and resource. Nothing extraneous and nothing buried.
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 no-parameter, read-only listing tool with no output schema, the definition covers what the agent needs: what is listed and that studio counts are attached. Slight gap in not clarifying whether the list is complete or filtered.
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?
The tool takes zero parameters, so per the baseline the schema carries no semantic burden and the description is not required to compensate. The description correctly implies a no-argument, full-list call.
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 (List) and resource (categories) and adds a useful detail, 'with their studio counts,' which tells the agent what comes back. It does not explicitly distinguish itself from siblings like list_places or get_stats, 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?
Usage is only implied: an agent can infer it should call this when it needs the category taxonomy, but there is no explicit when-to-use framing and no alternatives are named despite five sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have studios.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping detail that only places with studios are returned, but says nothing about ordering, completeness, or what the return shape looks like. With annotations doing the heavy lifting, this is adequate 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?
A single tight sentence with no filler. The resource and the 'have studios' constraint are both front-loaded, so the agent can read the scope immediately.
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 zero-parameter list tool with no output schema, the description names the three entity types returned and the studio qualifier. It could mention ordering or whether counts are included, but given the annotations and schema simplicity, it is close to complete.
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?
The tool takes zero parameters, so there is no parameter semantics burden and the baseline is 4. The description does not need to explain inputs and appropriately stays focused on the returned resource.
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?
Uses a specific verb (List) and a specific resource (countries, regions and cities) with a meaningful qualifier: only places that have studios. It is understandable on its own, though it does not explicitly name how it differs from siblings like list_categories or list_sources.
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 implies this is the discovery tool for geographic coverage, but it gives no explicit when-to-use guidance, no prerequisites, and no alternatives. It also does not clarify whether search_listings should be used when the agent already knows the place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the studio data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, idempotent operation with no open-world behavior. The description adds useful detail about what each source record includes (license and refresh), but it does not mention ordering, pagination, or completeness of the source list.
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?
The description is a single front-loaded sentence with no redundant or filler content. Every part of the sentence contributes to understanding what is returned.
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 zero-parameter, read-only listing tool, the description adequately explains the resource and the fields of interest. Since there is no output schema, it could say slightly more about the return shape, but the annotations already cover safety traits.
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?
The tool has zero parameters, so there are no parameter semantics to clarify. The baseline score of 4 is appropriate.
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?
The description gives a specific verb and resource: listing data sources, with the additional scope of license and refresh information. It is clearly distinct from siblings like list_categories or list_places, though it does not explicitly name those 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 description implies the tool is for inspecting data provenance, but it does not state when to use it versus other listing tools, nor does it name any alternatives or exclusions. No explicit usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published studios by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the meaningful scoping constraint that only published studios are returned, but says nothing about result ordering, pagination, or what a typo fallback means behaviorally.
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?
One sentence, front-loaded with the verb and resource, with zero filler. The scoping qualifier 'published' is placed where it matters most.
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 8 all-optional parameters and a fully documented schema, the short description is mostly sufficient; the cursor parameter even hints at the paginated response shape. The remaining gap is that no output schema exists and the description never indicates what a result item contains.
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 100%, so every parameter including sort defaults, cursor reuse and country 400 behavior is already documented in the schema. The description's 'text, place and category' phrasing merely summarizes parameter groupings without adding syntax or constraints 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 and resource with scope: 'Search published studios' by text, place and category. This clearly separates it from get_listing (single lookup) and the list_* siblings, though it never names those alternatives explicitly.
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 is only implied: the word 'published' signals that unpublished studios are excluded from results. There is no explicit statement of when to prefer this over get_listing or how to obtain slugs (that guidance lives only in the schema as '/places' and '/categories').
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.
get_listingget_statslist_categorieslist_placeslist_sourcessearch_listingsFind and book yoga, pilates and movement classes with independent teachers and small studios.
Cold plunge, sauna and contrast-therapy studios across US metros, each fact dated.
Find gyms and studios, see classes and prices, and book with Gymmy.
Find kids' enrichment providers (sports, swim, dance, arts, STEM, camps) in 39 US regions.
Add one secure layer between your agents and this server.
