Find and book yoga, pilates and movement classes with independent teachers and small studios.
Scored across 12 tools
Most tools target distinct resources and actions: search_classes, search_mentors, search_studios, search_videos, and search_help_articles are clearly separated, as are get_mentor and the list_* tools. Minor ambiguity exists between search_videos and list_host_videos, and get_class_payment_methods references 'book_class' while the actual tool is book_class_as_guest, but boundaries are still understandable.
Names are consistently snake_case and mostly follow a verb_resource pattern (search_*, list_*, get_*, book_*). The main deviation is 'list_host_videos' using 'host' while the rest of the set uses mentor/studio, and 'book_class_as_guest' is more verbose than the other names.
Twelve tools is well within the appropriate range for a multi-resource marketplace server. The set is scoped to search, discovery, and a limited booking flow without excessive or trivial tools.
The surface is search- and read-heavy but incomplete for a booking marketplace. Several described actions reference tools that are not present: book_private_session, buy_class_pack, and send_mentor_inquiry are named in descriptions but absent, creating dead ends when an agent tries to complete private-session booking, pack purchase, or mentor inquiry workflows.
Book a class, event or retreat for a person with no MoveMentors account. No sign-in needed: ask the person for their name and email and pass them in. The seat is held while the person pays by card: the response has a single-use Stripe Checkout URL to open in a browser (a payment vault or one-time card works there). The seat is released if unpaid, and once paid the confirmation email, with a link to change or cancel, goes to guestEmail in the language given. Only card-paid bookings work here; for a free class, a host paid in cash or by bank transfer, a host who checks phone numbers by text, a promo code or a retreat payment plan, the tool answers with the class page where the person books it themselves (no account needed). Find scheduleId with search_classes. For a pay-what-you-can class pass pwycAmountCents (at least minPriceCents from search_classes). Limited to a few bookings an hour per person.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| locale | No | Language for the emails and booking page. Defaults to English. | |
| guestName | Yes | The person's full name, as the host will see it. | |
| partySize | No | Total seats to reserve, including the person booking. | |
| guestEmail | Yes | Where the confirmation email and booking link go. Use the person's own address. | |
| scheduleId | Yes | Schedule ID (use search_classes to discover). | |
| pwycAmountCents | No | Pay-what-you-can classes only: the per-seat amount the person chooses, in cents of the class currency. Defaults to the suggested price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full load and does so: seat is held during payment, payment is a single-use Stripe Checkout URL opened in a browser, the hold is released if unpaid, and confirmation plus a change/cancel link goes to guestEmail. The fallback response for unsupported booking types and the hourly booking cap are behaviors nothing else declares.
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?
Purpose is front-loaded and every sentence adds a fact about payment, fallback or parameter sourcing, but it is delivered as one dense block with several clauses stacked into the long negative-case sentence, which slightly blunts scanability.
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?
There is no output schema, so the description must describe returns — and it does: a single-use Stripe Checkout URL on success, or a class page URL for unsupported booking types. For a seven-parameter mutation with no annotations, an agent has everything needed to call it and to predict both outcomes.
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 86%, yet the description still adds meaning: pwycAmountCents applies only to pay-what-you-can classes and must be at least minPriceCents from search_classes, locale drives both emails and the booking page, and scheduleId comes from search_classes. It stops short of explaining notes or the interaction between partySize and pwycAmountCents.
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 a class, event or retreat for a person with no MoveMentors account') and immediately narrows the case to guest, card-paid bookings. The reader can distinguish this from search_classes and the listing siblings without opening the schema.
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 enumerates the cases this tool handles and the cases it does not — free classes, cash/bank-transfer hosts, text-verification hosts, promo codes and retreat payment plans — and tells the agent what happens instead (a class page for self-booking). It also names search_classes as the source of scheduleId and states a per-person rate limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the list of payment methods the payee accepts for a class. Use this before calling book_class so you can ask the user which one to use (especially when the class's payee doesn't have Stripe enabled). Each entry has a canonical key (pass that to book_class as paymentMethod) and a human-readable label. Note: full payment details (bank account number, PayPal handle, etc.) are NOT returned here — they live on the confirmation page after booking, since they're sensitive to the payee.
| Name | Required | Description | Default |
|---|---|---|---|
| classId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it explains that each entry has a canonical key and human-readable label, and explicitly notes that sensitive full payment details are not returned and instead appear on the confirmation page after booking. It does not describe auth, pagination, or read-only status, but for a simple lookup it covers the important behavioral and privacy traits.
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 sentences front-load the purpose, then usage guidance, then output and privacy constraints. Each sentence adds distinct information and there is no repetitive or filler wording.
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 one-parameter lookup with no annotations or output schema, the description explains usage, return entry structure, and sensitive-data exclusion. The main remaining gap is that classId's source and format are not described.
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 sole input parameter, classId, has 0% schema description coverage. The description only implies it identifies a class; it does not explain where to obtain the ID, its format, or error behavior, so it fails to compensate for the schema gap.
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 opens with a specific verb and resource: 'Return the list of payment methods the payee accepts for a class.' That makes the tool's purpose immediately clear and distinct from the sibling search/list tools, none of which deal with class payment methods.
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?
It explicitly says to use this before calling book_class so the agent can ask the user which payment method to use, including the special case when the payee does not have Stripe enabled. It lacks when-not-to-use conditions and does not mention book_class_as_guest, but the primary 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.
Fetch full public details for a single mentor by slug: bio, location, ratings, certifications, taught styles, and canonical URL. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Mentor slug (the part after /mentors/...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose two useful traits: the operation is read-only and the data returned is the public-facing view of a mentor. It says nothing about authentication requirements, rate limits, or what happens when the slug does not resolve, which are the remaining behavioral facts an agent would want before calling.
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?
Two short sentences, front-loaded with the verb and resource, followed by the field summary and the read-only note. Every clause carries information; nothing is redundant or padded.
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 no output schema, enumerating the returned fields in the description usefully compensates for the missing return definition. The only real gap is failure behavior for an invalid slug, which is minor at this complexity level.
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?
There is a single parameter and schema description coverage is 100%; the schema already explains that slug is the segment after /mentors/. The description's "by slug" restates this without adding new syntax or format detail, so 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?
The description states a specific verb and resource ("Fetch full public details for a single mentor") and enumerates the returned fields (bio, location, ratings, certifications, taught styles, canonical URL). It implicitly contrasts with the list-oriented sibling search_mentors via "single mentor by slug," but never names that alternative, so sibling differentiation is inferred rather than stated.
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 this is the detail-lookup counterpart to search_mentors because of "single mentor by slug." There is no explicit when-to-use guidance, no guidance on obtaining a slug, and no stated exclusions or error conditions for an unknown slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a mentor's or studio's published video library by slug (pass exactly one of mentorSlug / studioSlug). Returns title, durationSec, priceCents (0 = free), currency, hasPreview (whether a free watchable snippet of the actual video exists on the page), and the public page path for each video. Buying or claiming happens on that page (/videos/{id}) and requires a free MoveMentors account; the video saves to the buyer's library and plays on any signed-in device. Videos a mentor includes with their membership are free to watch for that mentor's active subscribers. Hosts keep 100% of video sales. Hosts manage their library at /mentor/library or /studio/library.
| Name | Required | Description | Default |
|---|---|---|---|
| mentorSlug | No | ||
| studioSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it enumerates returned fields (title, durationSec, priceCents, currency, hasPreview, page path), defines the sentinel "priceCents (0 = free)", and explains hasPreview precisely. It omits pagination behavior and the error case when zero or two slugs are supplied, and the purchase/membership/revenue paragraphs describe the product, not this tool's 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?
The first two sentences are tight and front-loaded with purpose and return shape. The remainder is largely off-task: buying/claiming flow, account requirements, membership entitlements, host revenue share, and library-management URLs do not help an agent invoke a read-only listing call.
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 two-param read tool with no output schema, the description covers both the input selector rule and the return payload in enough depth to call it correctly. Remaining gaps (pagination, no-result behavior, ordering) are minor but real.
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 both properties are bare strings with no oneOf, so the description's mutual-exclusivity rule ("pass exactly one") supplies semantics the schema entirely lacks. It stops short of explaining what a slug is or how to obtain one, so not a 5.
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?
Opens with a specific verb+resource+"published" qualifier: "List a mentor's or studio's published video library by slug." The selector (mentor vs studio) and the published-only scope let an agent distinguish this from search_videos at a glance.
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 constraint "pass exactly one of mentorSlug / studioSlug" is genuinely useful invocation guidance, but there is no when-to-use vs when-not guidance and the sibling search_videos is never mentioned. The agent must infer that this is the exhaustive-library path while search_videos is the query path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a mentor's active class packs by slug. Returns name, sessionCount, priceCents, currency, validityDays for each pack. Public read; useful when a client asks 'what packs does X sell?' or before calling buy_class_pack.
| Name | Required | Description | Default |
|---|---|---|---|
| mentorSlug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the important traits: 'Public read' (no auth required) and 'active' only (inactive packs excluded). It omits ordering, pagination, and what happens for an unknown slug, which matter for a list endpoint.
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 sentences, front-loaded with purpose, then return fields, then usage context. No filler and no repetition of the tool 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?
There is no output schema, so enumerating the returned fields (name, sessionCount, priceCents, currency, validityDays) is valuable and covers most of what an agent needs. Remaining gaps are minor: result ordering, empty-result behavior, and pagination for mentors with many packs.
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 the single parameter has no description in the schema. The phrase 'by slug' and 'a mentor's ... packs' implies mentorSlug identifies a mentor rather than a class, which is genuinely useful disambiguation, but no format or example value is given.
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 qualifiers: 'List a mentor's active class packs by slug.' The 'active' filter and mentor-scoping are explicit, and no sibling tool (search_classes, get_mentor, get_class_payment_methods) covers class packs, so an agent can distinguish it without opening the schema.
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 concrete usage context: 'useful when a client asks what packs does X sell?' and 'before calling buy_class_pack', which names the downstream tool this feeds. It gives no explicit exclusions or note about inactive/expired packs beyond the word 'active', so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See what a mentor offers for private one-to-one sessions: each place with its lengths and prices, the ways to pay the mentor, the cancellation policy and, when durationMinutes is given, the open start times (UTC ISO, with the place's IANA time zone) over the next days. Open times already leave out classes, other bookings, time the mentor blocked and the 12-hour notice. An empty places list means the mentor has not opened private sessions; use send_mentor_inquiry instead. Book a time with book_private_session. The same flow for a person is the 'Book a private session' section on the mentor's public profile.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| mentorSlug | Yes | Mentor profile slug. | |
| durationMinutes | No | Session length. Omit to get only the lengths and prices. |
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 open times already exclude classes, other bookings, blocked time, and the 12-hour notice window, and it specifies the time format (UTC ISO plus the place's IANA time zone). What it omits is any statement about access requirements or side effects, though the read-only nature is strongly implied by 'See'.
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 conditional behavior and the empty-result escape hatch are front-loaded, and most clauses earn their place. The closing pointer to the mentor's public profile 'Book a private session' section is orienting but is the least load-bearing sentence and inflates an otherwise dense description.
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 read-only tool with no output schema, the description fully covers the return shape (places, lengths, prices, payment ways, cancellation policy, open times), the empty-result case, and the next action. Nothing an agent needs in order to call this correctly is missing.
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 67%, and the description fills the main gap by explaining the conditional effect of durationMinutes (only then are open start times computed) and that `days` bounds the lookahead window. mentorSlug and the enum values are already documented in the schema, so this is genuinely additive rather than redundant.
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?
Opens with a concrete verb and resource ('See what a mentor offers for private one-to-one sessions') and immediately enumerates the returned facets: lengths, prices, payment methods, cancellation policy, and open start times. An agent can tell this apart from search_mentors or list_mentor_class_packs 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names explicit branches: omit durationMinutes to get only lengths and prices, supply it to get open start times, and an empty `places` list means the mentor has not opened private sessions, in which case use send_mentor_inquiry. It also routes the booking step to book_private_session, so both the alternative and the follow-on action are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reviews for a specific class (by id or slug), latest first. Includes the rating, written review, mentor response (when present), and reviewer first-name-only. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| classId | No | ||
| classSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden; it does well by disclosing ordering, the returned fields including anonymization ('reviewer first-name-only'), and the no-auth requirement. It omits edge behavior such as what happens when neither classId nor classSlug is supplied, or whether the result is capped/paginated beyond the limit.
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?
Two short sentences, front-loaded with purpose and ordering, then return contents and the auth note. Every clause carries information; nothing is redundant.
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 small three-parameter read tool with no output schema, the description covers purpose, ordering, and return shape including privacy handling. The remaining gap is the unresolved semantics of the two optional identifier parameters, which is the main thing an agent could get wrong.
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 has to compensate and only partly does: it explains that classId and classSlug are alternative identifiers, but not their precedence or mutual exclusivity, and says nothing about 'limit' beyond what the schema constraints already encode (default 10, max 50).
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 reviews for a specific class'), names the two lookup keys (id or slug), and adds the ordering ('latest first'). No sibling tool covers reviews, so there is no ambiguity to resolve against the likes of search_classes or get_mentor.
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 context for use (fetching the review set for one class, identified by id or slug) and a useful operational note ('No auth required'), but never states exclusions or what to do when the class identifier is unknown — e.g., whether to fall back to search_classes first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookable classes, events, or retreats by query, city, discipline, date, session type, kind, or format (in-person vs online). Returns id, slug, title, kind, price, pricingModel, currency, duration, instructor, location, isOnline, meetingProvider, and the canonical URL. When pricingModel is PWYC (pay what you can), priceCents is the suggested amount and minPriceCents the lowest the user may pay (0 means they may attend free): ask the user what they want to pay and pass it to book_class as pwycAmountCents. Each result includes the next upcoming schedule. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | No | ISO date (YYYY-MM-DD). | |
| kind | No | Programming kind. CLASS = recurring per-session classes (the default mix); EVENT = focused workshops with an agenda; RETREAT = multi-day arcs with optional installment payments. | |
| type | No | ||
| limit | No | Maximum results to return. | |
| query | No | ||
| format | No | Filter by class format. `online` returns classes taught remotely (mentor's connected Google Meet or Zoom mints the join link at booking time). `in_person` returns classes hosted at a physical venue. Omit to include both. | |
| category | No | Class type slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the full behavioral load, and it does so credibly: it declares 'Read-only', spells out the return payload, says each result carries the next upcoming schedule, and explains the PWYC pricing model (priceCents = suggested, minPriceCents = floor, 0 = free). Gaps remain around pagination/truncation behavior and ordering, which matter for a search tool with a default limit of 10.
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 scope and filter facets come first, returns next, and the PWYC booking hand-off last — a sensible front-loaded order. It is slightly longer than needed; the returned-field enumeration could have been trimmed, but every sentence still serves a purpose.
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 available, the description usefully enumerates the response fields and mentions the embedded next-session schedule, which is exactly what an agent needs. For an eight-parameter, fully optional search tool the remaining shortfall is pagination and result-ordering semantics rather than core capability.
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 a middling 63%, and the description's facet list (query, city, discipline, date, session type, kind, format) maps loosely onto the eight parameters, adding some orientation. But the three undocumented parameters (city, type PRIVATE/GROUP, query) get no added meaning — notably it never says what fields 'query' matches against or how 'discipline' relates to the 'category' slug param.
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?
It opens with a specific verb and resource ('Search bookable classes, events, or retreats') and enumerates every filter facet, which is enough to tell it apart from search_mentors, search_studios, and search_videos without opening any schema. It also lists the returned fields, so the agent knows exactly what kind of entity comes back.
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 clear this is the discovery step and even routes the agent forward: when pricingModel is PWYC, ask the user what they want to pay and pass it to book_class as pwycAmountCents. That cross-tool hand-off is genuine usage guidance. It does not, however, state when to prefer a sibling such as search_mentors or what to do if a search returns nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the MoveMentors help center for articles matching a free-text query. Returns the top matches with title, description, category, locale, and a permalink the agent can cite or fetch for the full markdown body. Filter by category slug (e.g., 'payments', 'for-mentors') or locale ('en', 'es', etc.). No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| locale | No | Locale of the article body to search. Defaults to English. | en |
| category | No | Optional category slug. Run with no category once to discover; the response includes categories alongside results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does most of it: it discloses that results are ranked 'top matches' with specific fields (title, description, category, locale, permalink) and that no authentication is needed. It leaves the ranking method, the limit default/ceiling, and whether the search is keyword or semantic unexplained — meaningful gaps for a tool with zero annotation coverage, but the read-only, low-risk nature is unambiguous.
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 sentences that are front-loaded with purpose, then filtering, then access requirements. No filler, no restatement of the tool name, and the permalink/citation detail is genuinely useful rather than padding.
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 four-parameter search tool with no annotations and no output schema, the description covers purpose, result fields, filtering, and auth. The only omissions are the meaning of 'limit' and how matching works — minor, but they leave an agent slightly under-informed about result volume.
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?
At 50% schema coverage, the description must compensate for 'query' and 'limit', which have no schema descriptions. It clarifies 'query' as free text and gives concrete slug examples for 'category' and locale codes ('en', 'es'), which is real added value — but 'limit' is never mentioned, so the default of 8 and the maximum of 20 must be inferred from the schema alone.
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 uses a specific verb and resource — 'search the MoveMentors help center for articles matching a free-text query' — and distinguishes it from the search_classes/search_mentors/search_studios/search_videos siblings, which share the verb but target entirely different resources. An agent can route to it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the filtering options (category slug like 'payments'/'for-mentors', or locale) and notes 'No auth required', plus it implies a two-step workflow: search, then cite or fetch the permalink for the full body. It gives clear usage context but never states when not to use it or names an explicit alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search instructor profiles by free-text query, city, or discipline (yoga, pilates, meditation, etc). Returns slug, display name, city, ratings, top class types, and the canonical public URL. Many instructors also offer client-bookable private one-on-one sessions, bookable directly from their profile page (pick a room, length, and open half-hour slot). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (case-insensitive). | |
| limit | No | Maximum results to return. | |
| query | No | Free-text search across name/bio/class types. | |
| category | No | Class type slug (e.g. 'vinyasa', 'pilates'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose the safety profile in one word ('Read-only') and enumerates the returned fields, which is genuinely useful. However, it says nothing about pagination, result ordering, empty-result behavior, or rate limits, and the closing sentences about private sessions describe downstream booking rather than how this tool behaves.
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 first sentence is well front-loaded and does the real work. The subsequent private-session passage ('pick a room, length, and open half-hour slot') is promotional context that does not help an agent decide to call this tool or fill its parameters, so it dilutes an otherwise tight definition.
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 correctly compensates by listing return fields (slug, display name, city, ratings, top class types, public URL). All four parameters are covered by schema text and no mutation or auth complexity exists, so the definition is complete enough for correct invocation; only pagination/result-ordering detail is missing.
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 100%, so the baseline is 3; the description earns a small lift by naming the discipline vocabulary ('yoga, pilates, meditation, etc') that maps to the class-type-slug parameter, giving examples beyond the schema's 'vinyasa'/'pilates'. It adds nothing about the limit parameter or how multiple filters combine, so it stops short of a 5.
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 opens with a specific verb and resource — "Search instructor profiles" — and enumerates the three filter dimensions (free-text query, city, discipline), plus the returned fields. It does not name a sibling, so an agent must infer the split versus get_mentor (single profile) and search_classes (classes, not instructors) from names alone.
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 rather than stated: the reader infers this is the discovery tool for instructors and that get_mentor fetches one by slug. There are no explicit when-to-use/when-not conditions, no prerequisites, and no routing to alternatives such as search_classes for class-level searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search studios and gyms by free-text query or city. Pass rentable=true to restrict results to studios with at least one location that publishes rentable space (visiting mentors can claim slots and pay rent via Stripe Connect). Returns slug, business name, city, ratings, the canonical public URL, and rentable=true / false per studio. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | Maximum results to return. | |
| query | No | ||
| rentable | No | When true, only return studios with at least one Location where rentalEnabled = true. Matches the public /studios?rentable=1 directory filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and clearly states that the operation is read-only. It also explains the rentable filter behavior and lists the return fields, though it does not mention pagination, ordering, or any permission requirements.
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 front-loaded with purpose and filter guidance, then return values, and closes with the read-only note. Most sentences are useful, though the Stripe Connect parenthetical adds contextual detail that is not strictly needed for invoking the tool.
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 four-parameter search tool with no output schema or annotations, the description is fairly complete: it covers purpose, search modes, the rentable filter, return fields, and read-only status. It still lacks details on pagination, result ordering, and query/city interaction.
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 only 50%, so the description must compensate for undocumented city and query parameters. It indicates that query is free-text and city is a city filter, but does not clarify matching behavior, case sensitivity, or how the two parameters interact. Its description of rentable largely repeats the schema-provided 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?
The description states a specific verb and resource: search studios and gyms by free-text query or city. It is easy to distinguish from siblings like search_classes and search_mentors because the entity is explicit, 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?
It explains the two search modes (free-text query or city) and when to pass rentable=true to restrict results. However, it gives no explicit when-not guidance, no mention of alternative tools, and no guidance on whether query and city should be combined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the cross-host public video directory (the /videos page): published class recordings and courses from every mentor and studio. Optional query filters by title (case-insensitive). Returns title, host, durationSec, priceCents (0 = free), currency, hasPreview (a free watchable snippet on the page), series (the collection title when the video is part of a multi-part course, else null), and the public page path. Buying or claiming happens on /videos/{id} and requires a free MoveMentors account: the video saves to the buyer's library (/videos/mine), plays on any device they sign in on, and resumes where they left off. Mentors can include videos with their recurring membership, so subscribers watch those at no extra cost. Use when a client asks 'what videos can I watch or buy?' without naming a specific teacher.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and provides useful behavior: the directory is public, `query` is case-insensitive, and it lists the returned fields including price and preview semantics. It also explains the account/library/purchase context, though it does not describe pagination or how `limit` affects results.
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 front-loaded with purpose, query behavior, and return fields, and it remains readable throughout. Some purchase/library/playback detail goes beyond what is needed to select or invoke a search tool, but the structure is coherent and not repetitive.
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?
Since there is no output schema, including the returned fields is essential and done well, along with query semantics and purchase context. The main gap is that `limit` and pagination behavior are not explained, which matters for an agent trying to control result size.
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 explain both parameters. It explains `query` well as an optional case-insensitive title filter, but it never mentions `limit` or its effect, leaving half the parameter surface undocumented.
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 action and resource: browsing the cross-host public video directory of published class recordings and courses from every mentor and studio. It also scopes the tool against mentor- or host-specific alternatives by saying to use it when the client does not name a specific teacher.
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?
It gives a clear use case: when a client asks 'what videos can I watch or buy?' without naming a specific teacher. It also clarifies that buying or claiming happens elsewhere, on /videos/{id}, but it does not explicitly name sibling tools or give further exclusions.
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.
book_class_as_guestget_class_payment_methodsget_mentorlist_host_videoslist_mentor_class_packslist_private_session_slotslist_reviews_for_classsearch_classessearch_help_articlessearch_mentorssearch_studiossearch_videosFind wellbeing sessions with independent practitioners: free times, prices and booking links.
Find and book local services, classes and rentals; businesses set up and manage their pages.
Yoga, pilates, barre, aerial, hoop and pole studios by city.
Find and book UK private physiotherapy, osteopathy and chiropractic clinics, with live availability.
Add one secure layer between your agents and this server.
