Server Quality Checklist

Tool Scores

• get_pilates_with_neelam_classesB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description itself discloses that this is a read-only operation and enumerates the returned data (schedule, availability, instructor info, class details). It does not mention pagination, response shape, or whether filters are optional, but the core behavior is clearly non-mutating and scoped to upcoming classes.

  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?

  Two efficient sentences with the core action front-loaded and useful return-content detail. No filler, though a brief usage note could have made it even more valuable without hurting conciseness.

  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 description covers what the tool returns but not how it relates to the sibling tools (availability/schedule), nor how the filters behave when omitted. For a 4-parameter tool with no output schema and no annotations, this is adequate but has clear gaps in routing and default 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?

  Schema description coverage is 100%, so all parameters are already explained in the input schema. The description adds no detail about filtering by type/level or the days_ahead default, so it stays at the baseline for fully documented schemas.

  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?

  Description states a clear verb ('Get') and resource ('all upcoming Pilates With Neelam classes') and specifies return contents (schedule, availability, instructor info, class details). However, it doesn't explicitly distinguish from sibling tools like get_pilates_with_neelam_availability or get_pilates_with_neelam_schedule, so it misses the highest bar.

  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 prefer this tool over the four siblings (e.g., availability vs classes vs schedule). No exclusions or alternatives are mentioned, leaving the agent to infer usage purely from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_pilates_with_neelam_scheduleA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the core behavior: it retrieves and returns a structured weekly view, and the 'Get' verb implies a read-only operation. Since no annotations are provided, the description carries the full burden, and it does not explicitly guarantee no side effects, mention authentication needs, or describe behavior for invalid inputs. This is minimally transparent but adequate for a simple getter.

  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 with no filler. The core promise is front-loaded and every word contributes meaning.

  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 low complexity, no output schema, and no annotations, the description is minimally complete: it names the resource and the return shape, and the schema covers all parameters. However, it lacks detail about what the weekly view contains, whether the tool is read-only, and what defaults or edge cases apply, so an agent must infer some 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?

  Schema description coverage is 100%, and the schema already documents both studio_id and week_offset, including the required literal value for studio_id. The description adds no additional parameter semantics, 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 states a specific verb ('Get'), a clear resource ('weekly class schedule for Pilates With Neelam'), and an expected return shape ('structured weekly view'). It is clear and specific, but it does not explicitly differentiate itself from the similar sibling get_pilates_with_neelam_classes, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: an agent would use this when it needs the weekly schedule for Pilates With Neelam. However, the description gives no explicit guidance about when to prefer this over siblings like get_pilates_with_neelam_availability or get_pilates_with_neelam_classes, nor any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• check_in_pilates_with_neelam_classA
  3.6/5.0
  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 does reveal that a check-in is recorded and that a summary and exercise recommendations are generated, but it omits whether this creates or updates a persisted record, whether auth is required despite the optional auth_token parameter, and what side effects or return value the agent should expect.

  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?

  Two sentences with no filler; the core action is front-loaded and the outcome is stated compactly. Every sentence earns its place.

  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?

  Even though all parameters are documented in the schema, there is no output schema and no annotations. The description does not explain return values, persistence side effects, error conditions, or when the optional auth_token is actually needed, leaving an agent with important gaps for a mutating 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%, so the baseline is 3. The description reinforces the 'feeling' input and the overall check-in purpose but adds no new semantic detail beyond what the schema already documents for each parameter.

  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 a specific verb ('Record') and a clear resource ('post-class check-in for a student at Pilates With Neelam'), then adds the concrete outcomes: captures feelings, generates a summary, and recommends exercises. This distinguishes it clearly from the get/book/schedule sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'post-class check-in' clearly places this tool in a specific workflow moment, and the action is distinct from booking, availability, scheduling, and level-assessment siblings. It does not explicitly list exclusions or alternatives, but the intended use case is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_pilates_with_neelam_availabilityA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full disclosure burden. It does disclose the output content (spots available, enrolled students, booking status) and 'Check' or the 'get_' prefix imply a non-mutating operation, but it never explicitly states read-only behavior, auth requirements, or absence of side effects. This is adequate but not comprehensive.

  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 short sentences with zero filler: the first states the action and object, the second summarizes the return fields. Information is front-loaded and every word earns its place.

  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?

  For a simple read-only tool with two parameters and no output schema, the description sufficiently conveys purpose and return contents. It does not describe the exact response shape or status possible values, but an agent has enough to decide invocation and interpret the result. This is nearly complete for the tool's simplicity.

  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%, and the schema already documents both parameters clearly (class_id with an example, studio_id with the exact accepted value). The description adds no parameter-level detail beyond what the schema provides, so the baseline of 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 states a specific verb ('Check real-time availability'), a specific resource ('a specific Pilates With Neelam class'), and explicitly lists the returned data ('spots available, enrolled students, and booking status'). This clearly distinguishes it from siblings like get_pilates_with_neelam_classes or get_pilates_with_neelam_schedule, which serve listing/scheduling purposes rather than occupancy checks.

  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 the tool is for when real-time occupancy data is needed, but it does not explicitly contrast usage with sibling tools or state when not to use it. It provides context ('real-time availability') but no exclusions or alternative routing, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_studio_manifestA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full disclosure burden. 'Get' signals a read operation, and 'verify the MCP server is connected to the correct studio' usefully reveals the tool's role as a connection check. However, it doesn't explicitly state side-effect-freeness or what happens on failure or wrong-studio connection — minor gaps for a zero-parameter read 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?

  Two short sentences totaling roughly 25 words. The first delivers the verb and resource; the second delivers the usage timing. Every sentence earns its place, with no fluff and no repetition of schema content.

  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?

  For a zero-parameter tool with no output schema and no annotations, the description covers what it returns (studio identity and manifest) and when to call it. It doesn't specify the manifest's contents or return format, but at this low complexity tier nothing critical is missing for correct invocation.

  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 properties, so there are no parameters to document, placing this at the baseline of 4. The description appropriately avoids inventing parameter detail, and its only guidance ('call this first') is behavioral rather than parameter-related.

  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 and resource — 'get' the 'Pilates With Neelam studio identity and manifest' — which clearly sets this apart from all class/schedule/booking-level siblings. The second sentence reinforces purpose by framing it as the server connection verification tool. 'Manifest' is mildly jargon-y and could be expanded, but the intent is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit temporal guidance: 'Call this first to verify the MCP server is connected to the correct studio' tells the agent exactly when to invoke it. It doesn't name alternatives or state when not to use it, but the sibling names (find_my_class, book_..., check_in_...) make the non-overlap obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• assess_pilates_levelA
  4/5.0
  Behavior3/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 states the outcome ('Returns recommended level, focus areas, and suitable classes'), but does not disclose whether the assessment is read-only, whether it persists any record, or what side effects may occur.

  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?

  Two crisp sentences with no filler: the first states purpose and audience, the second states the return value. It is front-loaded and every word earns its place.

  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 schema covers all inputs and the description covers the essential output categories, an agent has enough to select and invoke the tool correctly. It could be stronger on side effects and return format, but for an assessment tool with a fully documented schema, it is substantially complete.

  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 parameters including goals, experience, injuries, and fitness level are already documented structurally. The description adds no parameter-specific semantics, but the schema fully compensates, so the baseline 3 is appropriate.

  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 starts with 'Run a Pilates level assessment', a specific verb and resource, and specifies the studio context. It clearly distinguishes this from all sibling tools, none of which perform an assessment.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear trigger condition: it is for 'a new or existing student at Pilates With Neelam' who needs a level assessment. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct enough that this is a minor gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_my_classA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations present, the description carries the burden of behavioral disclosure. It explains that queries are interpreted in natural language and that the result is matching classes with availability, which is useful and accurate. It does not mention edge behaviors like empty results or ambiguity handling, but for a read/search tool the disclosure is reasonably complete.

  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 compact, front-loads the tool's core purpose, and uses example queries to convey behavior efficiently. Every sentence earns its place, with no redundant filler or schema repetition.

  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?

  The description covers the tool's input style and return type ('matching classes with availability'), which is sufficient for a low-complexity search tool with two fully documented parameters. There is no output schema, so a bit more detail about the exact response shape or ordering could help, but the description still gives an agent enough to invoke 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?

  Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds example query phrasing that supports the query parameter but does not add substantive meaning beyond the schema. This matches the baseline for fully schema-covered parameters.

  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 that the tool searches for Pilates With Neelam classes using natural language, which is a specific verb and resource. It also gives concrete example queries, making the tool's purpose easy to grasp. It does not explicitly name a sibling alternative, but natural-language search is distinct enough from the other get_/book_/check-in tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when a user expresses a class-search need in natural language. The example queries further illustrate acceptable usage. It does not explicitly state when not to use it or name alternatives, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• book_pilates_with_neelam_classA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden, and it discloses meaningful behavior: it validates studio identity, class availability, and enrollment rules, and it returns a booking confirmation with studio identification. It adds transparency beyond the bare action, though it does not detail failure modes or side effects beyond booking.

  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?

  Three short sentences, each earning its place: the action, the validation behavior, and the return value. The most important information is front-loaded and there is no redundant wording.

  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 fully documented schema and the description's coverage of the core action, validations, and return value, the tool is sufficiently specified for an agent to invoke it correctly. It does not fully describe error handling or the exact shape of the booking confirmation, but these are minor gaps for a straightforward booking 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?

  The input schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter-specific semantics beyond implying that studio identity and enrollment rules are checked, but the schema already explains studio_id and class_id 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 a specific action ('Book a student into a Pilates With Neelam class') with a concrete resource and scope. It is distinguishable from siblings like check_in_pilates_with_neelam_class and the various get/list tools, so an agent can tell booking from checking in or viewing availability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when the tool is appropriate: booking a student into a class, with validation of studio identity, availability, and enrollment rules. It does not explicitly name alternative tools or state when not to use it, but the booking action is unambiguous relative to the sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.