Server Quality Checklist

Tool Scores

• get_client_infoB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility. It only states 'Fetch detailed profile information', omitting any behavioral traits such as read-only nature, authentication needs, error behavior, or side effects. This is insufficient for a tool without annotations.

  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 key action and resource, and no wasted words. Every sentence adds value.

  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?

  Though the tool is simple with one parameter and no output schema, the description fails to explain what 'detailed profile information' includes, which is critical for an AI agent to ground responses. Without output schema or description of return data, the tool is under-specified.

  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 does not add any meaning beyond the schema's description of 'client_id'. No additional context is provided about the 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 clearly states the verb 'Fetch' and the resource 'detailed profile information for a Mindbody client'. It also provides context ('Used by AI front-desk agents to ground responses in customer history'), which distinguishes it from sibling tools like book_appointment or list_classes.

  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 for grounding customer responses but does not explicitly state when to use this tool versus alternatives or provide exclusions. The sibling tools are functionally distinct, so the context is adequate but not explicit.

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

• book_appointmentA
  3.6/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 discloses the gated feature and error condition but does not describe side effects, permissions needed, or expected success response. For a creation tool, more behavioral context is needed.

  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 concise—two sentences that front-load the purpose and add a critical gating condition. No unnecessary words or redundant 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?

  Given 4 required parameters, no output schema, and no annotations, the description lacks important context such as what the tool returns on success, prerequisites (e.g., checking availability), and any rate limits. The gating information is helpful but incomplete.

  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 75% (client_id missing description). The tool description does not add any parameter-level information beyond what the schema provides. While the schema itself is reasonably descriptive, the missing client_id description is not compensated.

  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 schedules a single wellness or training appointment for a client with a specific staff member at a specific time. It distinguishes itself from sibling tools like book_client_to_class (books a class) and checkout_shopping_cart (checkout process).

  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 mentions the gating condition (MINDBODY_ALLOW_BOOKINGS) and error return if not enabled, but does not provide explicit guidance on when to use this tool versus alternatives like book_client_to_class. The context is implied but not directly stated.

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

• book_client_to_classA
  3.6/5.0
  Behavior3/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 states the gating condition and that the action results in a real reservation, but lacks details on idempotency, side effects, or whether the booking is irreversible.

  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 extremely concise with three sentences, each serving a purpose: stating the action, noting the gating condition, and clarifying the real-world impact. No extraneous 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?

  For a tool with 2 parameters and no output schema, the description covers the core purpose and a key constraint (env var gating), but omits details about parameter validation, failure modes like full classes, or expected behavior when successful.

  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?

  Schema description coverage is 0%, and the description fails to explain the parameters 'client_id' and 'class_id' beyond the implied meaning from the action. No details on format, source, or constraints are provided.

  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: enrolling a client into an upcoming studio class. The verb 'enroll' and the resource 'client into class' are explicit. It distinguishes itself from sibling tools like 'book_appointment' which likely books appointments, not classes.

  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 mentions the tool is gated behind an environment variable and returns an error if not enabled, but does not provide explicit guidance on when to use this tool versus alternatives like 'book_appointment' or scenarios where it should not be used.

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

• list_classesA
  3.6/5.0
  Behavior2/5

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

  No annotations provided; description only says 'Query class schedules and active class lists within a date range' without details on return format, pagination, or behavior when parameters are omitted. This is insufficient 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, directly to the point, no wasted 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?

  Without an output schema, the description should clarify what the tool returns. It only mentions a query action but omits result format, limiting the agent's understanding of how to use the output.

  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 already documents both parameters. The description adds no additional meaning beyond the schema's ISO 8601 format specification.

  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?

  Description clearly states it queries class schedules and active class lists within a date range, specifically for AI scheduling agents. This distinguishes it from sibling tools like book_appointment or book_client_to_class.

  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?

  Context is provided for AI scheduling agents to surface available classes, implying when to use. However, it does not explicitly state when not to use or list alternatives.

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

• checkout_shopping_cartA
  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 must convey behavior. It states it takes payment and is gated, but lacks details on side effects (e.g., inventory changes, confirmation). It is reasonably transparent but not fully exhaustive.

  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 effectively convey purpose, gate condition, and payment action. No wasted words; front-loaded with key intent.

  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 no output schema, the description explains the action (payment checkout) and a key prerequisite (env var). Missing details like confirmation or error scenarios, but sufficient for a payment trigger 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 50%, with descriptions for item_id and item_type. The description mentions 'passes, services, or products' which aligns with item_type enum, but does not add significant new meaning beyond schema. A 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 clearly states it processes purchases and completes payment checkout for passes, services, or products. This contrasts well with sibling tools that focus on booking or client info, making its unique purpose evident.

  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?

  It explicitly mentions being gated behind an environment variable and warns that it takes payment and returns an error if disabled. While it doesn't explicitly list when not to use, the context strongly implies it is for payment only, distinct from booking tools.

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