Mindbody MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.2
Disambiguation3/5
Many tools have clearly distinct resources, but the scheduling and purchasing domains contain overlapping tools (e.g., getServices, getPackages, getContracts; getBookableItems, getActiveSessionTimes, getScheduleItems). Additionally, getClassVisits and getClientVisits are similar in scope, creating potential confusion.
Naming Consistency4/5
Tool names consistently follow a verb_noun pattern (get, add, update, remove, substitute, checkout, purchase) and use camelCase throughout. Minor deviations exist in verb choice for similar actions (e.g., addClientToClass vs. addClient), but the overall structure is predictable and readable.
Tool Count2/5
With 39 tools, the server exceeds the 25+ threshold considered excessive, creating a large and potentially overwhelming surface for agents. Even though Mindbody is a broad domain, the number of tools could be consolidated or split into different servers.
Completeness3/5
The tool set covers many core workflows: client management, class scheduling, appointments, enrollments, and sales. However, obvious lifecycle gaps exist, such as no delete operations for clients or appointments, no class creation/update, and no cancellation for appointments, which can lead to dead ends.
Average 3/5 across 39 of 39 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on September 10, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It fails to mention that this is a read-only operation, how filters like date ranges or staff/location IDs affect results, or what the response contains. The wording 'schedule items/availability' is too generic to convey meaningful behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no redundant text. However, it is under-specified to the point of marginal utility: it essentially restates the tool name plus a vague synonym. It is concise but does not earn its place by adding meaningful information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema, and the description provides no context on what the returned data looks like, whether the parameters are filters, or how to interpret the results. This is inadequate for an agent to invoke the tool effectively, especially given the large set of similar schedule-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema parameters have terse descriptions (e.g., 'End date', 'Staff IDs'), but the tool description adds no extra context about how these parameters interact or what forms they take. The description does not compensate for the schema's lack of detail, but it also does not contradict it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get schedule items/availability' identifies the resource as schedule items/availability, which is clearer than a tautology but still vague. It doesn't specify the exact nature of the items or distinguish from similar siblings like getClassSchedules or getBookableItems, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of the many related sibling tools. There is no mention of alternative tools, prerequisites, or typical use cases, leaving the agent to guess at the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the mutation action ('update') without mentioning side effects, required permissions, reversibility, or implications for related data. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is severely under-specified for a tool with 9 parameters. It essentially restates the tool name and does not provide any structural breakdown or key highlights.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no output schema, no annotations), a one-line description is completely inadequate. It does not explain return values, how parameters interact, or any behavioral context needed to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 9 parameters, so the baseline is 3. The tool description adds no additional meaning beyond the schema, but the schema already documents parameter names and brief descriptions, which is sufficient for basic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('update') and resource ('appointment'), and implies a distinction from the sibling addAppointment. However, it lacks any detail about which fields or aspects of the appointment can be updated, so it does not fully distinguish from other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives like addAppointment or getStaffAppointments. There are no prerequisites, exclusions, or scenario descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Update client information' and does not disclose whether updates are partial or full, whether validation occurs, what happens to unspecified fields, or any side effects. The verb implies mutation but adds no behavioral detail beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise and front-loaded. But it is so minimal that it borders on under-specification rather than efficient communication; no structure or extra context is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complex nested updates object, no annotations, and no output schema, the description is insufficient. It lacks information about response behavior, error conditions, and the nature of updates (merge vs. replace). An agent would have to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers clientId with a description but the nested 'updates' object lacks description. The tool description adds no parameter semantics; it doesn't explain that 'updates' is a partial update payload or list the editable fields. The property names are self-evident, but the description does not compensate for the 50% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('client information'), clearly distinguishing it from addClient (create) and getClients (read). However, it lacks specificity about which client fields are updatable or that it targets existing clients only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like addClient or updateAppointment. There is no mention of prerequisites, context, or exclusions. The usage is only implied by the verb 'Update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention potential side effects (e.g., sending emails, processing payments), permission requirements, or reversibility. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and contains no filler, but it is under-specified for a tool with 11 parameters and 5 required fields. The single sentence is not appropriately sized; it omits valuable context that should be present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex booking operation with no annotations, no output schema, and a high parameter count. The description fails to explain return values, side effects, or dependency on related entities (staff, client, location), leaving the agent without enough information to use the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 11 parameters (100% coverage), so the schema already explains the meaning of each field. The tool description adds nothing beyond what the schema offers, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (booking) and the resource (appointment), which makes its primary purpose unambiguous. However, it does not explicitly differentiate from sibling tools like updateAppointment or addClientToClass, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as updateAppointment or addClientToClass. It simply states the action without any context about prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only states 'Process a shopping cart checkout' without revealing side effects like payment charging, inventory changes, receipt generation, or error conditions. This is a significant gap for a mutation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. No wasted words, but the brevity borders on under-specification. Still, for what it says, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex transactional tool with 7 parameters and no output schema, the description is incomplete. It does not explain the workflow, expected result, or any important context like whether it creates an order or handles partial payments. The lack of an output schema increases the burden on the description, which it fails to meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description itself adds no parameter-specific meaning beyond the schema, but the schema already explains each field (e.g., 'items' as 'Cart items', 'payments' as 'Payment methods'), so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Process a shopping cart checkout' clearly identifies the action (process) and the resource (shopping cart checkout), distinguishing it from sibling tools which are mostly read or add/update operations. It lacks a bit of specificity about what 'checkout' entails, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as purchaseContract or addClientArrival. There is no mention of prerequisites or context where this tool is preferred over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Get programs' with no mention of read-only semantics, return format, pagination, or any side effects. The description adds no behavioral context beyond the word 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. There is no wasted wording, but it is also extremely terse and could arguably provide a bit more useful structure without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what a 'program' is and what the response contains. It does not. Also, the meaning of the scheduleType parameter and its expected values are left entirely unexplained, making the tool under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (onlineOnly has a description, scheduleType only has an enum). The description does not mention either parameter or their meaning, so it fails to compensate for the schema's gaps. For example, it does not explain how scheduleType affects the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Get programs') with illustrative examples (yoga, pilates), making its purpose reasonably clear. However, it does not explicitly distinguish itself from sibling tools like getClasses or getServices, which could overlap with 'programs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose, not what the tool returns, whether it is read-only, how it filters, or any side effects. The absence of any behavioral context beyond the name is a significant gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Get staff appointments'), which is concise but at the cost of valuable information. It essentially restates the tool name and does not use the available space to add context. This is under-specification rather than efficient conciseness, similar to the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is far too minimal. It does not explain return values, the effect of combining filters, or the default behavior when optional parameters are omitted. The description is not adequate to guide an agent in using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully describes all six parameters, including the required staffIds and the optional filters. The description adds no additional meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get staff appointments' clearly states the action (get) and the resource (staff appointments), which is specific enough to understand the tool's core function. However, it does not differentiate from sibling tools like getScheduleItems or getTeacherSchedule, which might also return appointment-like data. It is not vague, but it lacks specificity about the detailed scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The description does not mention prerequisites, contexts, or exclusions. The schema implies that staffIds is required, but the description provides no rationale for choosing this tool over similar appointment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get active session availability times' without explaining filtering semantics, output format, pagination, or any side effects. This is a significant gap for a tool that queries time availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise in size, but it is under-specified and fails to provide meaningful information beyond the tool name. It is not wastefully verbose, but it does not earn its place by adding substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema, the tool requires more descriptive context to be usable. The one-sentence description does not explain how the parameters interact (e.g., whether days and times are filters or inputs), and the large sibling list makes the lack of guidance even more problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 out of 5 parameters have descriptions). The description itself adds no parameter semantics beyond the schema, and the undocumented `scheduleType` parameter relies solely on its enum values. This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'active session availability times', which is specific enough to indicate the tool's basic function. However, it does not distinguish this from sibling tools like getScheduleItems or getClassSchedules, so it loses some points for lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like getScheduleItems, getBookableItems, and getClassSchedules, the lack of any contextual usage instructions makes it difficult for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'Get', but it does not describe any behavioral traits such as how availability is determined, whether results are paginated, or any authentication requirements. The description is minimal and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, for a tool with six parameters and no output schema, the brevity comes at the expense of essential information, making it under-specified. It is not verbose, but it is not adequately informative either.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is incomplete. It fails to explain how parameters like startDate/endDate, staffIds, locationIds, and appointmentId affect the results, what the return value looks like, or any limitations. This leaves the agent with insufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter given a basic label (e.g., 'Start date', 'Staff IDs'). The tool description adds no additional meaning beyond 'available appointment slots', which implicitly connects the parameters to filtering availability but does not explain parameter interplay or formatting. This meets the baseline for high schema coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'available appointment slots', which accurately conveys the tool's purpose of retrieving bookable slots. However, it does not differentiate from sibling tools like getActiveSessionTimes or getScheduleItems, which also retrieve time-related information, so it is clear but not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or mention sibling tools, leaving the agent without context for tool selection in a list of many appointment/schedule-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Search and retrieve' implies a read-only operation, but it does not state pagination, response format, whether filters are combinable, or any side effects. There is no mention of permissions, rate limits, or data scope, leaving the agent uncertain about the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, containing only 'Search and retrieve clients.' While this is concise, it is under-specified and borderlines on being a phrase rather than a complete sentence. It gets the core idea across but lacks details that would make it genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain what the tool returns (e.g., a list of client objects, fields, pagination). It also does not clarify relationships between parameters (e.g., whether clientIds and searchText are combined or mutually exclusive). With four optional parameters and no output schema, this description is inadequate for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (clientIds, isProspect, searchText, lastModifiedDate) already have meaningful descriptions in the schema. The tool description adds no parameter-specific meaning, but the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search and retrieve clients' uses a clear verb ('search and retrieve') and a specific resource ('clients'), which distinguishes it from sibling tools like getClientMemberships or getClientVisits. However, it does not specify whether it returns a list, a single client, or supports both by ID and search, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that to fetch memberships, visits, or account balances one should use sibling tools, nor does it state scenarios where clientIds vs searchText would be preferred. The description is purely functional with no contextual selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Get', which implicitly suggests read-only, but it does not mention filtering capabilities, response format, or any side effects. This is insufficient for a tool with five parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but it is arguably under-specified for a tool with five parameters and no output schema. It is not verbose, but it could provide more useful detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's five optional parameters and absence of an output schema, the description is incomplete. It does not convey the tool's filtering capabilities or what the response contains, leaving the agent with insufficient information to anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all five parameters, so the description does not need to explain them. However, the description adds no extra meaning about parameter interactions or common usage, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('retail products'), which distinguishes it from sibling tools like getServices or getClasses. It notably adds 'retail' to provide product-type context, but does not specify whether it returns a list or a single item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about intended use cases, prerequisites, or why an agent should choose this over related getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Book' implies a mutation, but it does not explain side effects like payment processing, waitlist handling, capacity checks, or whether the booking can be undone. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with minimal words: 'Book a client into a class'. Every word contributes to the core purpose, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich schema parameter descriptions, the tool overall is under-documented: no output schema, no annotations, and the description omits behavioral expectations such as payment semantics, waitlist behavior, and success/failure responses. For a booking tool with four parameters, this level of context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions, including waitlist and requirePayment, so schema coverage is 100%. The description adds no further parameter meaning beyond what the schema already provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Book' and names the resource 'a client into a class', clearly stating the tool's core function. It distinguishes from siblings like removeClientFromClass by implying a create/booking action, but it does not explicitly name alternatives or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as addClientToEnrollment or addClientArrival. It lacks context about prerequisites (e.g., client must exist, class must be open) and gives no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects like sending confirmation emails, waitlisting, or modifying enrollment dates, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence with no wasted words, making it concise and front-loaded. However, it may be too terse for a tool with 8 parameters, but that is a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 2 required, no output schema, and no annotations, the description is incomplete. It fails to explain key behaviors such as waitlist handling, email notifications, or enrollment dates, which are essential for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are already documented in the schema. The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Register' and identifies the resource as 'client for course/workshop', clearly indicating the action. However, it does not differentiate from sibling tools like addClientToClass, which is a similar operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as addClientToClass or removeClientFromClass. The description provides no context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose and gives no details about side effects, read-only nature, authentication requirements, or return value. 'Get' implies read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and to the point, which is concise, but it is a fragment rather than a complete sentence. It lacks any additional structure or context. It is not under-specified to the point of being a tautology, but it is minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameters, the description is the only source of context. It is too sparse to fully understand what the activation code is, how it is used, or what the tool returns. For a simple tool this might be sufficient, but with no additional context the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it is consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('site activation code'), which is specific and understandable. It does not need to distinguish from siblings since no other tool relates to activation codes, but it could be more explicit about what an activation code is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions. The intended usage must be inferred from the name and description, which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not reveal any constraints such as pagination, whether date filters are required, or how 'all' is defined. The lack of behavioral detail could mislead the agent into assuming unrestricted access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for a tool whose parameters are fully documented in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters, no output schema, and no annotations, the description is under-specified. It does not explain whether filters are combinable, whether a date range is required to avoid large result sets, or what fields are returned per class. This leaves significant gaps for an agent deciding how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described. The description only says 'filtering options', which adds no additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource 'classes', making the core purpose clear. However, the phrase 'with filtering options' is vague and does not distinguish this tool from siblings like getClassSchedules or getClassVisits, which also retrieve class-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any alternatives, exclusions, or contextual prerequisites, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It merely says 'Get' with no disclosure of response format, behavior when no filters are provided, or read-only guarantees. This is minimal behavioral transparency for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero fluff. It is appropriately concise, although it may be too terse to serve as a standalone guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the seven-word description is insufficient for an agent to understand return values, filter semantics, or when this tool is the best choice among many sibling schedule-related tools. The parenthetical adds some clarity but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all four parameters (staffIds, programIds, locationIds, classDescriptionIds) with explicit descriptions, so the description adds no additional meaning. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get class schedules' with a clarifying parenthetical '(recurring class templates)' that distinguishes it from sibling tools like getClasses (actual class instances) and getClassDescriptions. It names a specific resource and verb, though it doesn't explicitly reference alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related siblings such as getClasses or getScheduleItems. There is no mention of filter combinations or whether all options are optional, leaving the agent to infer usage solely from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure, but it only states 'Get client's enrollments' without clarifying whether the enrollments are active, historical, sorted, or how the response is structured. This minimal wording does not add meaningful behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short phrase with no wasted words, making it easy to parse. However, it is so terse that it verges on under-specification, though it remains appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is minimally adequate but leaves questions unanswered, such as whether enrollments are filtered by status or date. The existence of getEnrollments as a sibling also adds ambiguity that the description does not address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the only parameter (clientId) with 'Client ID', and the description adds no additional meaning about the parameter's format or usage. With 100% schema coverage, this meets the baseline for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('client's enrollments'), making the tool's function understandable. However, it does not explicitly differentiate this from the sibling tool getEnrollments, which could cause confusion about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like getEnrollments or getClientMemberships. It also fails to mention prerequisites, such as the need for a valid clientId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states 'active memberships,' implying a filter, but does not explain any other behavioral traits such as authentication requirements, pagination, data freshness, or what happens when no memberships exist. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and to the point, but its brevity leaves out important context that would improve usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations or output schema, the description is incomplete. It doesn't mention what the response contains, how it's sorted, or how it relates to other client endpoints. The description is adequate for a simple read but lacks enough context for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with basic descriptions, so the baseline is 3. The tool description adds no additional meaning beyond the schema; it doesn't explain how the parameters affect the result or how locationId filters memberships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'client's active memberships.' It clearly indicates the tool returns a client's memberships, but it does not explicitly distinguish it from sibling tools like getClientContracts or getClientAccountBalances, so it doesn't quite earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as getClientContracts or getClientAccountBalances. There is no mention of prerequisites, typical use cases, or exclusions, so it scores low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the read-only intent via 'Get' but does not mention date range behavior, result limits, or any side effects. This is minimal for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb, zero waste. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters and no output schema, yet the description is one line and does not explain return values, date filtering behavior, or edge cases. This is inadequate for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, and the description adds no additional parameter semantics. Since schema coverage is 100%, baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'client's visit/attendance history', clearly indicating the tool retrieves a client's visit records. It is distinguishable from sibling tools like getClassVisits because it focuses on client-level attendance, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like getClassVisits or getClientMemberships. The description only states what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only restates the tool's function and adds no behavioral details (e.g., whether it returns active/inactive contracts, authorization needs, or filtering semantics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately sized, though slightly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a rich set of sibling tools, the description is too vague. It fails to clarify what 'available' means, what the return structure is, or how this relates to other contract-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'contracts/memberships', which is specific. However, it does not differentiate from sibling tools like getClientContracts, leaving ambiguity about what 'available' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as getClientContracts or purchaseContract. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Get enrollments' implies a read operation but does not mention filtering behavior, return format, pagination, authentication, or any side effects. The parenthetical adds domain context but not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with the verb and resource front-loaded. The parenthetical elaboration is purposeful, avoiding redundancy. There is no wasted text, making it appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 optional parameters, no annotations, and no output schema, the description is too sparse. It does not explain the response structure, the meaning of the filter parameters, or any constraints. This is insufficient for an agent to use the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond the schema, but the schema's parameter descriptions are minimal (e.g., 'Start date', 'Staff IDs') and do not explain how filters combine or interact. No additional value is provided, so the baseline stands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get enrollments' with a parenthetical scope ('courses, workshops, series'). This provides enough clarity to distinguish from generic list tools, though it does not explicitly differentiate from the sibling getClientEnrollments or explain the distinction between client-specific and overall enrollments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like getClientEnrollments, getClasses, and getScheduleItems, the description offers no usage context, exclusions, or prerequisites, leaving the agent to guess the appropriate selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get class packages', implying a read-only operation, but gives no details on permissions, pagination, return format, or side effects. This is minimal transparency beyond the verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single short phrase. There is no filler, but the brevity comes at the cost of conveying useful context, making it slightly under-specified rather than optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves the return values and behavioral details unspecified. It doesn't explain the relationship between locationId and classScheduleId or whether they are optional filters. For a tool with two optional parameters, this is insufficient context for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters (locationId and classScheduleId), so the description need not repeat them. However, the description adds no additional meaning about how these parameters interact with each other or whether they act as filters, which the schema already handles minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'class packages', making it clear this is a read operation for a class-related resource. It somewhat distinguishes from sibling tools like getServices or getProducts by specifying 'class packages', though it doesn't define what a package is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as getServices, getProducts, or getClassSchedules. There are no exclusions, prerequisites, or alternative recommendations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Get resources'. It implies a read-only operation but does not mention response format, pagination, required parameters, or limitations. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant content. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters, no output schema, and no annotations, the description is thin. It does not explain the return shape, the meaning of the date/time parameters, or how resources are filtered. The agent is left to infer too much, making this inadequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description itself does not add any parameter-specific semantics beyond the parenthetical clarification of what 'resources' means, which is already partially in the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'resources (rooms, equipment)', which is a specific verb+object. It distinguishes the resource type with a parenthetical, making the purpose unambiguous among siblings, though it doesn't explicitly contrast with alternatives like getBookableItems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as getBookableItems or getLocations. There are no exclusions or context hints for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get available services', which implies a read operation, but does not mention return format, pagination, filtering behavior, or any side effects. This is minimal transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get available services (class packages, memberships)'. It is front-loaded with the verb and resource, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema, but the description does not explain what the tool returns or how the parameters affect results. It also does not clarify the relationship to similar tools (e.g., getPackages) or the meaning of 'available'. The example parenthetical is helpful but insufficient for a tool in a large sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning for parameters; the list of example types ('class packages, memberships') is not tied to specific parameters. It does not compensate for or enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('available services'), with examples 'class packages, memberships' to clarify the domain. However, it does not differentiate this tool from sibling tools such as getPackages or getClientMemberships, so it misses the highest mark for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. For a tool with many sibling list/get tools, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavioral traits. It only states the read action 'Get' but does not disclose return format, filtering behavior (AND/OR), pagination, permissions, or whether it includes historical entries. No behavioral context is added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the key action and resource, making it easily parseable. Conciseness is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three optional filters, the description is under-specified. It fails to explain what a waitlist entry contains, how the filters combine, or whether results are paginated. Users have little context for anticipating the tool's behavior or constructing effective calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional meaning about how classIds, clientIds, or classScheduleIds interact, which is a missed opportunity to clarify filter semantics. However, the schema already provides basic parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving waitlist entries related to classes. It is specific enough to distinguish from sibling tools like getClasses or getClassSchedules, though it does not explicitly mention the filtering capabilities. The verb 'Get' and resource 'waitlist entries' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions among the many sibling tools. Users must infer from the name alone, which is insufficient for distinguishing from related get/list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It states 'purchase' but does not explain consequences such as payment processing, initiation of billing, whether the action is reversible, or whether it requires special permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It states the action and object efficiently, achieving the goal of conciseness despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 7 parameters, 3 required, no output schema, and no annotations. The description only says 'purchase a contract/membership', which does not explain return values, side effects, required permissions, or how this differs from other purchase-related tools. The schema covers parameter formats but does not address the tool's overall context, making the description inadequate for complex use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86% (6 of 7 parameters have descriptions). The description itself adds no parameter-level detail, but the schema already provides meaningful descriptions for clientId, startDate, contractId, locationId, promotionCode, and clientSignature. The only parameter without a description is firstPaymentOccurs, but its enum values are self-explanatory. With high schema coverage, this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Purchase a contract/membership' clearly identifies the action (purchase) and the resource (contract/membership). It distinguishes itself from sibling tools like getContracts or getClientContracts, which are read-only, and checkoutShoppingCart, which handles broader cart checkout. The use of 'contract/membership' is slightly ambiguous but the parameter 'contractId' clarifies the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., checkoutShoppingCart for purchases, addClientToClass for class enrollments). It does not mention prerequisites, required state (e.g., client must exist), or typical purchase scenarios. There is no 'when not to use' exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'mark arrival' without disclosing side effects, whether it's a write operation, permissions required, reversibility, or failure cases. It doesn't describe what happens in the system (e.g., arrival record created).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that immediately conveys the action. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the operation is simple and parameters are fully documented, the lack of annotations and output schema leaves gaps about side effects, return values, and usage context. It's minimally adequate but missing important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both clientId and locationId described. The description adds no parameter-specific detail, but the schema alone is sufficient, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Check in a client') and clarifies with 'mark arrival', which defines the action clearly. It is distinct from sibling tools like addClientToClass or addAppointment, though it doesn't explicitly call out those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. It doesn't mention that this is for physical arrival at a location, prerequisites like existing client/location records, or exclude uses like class check-in. The description merely states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read operation through the verb 'get' but provides no details on return format, error behavior, permissions, rate limits, or what 'contracts/memberships' actually includes. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource. It contains no fluff or redundancy, making it very easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description doesn't clarify whether contracts and memberships are returned as separate entities or combined, and there is no output schema to compensate. Given the lack of annotations, more context about the returned data would be expected, making this minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter 'clientId' with 100% coverage, and the description's phrase 'client's' aligns with that parameter. However, the description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate when the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (client's contracts/memberships), making the tool's purpose understandable. However, it doesn't differentiate from the sibling tool 'getClientMemberships', which likely has similar or overlapping functionality, so it falls 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'getClientMemberships' or 'getContracts'. The description offers no context on prerequisites, conditions, or exclusions, leaving the agent without enough information to choose correctly among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Get', implying read-only, but does not mention side effects, pagination, response format, or any other behavioral traits. This is a significant gap for safe tool selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with fully documented optional parameters and no output schema. The description is minimally viable but lacks return value details and usage context, falling short of being complete for an agent selecting among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (onlineOnly, programIds) having descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get session types (class types, appointment types)'. It uses a specific verb and resource, and the parenthetical clarifies the scope. However, it does not explicitly differentiate from similar siblings like getClassDescriptions, though the naming and parenthetical help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about typical use cases, prerequisites, or exclusions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates a read operation but does not disclose what 'site/business information' includes, whether all sites are returned, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and free of unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description is the only source of context. It fails to clarify what a 'site' is, how it relates to locations, or what the return data might look like, leaving significant ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no parameter-specific information, but none is needed given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches site/business information with a specific verb and resource. However, it does not distinguish this tool from sibling tools like getLocations or getResources, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what it does without any context or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the resource is returned but does not describe output structure, pagination, or filtering behavior, nor does it clarify if only active types are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the operation. Every word earns its place; it is not verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description is mostly adequate, but it leaves ambiguity about the meaning of 'class types' and how this differs from getClasses. Given the sibling context, a brief clarification would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so there is nothing to explain. The description adds no parameter semantics because none exist, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with resource 'all class types/descriptions offered', clearly indicating a read operation retrieving class metadata. It distinguishes itself from siblings like getClasses and getClassSchedules by focusing on 'types/descriptions', though 'class types' remains somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool compared to getClasses, getClassSchedules, or getClassVisits. No alternatives or exclusions are mentioned, leaving the agent without context for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action without explaining what 'account balances' includes (e.g., current balance, credit, charges) or whether it returns a single value or list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action verb, and no filler. It is appropriately sized for the simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations or output schema, the description should provide more context about the return value or any special behavior. It is adequate but leaves gaps in understanding what exactly is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single clientId parameter, so baseline 3 applies. The description adds no additional meaning beyond the schema's minimal 'Client ID' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves client account balances, using a specific verb and resource. It distinguishes from siblings like getClientMemberships and getClientVisits by focusing on account balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or context about billing workflows. The description does not mention scenarios like checking outstanding balances before checkout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavioral traits. It only says 'cancel a booking' but does not mention side effects such as whether it is reversible, triggers a waitlist, affects payments, or how lateCancel behavior works. These are critical omissions for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core function directly, exemplifying conciseness, though it lacks additional context, conciseness as a dimension is about size and structure, and this is exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, so the description should provide richer context about behavior, return values, or use cases. However, it only gives a one-line purpose, leaving the agent uninformed about the consequences of cancellation, the meaning of the lateCancel parameter, or what response to expect. This is insufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (classId, clientId, lateCancel), so the schema coverage is 100%. The description itself adds no parameter-level meaning, but the baseline of 3 is appropriate because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel a client's class booking' clearly states the action with a specific verb and resource. It distinguishes from sibling tools like 'addClientToClass' by using 'cancel' rather than 'add', and from viewing tools by the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without exclusions, prerequisites, or mentions of when not to use it, unlike the get_calls example that names an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states the action without disclosing effects such as whether the original teacher is removed, any permission requirements, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and efficient, achieving its goal in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description doesn't explain return values, side effects, or limitations. It is incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for each parameter, so the description adds no additional parameter meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action of substituting a teacher for a class, using the specific verb 'substitute' and resource 'teacher for a class'. This distinguishes it from sibling tools like addClientToClass or getTeacherSchedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or related tools, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It simply states 'Add a new client' without disclosing behavioral details such as whether the operation is idempotent, what permissions are required, what happens on duplicate entries, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero unnecessary words. It is as concise as possible while conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 15 parameters, the description is minimal. It doesn't mention the return value or any side effects, but the schema covers parameter details. The lack of output schema and annotations leaves some gaps, but the core action is clear enough for a simple add operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 15 parameters with descriptions. The tool description adds no information about parameter semantics, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' with the resource 'client', clearly identifying the action of creating a new client record. It distinguishes from sibling tools like addClientToClass, addClientArrival, and updateClient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as updateClient or addClientToClass. There are no stated prerequisites, exclusions, or contextual cues about the creation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it simply restates the tool's name and provides no additional context about return format, pagination, authentication requirements, or any side effects. It gives no information beyond what the name implies, leaving the agent to assume behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that fully conveys the tool's purpose without any unnecessary words. It is appropriately sized for a zero-parameter, read-only tool and wastes no tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no annotations, no output schema—the one-sentence description is largely sufficient. However, it could be marginally improved by explicitly stating the return type (e.g., 'returns a list of location objects'), especially since there is no output schema to fill that gap. Still, for a basic list-retrieval tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. According to guidelines, a baseline of 4 is appropriate since there are no parameters to explain. The description does not need to add parameter information, and nothing is missing in this regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all studio locations' clearly states the verb (get), resource (locations), and scope (all). It is concise and unambiguous, but does not explicitly differentiate from the sibling tool 'getSites', which could be a potential source of confusion. Thus, it misses the highest rating for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The description does not mention any exclusions, prerequisites, or context where another tool would be more appropriate. For a simple getter, some indication of typical use cases or relationships to sibling tools would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Get all staff members with optional filters', which adds no details about permissions, filtering semantics, pagination, or response characteristics. The behavior is largely assumed from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, eight words, and immediately communicates the core function. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with no output schema, the description is adequate but leaves gaps. It doesn't explain filter semantics, available filter options, or any restrictions. Since parameters are well-defined in the schema, this is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has its own description (e.g., 'Filters to apply', 'Specific staff IDs to retrieve'). The tool description only adds the generic phrase 'optional filters', which is redundant with the schema and doesn't clarify how filters are combined or formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (staff members) and action (get all), with optional filters. It is distinguishable from sibling tools like getStaffAppointments and getTeacherSchedule, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read-only listing tool, but provides no explicit guidance on when to use it versus alternatives (e.g., getTeacherSchedule for schedules). It lacks any exclusions or context about filter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It does not disclose whether the operation is read-only, how missing dates are handled, or any response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the core action and resource. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without an output schema, the description could mention what the returned schedule includes (e.g., class times, locations). It also doesn't clarify whether date range is optional, given only teacherName is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters, including date formats. The description's mention of 'specified date range' adds general context but does not clarify optionality or interaction between startDate and endDate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as a teacher's class schedule, scoped by date range. This distinguishes it from sibling tools like getClassSchedules, which likely target class-level schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as getClassSchedules or getStaffAppointments. The description only states what it does without any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the returned data (clients who booked/attended, sign-in status, late cancellations, service info) and the verb 'Get' implies a read-only operation. However, it does not explicitly state read-only behavior, permission requirements, or behavior on invalid classId, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and scope, followed by a concise list of the return contents. Every word adds value, with no redundancy or filler. It is efficiently structured and well-sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no annotations, no output schema), the description is fairly complete: it explains what is returned and covers the main behavior. It lacks guidance on when to use lastModifiedDate or edge cases like invalid classId, but the schema provides parameter details. It could benefit from explicit usage alternatives, but overall it is sufficient for a basic read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both classId and lastModifiedDate have descriptions), so the baseline is 3. The description adds no parameter-level details beyond the schema; 'for a specific class' merely reiterates classId's purpose. It does not elaborate on lastModifiedDate semantics, but the schema already covers it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('client visits/attendance for a specific class'). It distinguishes from sibling getClientVisits by scoping to a class and lists specific returned data (sign-in status, late cancellations, service information), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by saying 'for a specific class' and requiring a classId, but it does not explicitly mention when to prefer this over alternatives like getClientVisits, nor does it state exclusions (e.g., for client-level visits use getClientVisits). It gives clear context but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MindbodyMCP MCP server](https://glama.ai/mcp/servers/vespo92/MindbodyMCP/badges/card.svg)](https://glama.ai/mcp/servers/vespo92/MindbodyMCP)

Score Badge

Copy to your README.md:

[![MindbodyMCP MCP server](https://glama.ai/mcp/servers/vespo92/MindbodyMCP/badges/score.svg)](https://glama.ai/mcp/servers/vespo92/MindbodyMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vespo92/MindbodyMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server