Server Quality Checklist

Tool Scores

• get_trainer_attendanceC
  2.7/5.0
  Behavior2/5

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

  There are no annotations, so the description carries full behavioral disclosure responsibility. It only states the output (attendance and fill-rate) and allowed periods, but does not mention whether the tool is read-only, requires specific permissions, or what the response format looks like. No side effects or caveats are disclosed.

  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 that delivers the core purpose and period scope immediately. There is no wasted wording. It is appropriately front-loaded, though its brevity sacrifices detail that might be necessary for full comprehension.

  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 only two simple parameters and no output schema, the description could be expected to explain the meaning of 'fill-rate' and how to specify a trainer, which it does not. The tool might return aggregated data, but no information is provided about the nature of the output or any default behavior beyond 'week' in the schema. Overall, the description is minimal and leaves important questions unanswered.

  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%, so the description must compensate. It clarifies that 'period' accepts 'day' or 'week', which adds value beyond the schema's default. However, it does not explain what 'trainer' expects (e.g., ID, name), nor does it elaborate on any other constraints. The parameter semantics are only partially addressed.

  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 returns attendance and fill-rate for a trainer, and specifies that the period is either 'day' or 'week'. This is specific enough to distinguish it from siblings like get_class_performance or get_revenue_insights, though it lacks an explicit verb like 'retrieve'. The purpose is unambiguous and not a tautology.

  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 the sibling tools. The description only mentions the period options ('day' or 'week') without context on which scenario warrants this tool. There are no exclusions or alternative tool references, so an agent might struggle to decide when this is the appropriate choice.

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

• get_class_performanceB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided (e.g., readOnlyHint, destructiveHint), so the description carries the full burden of disclosing behavioral traits. The description only says 'Rank classes by fill rate' but does not disclose whether this is a read-only operation, whether it performs any calculations or aggregation, or whether any side effects exist. For a read-only reporting tool, even a phrase like 'Returns a list' would help, but it is missing. The description does not contradict any annotations (since none exist), but it fails to convey expected behavior beyond the high-level result.

  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, highly concise, and immediately communicates the core purpose. It is front-loaded with the action 'Rank classes' and provides a practical implication ('popular vs. dead classes to cut'). No unnecessary words or repetition. It is appropriately sized for its simplicity.

  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 tool's simplicity (one parameter, no output schema), the description covers the main intent well. However, it lacks details about the return type (e.g., does it return a list with fill rates?), how 'limit' affects results, and whether it includes only active classes or all classes. Since there is no output schema, the description should provide some indication of what the tool returns. The description is adequate for a simple read-only tool but is not comprehensive for an agent that might need to interpret results.

  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?

  There is one parameter, 'limit', which has a default and no description. Schema description coverage is 0%, but with only one parameter, the description's mention of 'Rank classes' implies that 'limit' likely controls the number of classes returned. However, the description does not explicitly explain the 'limit' parameter, so an agent might not know if it controls the number of classes or something else. While the single parameter is self-explanatory to a human, the description adds no specific explanation, so the agent must infer from the schema's default value.

  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: to rank classes by fill rate, identifying popular and dead classes for potential cutting. The verb 'Rank' and resource 'classes' are specific, and the purpose is distinct from siblings like 'get_today_summary' (which likely provides a summary) and 'get_revenue_insights' (which focuses on revenue). However, it does not explicitly mention the return format or the scope of data (e.g., current vs. historical), so it is not perfect.

  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 planning class cuts or evaluating class performance, but it does not explicitly state when to use this tool versus alternatives. For example, it does not say 'Use this when you need to identify underperforming classes' or 'Instead of get_revenue_insights, use this for class-level fill rates.' The guidance is minimal and relies on inference.

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

• get_today_summaryB
  3.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 carry the burden of behavioral disclosure. It describes what data is returned (classes held, total attendance, top classes) but does not mention any side effects, auth requirements, or limitations beyond the summary nature. This is adequate but not rich.

  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, straightforward sentence that immediately states the tool's purpose and output content. There is no superfluous text or wasted words.

  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 tool with one optional parameter and no output schema, the description covers the core output but lacks details on parameter usage and potential edge cases. It gives the essential summary items but does not fully flesh out behavior, making it minimally complete.

  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?

  With 0% schema description coverage, the description must explain the gym_id parameter. It does not mention the parameter at all, leaving the optional gym_id with default 'demo' unexplained. The agent cannot infer how gym_id affects the summary from the description alone.

  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 provides a daily attendance summary, specifically listing what it includes: classes held, total attendance, and top classes. It distinguishes from sibling tools like trainer attendance, class performance, and revenue insights by focusing on the overall attendance dashboard.

  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 offers no guidance on when to use this tool versus alternatives. It does not mention exclusions or specific contexts, leaving the agent to infer that it is for daily overviews. Without explicit comparison to siblings, usage guidance is minimal.

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

• get_revenue_insightsA
  3.6/5.0
  Behavior2/5

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

  With no annotations, this description carries the full disclosure burden. It implies a read-only query but doesn't explicitly state side effects, data scope, or output behavior, offering only a minimal observation about profitability.

  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 sentence, each word adds value. No filler or redundancy.

  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 tool is simple and the description adequately conveys its purpose. While it could mention performance limits or return format, these are likely implied by the simplicity. It's complete enough for an agent to infer usage.

  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?

  Zero parameters mean the schema already fully describes them (empty). The description adds value by implying the tool returns a comparison, but no parameter docs are needed since there are none.

  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 specifies the action ('most profitable vs. least profitable classes') and the resource ('classes by revenue'). It distinguishes from sibling tools like get_cluster_metrics or get_classification_metrics by focusing on profitability analysis.

  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 prerequisites, frequency, or any context for selection, leaving the agent to infer.

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