Read Fitssey schedules, class capacity, stock, pass pricing, sales and attendance reports.
Scored across 15 tools
Most tools have clearly distinct purposes: reports, catalog reads, and schedule reads are mostly separable. Minor confusion is possible between get_schedule and get_schedule_event, and between list_classes and list_courses, but the descriptions provide enough distinction.
All tool names use a consistent fitssey_ prefix followed by a clear get_ or list_ verb and a snake_case noun. The single-record vs page-list distinction is also reflected predictably in naming.
Fifteen tools is well within a reasonable range for a read-oriented fitness studio API surface. The set covers reports, catalogs, schedules, locations, staff, and products without excessive duplication.
The surface is entirely read-only and omits core lifecycle operations such as creating or updating bookings, clients, contracts, products, and staff. There are also dead ends: reports expose client IDs but no client lookup, and several listed resources have no corresponding get-by-ID tool.
Read one page of active client passes with client IDs and validity; cached by Fitssey for five minutes. Interpret remain with sessionType: limitedVisits counts visits, limitedTime counts minutes, and -1 means no session limit. Excludes names and emails. This page is not a full membership total.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description adds genuinely new behavior: a five-minute server-side cache, exclusion of names and emails, and per-field interpretation rules for 'remain' including the -1 sentinel. This is substantive disclosure beyond annotations, though cache staleness handling and pagination end conditions are not spelled out.
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 core action and no filler; the payload/semantics caveats follow logically. It is dense but each clause carries information, with only mild run-on density in the sessionType clause.
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 heavy lifting by naming the returned fields (client IDs, validity, remain/sessionType) and warning that results are partial. It stops short of describing page metadata or ordering, which an agent consuming the output would want.
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 'page' and 'count' are documented nowhere except their JSON types and bounds. The phrase 'one page of' hints at pagination but gives no guidance on page sizing, defaults or the 100-item ceiling, so the description only partially compensates 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?
States a specific verb ('Read one page of') plus resource ('active client passes') and scope (client IDs and validity), which cleanly separates it from siblings like fitssey_get_client_visits_report and fitssey_get_sales_report.
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 by 'active client passes' and the explicit caveat that 'This page is not a full membership total', which tells the agent to paginate rather than treat results as complete. However, it never names an alternative tool or states prerequisites for when this report is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of class visits for at most 31 days, with client IDs, pass and payment status. Excludes names, emails and private notes. This page is not a complete attendance total.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| endDate | Yes | ||
| startDate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety bar is low. The description adds real value beyond them: a hard 31-day window, the exclusion of names/emails/private notes (useful for knowing what the payload cannot answer), and the critical caveat that a single page is not a complete attendance total.
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, each earning its place: scope and fields first, then data exclusions, then the interpretation caveat. Nothing is repeated from the title and there is 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?
With no output schema, the description does the work of listing returned fields and explicitly listing what is excluded, plus the pagination caveat. Remaining gap is the lack of any signal about how to detect further pages or what the response envelope looks like.
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%, so the description must carry parameter meaning. It covers the date window ('at most 31 days') and implies pagination ('one page'), but never explains page/count semantics, defaults, maximums, or the YYYY-MM-DD date format that the schema only enforces via regex.
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 ('Read one page of class visits'), the 31-day window constraint, and the fields returned (client IDs, pass and payment status). The resource is naturally distinct from the sibling reports (sales, active passes), but no sibling is named to explicitly route the agent.
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 through the 31-day cap and the warning that a page 'is not a complete attendance total', which steers the agent toward paging rather than aggregating. However, there is no explicit statement of when to choose this over fitssey_get_sales_report or fitssey_get_active_passes_report, and no guidance on iterating pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one contract’s ID, name and online-sale flag; no payment or bank details.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the description's job is scoping data. 'No payment or bank details' is a genuinely useful disclosure of what is excluded from the payload. It stops short of saying what happens when the contract doesn't exist or isn't accessible.
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 clause with the resource and returned fields front-loaded, and a trailing scope limit. Nothing extraneous.
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, naming the three fields returned plus the excluded sensitive data is exactly the right compensation. The remaining gap is the undocumented required parameter and no failure 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 single parameter 'contract' has zero schema description coverage and the description never mentions it. The UUID pattern implies an identifier but the description gives no guidance that it must be a contract UUID or where to obtain one.
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 ('Read one contract') plus the exact fields returned, which clearly separates it from the plural sibling fitssey_list_contracts. It doesn't explicitly name the sibling, but 'one contract' vs a list tool is unambiguous.
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 singular scope implies 'use this when you need a single contract, not a listing,' but no alternative is named and no prerequisite is stated. An agent must infer that it needs an existing contract ID from list_contracts first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one pass offering and its session, expiry and price settings. Excludes private notes.
| Name | Required | Description | Default |
|---|---|---|---|
| pricingOption | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds useful behavioral scope by saying it returns session, expiry and price settings and explicitly excludes private notes.
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 two short sentences, front-loaded with the core read operation and followed by a useful exclusion. There is no redundant or wasted language.
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 should carry more weight in explaining return details. It gives partial return scope and an exclusion, but omits the meaning of the required parameter and does not describe the response shape.
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 the description never explains that pricingOption is a UUID or identifier for the pass offering. The parameter name and pattern provide some clues, but the description does not compensate for the missing schema documentation.
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: read one pass offering, including its session, expiry and price settings. The word 'one' implicitly distinguishes it from list_pricing_options, though it does not explicitly name the sibling.
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 says what the tool reads but gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives like fitssey_list_pricing_options. Usage is only implied by 'Read one pass offering.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one product’s stock, SKU and price. Excludes private notes.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description's one real addition is 'Excludes private notes', a useful scope disclosure, but it says nothing about lookup failure behavior, auth requirements, or response shape beyond the three named fields.
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 with no padding, and the primary action is front-loaded. The brevity is efficient, though it borders on under-specification rather than pure economy.
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 rich annotations and no output schema, the description covers purpose and the notable exclusion. It still omits the identifier type the agent must supply and any indication of what happens for a missing or unauthorized product, which matters given 0% schema coverage.
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 the sole 'product' parameter has no descriptive text in the schema. The description could have said it expects a product UUID (the schema's pattern) but instead says nothing about the argument, leaving the agent to infer format from the raw regex.
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 cardinality ('Read one product') plus the fields returned (stock, SKU, price), which implicitly separates it from fitssey_list_products. It never names a sibling explicitly, so 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?
The word 'one' implies this is the single-record counterpart to fitssey_list_products, but the description gives no explicit when-to-use rule, no prerequisite for obtaining a product identifier, and no statement about behavior when the product does not exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of sales for at most 31 days, preserving vendor monetary numbers. Excludes customer names, emails, addresses and invoice tax identifiers. This page is not total revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| endDate | Yes | ||
| startDate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds genuinely new context: the 31-day limit, the deliberate exclusion of PII fields (customer names, emails, addresses, tax IDs), and the warning that a page is not total revenue. What's missing is pagination behavior (how to know when pages are exhausted).
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 tight sentences, each carrying distinct information (scope, exclusions, revenue caveat), with the hardening constraints front-loaded. 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?
Covers data scope, privacy exclusions, and the partial-result caveat, which is decent for a read-only report. But with no output schema and zero parameter documentation, the definition leaves pagination and parameter usage underspecified for a 4-parameter paged endpoint.
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 4 parameters, so the description must compensate and largely doesn't. It never explains the meaning of 'page' vs 'count', how paging interacts with the date range, or the date format, leaving the agent to infer from the raw 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 ('Read one page of sales') plus the key scope constraint (at most 31 days). It is distinguishable from the other report siblings by resource, though it doesn't explicitly name which sibling to use for a different report.
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 31-day cap and 'one page' framing imply usage but there is no explicit when-to-use guidance, no mention of how to get totals vs pages, and no alternative named among the many report/list siblings. The agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read scheduled classes and remaining capacities for a date range of at most 31 days. No bookings are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | ||
| startDate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is largely covered. The description reinforces this with 'No bookings are changed' and adds the date-range constraint, but it does not disclose pagination, timezone handling, or freshness of remaining capacities.
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 two concise sentences with no wasted wording. The core operation is front-loaded, followed immediately by the key date-range limitation and safety reassurance.
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 two-parameter read tool with annotations covering safety, the description is largely complete: it names the returned data and the 31-day limit. It could be stronger by clarifying date-range boundaries or timezone, but no critical calling information 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 description coverage is 0%, so the description must compensate. It adds an important constraint beyond the schema: the date range must be at most 31 days. However, it does not clarify per-parameter semantics such as inclusive boundaries, timezone, or date interpretation.
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: read scheduled classes and remaining capacities. It also scopes the operation to a date range, but it does not explicitly distinguish itself from siblings such as fitssey_list_classes or fitssey_get_schedule_event.
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 states the 31-day maximum date range, which is a useful constraint, but it gives no guidance on when to use this tool instead of alternatives like fitssey_list_classes or fitssey_get_schedule_event. The agent must infer the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one scheduled event, capacities and assigned teachers. Excludes livestream URLs, passwords and private notes.
| Name | Required | Description | Default |
|---|---|---|---|
| scheduleEvent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered; the description adds genuine value by disclosing data redaction — no livestream URLs, passwords or private notes are returned. That matters for an agent deciding whether this call is sufficient for a given question. It does not mention error behavior for a missing/invalid event key.
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, zero filler, and the scope statement ('Read one scheduled event') is front-loaded before the return/exclusion detail. Nothing is redundant with the title or annotations.
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-record read with rich annotations and no output schema, the description covers purpose and the notable exclusions in the returned data. The only real gap is what form the 'scheduleEvent' argument takes, which is left entirely to the schema.
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 single required parameter 'scheduleEvent' carries only a regex pattern and length bounds with no explanation. The description never states that the parameter is the event identifier (ID vs. slug vs. name), so the agent must guess the expected input format.
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 ('Read') and resource ('one scheduled event') plus the payload contents (capacities, assigned teachers), which distinguishes a single-record fetch from the list-style siblings like fitssey_get_schedule and fitssey_list_classes. It does not explicitly name a sibling to disambiguate against, 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?
The word 'one' implies this is the per-record lookup used when a single event identifier is already known, but there is no explicit when-to-use vs. fitssey_get_schedule, and no stated preconditions. Usage is inferable rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of the class catalog and categories. Excludes descriptions and private notes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: results are paginated ('one page') and certain fields are omitted ('Excludes descriptions and private notes'), which helps the agent interpret the return payload. It still omits pagination defaults and response shape details.
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 with zero waste, and the core action is front-loaded before the field-exclusion caveat. 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?
The tool has four undocumented parameters and no output schema, so the description should explain more about pagination defaults and the shape of returned catalog entries. It does note that descriptions and private notes are excluded, which is useful, but the overall picture is only minimally sufficient for correct invocation.
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 all four parameters, so the description carries the full burden of explaining them. It only hints at pagination via 'one page' and says nothing about page, count, sortDir, or the fixed sortField='createdAt', leaving the parameters effectively 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?
States a specific verb ('Read one page') and resource ('class catalog and categories'), which clearly distinguishes it from the get_* siblings that return single entities. However, it does not differentiate itself from the sibling fitssey_list_courses, leaving an ambiguity about classes vs. courses that an agent must resolve elsewhere.
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?
'Read one page' implies paginated browsing of the catalog, which is adequate implied usage. But there is no explicit guidance on when to use this versus list_courses or the schedule tools, and no exclusions or prerequisites are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contract catalog IDs, names and online-sale flags. Excludes private notes and payment details.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description does add real value by naming the returned field subset and explicitly excluding private notes and payment details. It says nothing about pagination behavior or result size limits, which matter given page/count parameters.
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 tight sentences with the returned-field summary front-loaded and the exclusion clause second. No filler or restatement of the title.
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 paginated list tool with no output schema, the agent still lacks any guidance on paging, page size, or sort behavior, and there is no note on what to do when the result set is large. The returned-field and exclusion notes partially compensate.
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% for four parameters (page, count, sortDir, sortField), and the description mentions none of them. With no documentation anywhere for pagination or sorting, the description fails to compensate for the low coverage.
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 ("Read contract catalog") and enumerates the returned fields, so an agent knows this lists contracts rather than fetching one. It does not explicitly contrast with the sibling fitssey_get_contract, so the list-vs-single distinction rests on the name 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?
Listing semantics imply 'use when you need to enumerate contracts', but nothing states when to prefer this over fitssey_get_contract or fitssey_get_pricing_option. No prerequisites or exclusions are given beyond the data-scope note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read online-bookable courses and their scheduled sessions for a date range of at most 31 days.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | ||
| startDate | Yes |
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. The description adds a genuine behavioral constraint beyond the annotations: the date range is capped at 31 days, which affects how an agent must chunk requests. It does not describe return volume or pagination.
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 with no waste, front-loading the read action and the resource before the range constraint.
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's 'courses and their scheduled sessions' is the only signal about return content, and it omits pagination, ordering and whether courses without sessions appear. The 31-day cap is disclosed, but the picture is only adequate for a 2-parameter list tool.
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?
With 0% schema description coverage, the description must carry the load. It does clarify the two date parameters as a bounded range (max 31 days), but leaves open whether the bounds are inclusive, what timezone applies, and the required date format (only the schema pattern conveys that). Partial compensation.
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 ('Read') and a scoped resource ('online-bookable courses and their scheduled sessions'), which is meaningfully narrower than the sibling fitssey_list_classes or fitssey_get_schedule. It does not explicitly name those siblings, so the differentiation is implicit 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?
The 'online-bookable' qualifier implies when this list applies versus a general class list, but there is no explicit when-to-use/when-not guidance and no mention of the sibling tools an agent should consider instead. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read studio locations, business addresses and rooms. Excludes entrance instructions and phone details.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value by bounding the returned content (addresses and rooms included; entrance instructions and phone details excluded). It says nothing about pagination behavior, ordering, or result volume despite exposing page/count/sort parameters.
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 with zero filler, and the content scope is front-loaded ahead of the exclusion note. Nothing could be cut without losing information.
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's field-scope statement is valuable, and annotations cover the safety profile. However, for a paginated list tool with four undocumented parameters, the definition omits how results are paged and ordered, which is the main gap an agent needs closed before calling.
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 four parameters, so the description carries the full burden and does not meet it. It never mentions paging, result count, or that sorting is fixed to createdAt with asc/desc direction, leaving the agent to infer the traversal model from bare property names.
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 set: reading studio locations, business addresses and rooms. The scope is clear enough to separate it from every sibling, which all handle other resources (products, contracts, staff). It stops short of any explicit sibling contrast, but the resource noun does the disambiguating work.
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 verb 'Read' and reinforced by the exclusion note, which hints that entrance instructions and phone details must come from a different call. There is no explicit statement of when to use this versus a get_* sibling, and no guidance on paging through results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read pass catalog, session allowance and prices in the vendor’s smallest currency unit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered without the description. The description adds only the useful note that prices are in the vendor's smallest currency unit; it says nothing about pagination behavior or total counts, which the annotations don't cover.
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 compact sentence with no filler, front-loading what is returned. It is efficient, though slightly terse given how much it leaves unexplained.
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 and zero parameter documentation, the description should carry more: it does not explain paging, max page size of 100, sort constraints, or the return shape beyond naming the business fields. For a four-parameter list endpoint this leaves real gaps.
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 four parameters (page, count, sortDir, sortField), and the description compensates for none of them — no mention of paging, page size limits, or that sorting is restricted to createdAt. Parameter names and defaults carry the entire burden here.
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 the resource concretely — pass catalog, session allowance, prices — and specifies the currency-unit convention, which tells an agent the shape of the data. It does not explicitly distinguish itself from the sibling fitssey_get_pricing_option, so the list-vs-single distinction is only implied by the tool name.
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?
There is no guidance on when to use this rather than fitssey_get_pricing_option or the contract/product tools, and no mention of prerequisites or result-set expectations. The agent must infer usage entirely from the tool name and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of products with SKU, stock and prices in the vendor’s smallest currency unit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds genuine value by disclosing the returned fields and that prices are in the vendor's smallest currency unit, which prevents a common misinterpretation. It doesn't say how to detect the last page or whether a total count is returned.
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 the resource and scope front-loaded and no filler. Every clause carries information.
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 paged list with no output schema, the description covers what is returned and the currency unit convention, which is the main thing an agent could get wrong. The remaining gap is pagination and sorting semantics, which are discoverable from the schema's defaults and enums.
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% for four parameters, so the description must compensate and largely doesn't. 'One page' weakly implies page/count, but sortField and sortDir (including the fixed createdAt constraint and asc/desc enum) are never mentioned anywhere and must be inferred from the raw 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 scope ('Read one page of products') plus the fields returned (SKU, stock, prices). This differentiates it implicitly from the singular fitssey_get_product and from fitssey_list_pricing_options, though no sibling is named 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?
There is no statement of when to use this versus fitssey_get_product for a single item, and no guidance on iteration when more pages are needed. The only usage signal is the phrase 'one page', which hints at pagination without explaining it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of studio staff IDs and names; optionally filter by role. Excludes contact and profile details.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| iamRole | No | ||
| sortDir | No | asc | |
| sortField | No | createdAt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: results are a single page (pagination semantics) and contact/profile fields are deliberately omitted, which stops an agent from expecting complete records.
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 the scope and the exclusion front-loaded; no filler and nothing repeated from the title.
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 usefully states what comes back (staff IDs and names) and what does not, which is the main risk here. It is slightly incomplete on pagination mechanics (how to know more pages exist) and default sort/count behavior for a 5-parameter list tool.
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 carries the burden of explaining five parameters. It clarifies paging ('one page') and the role filter, but says nothing about 'count', 'sortDir', or 'sortField' (whose only allowed value is createdAt), leaving sort behavior undocumented in both places.
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 ('Read one page of studio staff IDs and names') plus the shape of the return (IDs and names), and even names an explicit exclusion ('Excludes contact and profile details'). No sibling tool operates on staff, so sibling differentiation is inherent to the resource; the only gap is that it doesn't flag the relationship to report/get siblings for detail lookups.
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?
'optionally filter by role' implies the main use case, and the exclusion of contact/profile details hints at when to look elsewhere, but there is no explicit when-to-use guidance, no mention of alternatives for full staff details, and no guidance on paging through the full roster.
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.
fitssey_get_active_passes_reportfitssey_get_client_visits_reportfitssey_get_contractfitssey_get_pricing_optionfitssey_get_productfitssey_get_sales_reportfitssey_get_schedulefitssey_get_schedule_eventfitssey_list_classesfitssey_list_contractsfitssey_list_coursesfitssey_list_locationsfitssey_list_pricing_optionsfitssey_list_productsfitssey_list_staffRead Mindbody classes, schedules, clients, staff and sales; book clients and appointments.
Read-only studio reports from FullClass: upcoming classes, fill rates, bookings and revenue.
Read club members, court availability, reservations, events, attendance and revenue reports.
Check classes, attendance, customers, memberships and invoices in TeamUp and register customers.
Add one secure layer between your agents and this server.