Server Quality Checklist

Tool Scores

• list_supported_questionsB
  3.2/5.0
  Behavior3/5

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

  The phrase 'can and can't answer' usefully reveals that the tool covers both supported and unsupported questions, which goes beyond the name. However, with no annotations available, the description carries the full transparency burden and does not explicitly state that this is a read-only operation or describe the output format.

  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?

  A single, concise sentence with no filler. The dash creates a clear appositive, and every word contributes meaning, achieving maximum efficiency.

  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 and has an output schema, so the description need not explain return values. However, the vague phrasing and lack of usage guidance make it only minimally complete for an agent to understand when and why to call this tool.

  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, so schema coverage is effectively 100%. The description adds no parameter semantics, but none are needed; baseline score for zero-parameter tools is 4.

  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's 'governed capability set' is vague and does not explicitly state that the tool lists supported questions, but the tool name makes the function clear. It does differentiate from sibling data-retrieval tools by focusing on system capabilities rather than specific metrics.

  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. The description lacks any context about discovering capabilities before querying or any comparison with the sibling tools, leaving the agent without decision criteria.

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

• get_deal_reasonA
  3.7/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 behavioral disclosure burden. It does disclose that the tool 'refuses if empty' and returns the reason 'verbatim', which are useful behavioral details. However, it does not explicitly state read-only status, permission requirements, or error handling for invalid account_name/viewer, leaving 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 extremely concise—two short sentences plus an Args list—and front-loads the core purpose. Every sentence earns its place, with no redundancy or fluff. The structure is clean and immediately scannable.

  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 with only two parameters and an output schema, so the description does not need to detail return values. It covers the main behavior, parameter meanings, and an important edge case (empty refusal). It lacks broader usage context or explicit safety statement, but for a simple read tool, it is largely 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 Args section adds meaning beyond the bare schema: account_name is described as 'The account to look up' and viewer as 'LEADERSHIP or a rep_id. Required.' This compensates for the schema's 0% description coverage and clarifies the expected format for viewer. The descriptions are concise but valuable.

  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 resource (stored loss_reason) and scope (one account), and the tool name includes 'get'. It differs from sibling tools by focusing on a specific deal/account reason rather than segment attainment, reps at risk, pipeline value, or supported questions. It lacks an explicit verb, but the intent 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 Guidelines3/5

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

  The description implies usage via 'for one account' and 'Refuses if empty', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. It offers only implied context, so it meets the 'implied usage' level.

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

• get_reps_at_riskA
  3.7/5.0
  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 explains the core filtering logic and parameter roles, but omits important behavioral traits such as how the viewer parameter affects data scope (e.g., whether a rep_id returns only that rep's data vs a leadership view of all reps), access permissions, auth requirements, or error 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 concise and well-structured: two sentences for the main purpose, followed by a clear Args section. Every sentence provides necessary information, with no redundancy or filler.

  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 modest complexity and the presence of an output schema, the description covers the essential function and parameters. However, it lacks details on viewer role semantics (e.g., what data a rep_id viewer can access) and potential edge cases, leaving some contextual ambiguity for an agent deciding when and how to invoke the tool.

  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?

  Schema description coverage is 0%, so the description must compensate. It does so effectively by defining viewer as 'LEADERSHIP' or a rep_id and threshold as a numeric cutoff in [0.0, 1.0] with a default of 0.70, adding meaning beyond the raw schema types.

  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 returns reps whose Q1 2026 closed-won attainment is below a threshold, using a specific verb and resource. It distinguishes itself from sibling tools like get_segment_attainment and get_pipeline_value by focusing on rep-level at-risk status based on attainment.

  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 through the threshold and viewer parameters, but does not explicitly state when to use this tool versus alternatives. It provides no exclusions or references to sibling tools, leaving the agent to infer applicability from the functional definition.

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

• get_segment_attainmentA
  4.3/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 transparency burden. It provides useful behavioral details such as allowed values for segment and viewer, and marks viewer as 'Required.' However, it does not disclose error handling, authorization implications of the viewer parameter, or explicitly state that this is a read-only operation, leaving some ambiguity.

  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 and well-structured. The main purpose is front-loaded in a single line, followed by a clean arguments block. Every sentence adds value, with no redundant or wasted words.

  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 has an output schema, so return values are covered elsewhere. The description provides the time period, allowed segment values, and viewer types, which covers the essential context for a simple two-parameter tool. However, it leaves the purpose of the viewer parameter slightly ambiguous (e.g., whether it is for permission filtering or data scoping), which could be clearer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. It explains both parameters: segment (one of three named values) and viewer (either 'LEADERSHIP' or a rep_id like 'REP-02,' required). This adds essential meaning beyond the bare string types in the schema.

  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: 'Q1 2026 closed-won attainment vs. quota for one segment.' This is a specific verb-resource combination with scope (one segment) and time period, effectively distinguishing it from sibling tools that focus on reps at risk, pipeline value, deal reasons, and supported questions.

  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 implies usage context by stating 'for one segment,' which suggests using this tool when segment-level attainment data is needed. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent would understand its purpose relative to sibling tools, which have different focuses.

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

• get_pipeline_valueA
  4.8/5.0
  Behavior5/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 clearly explains the calculation logic, the meaning of 'open-stage', and the exact filter semantics (e.g., close_before keeps deals with close_date <= the given date). This makes the tool's behavior transparent.

  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 and well-structured: a one-line summary followed by a bulleted Args list. Every sentence provides essential information, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the description covers the computation, all parameters, and filter semantics. The presence of an output schema means return-value details need not be in the description. This is fully adequate for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description fully compensates by explaining each parameter: viewer must be 'LEADERSHIP' or a rep_id and is required; segment is an optional filter; close_before is an optional ISO date with an exact comparison rule. This adds substantial meaning beyond the raw schema.

  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 computes a sum of open-stage deal_value with optional filters. It uses a specific verb ('Sum') and resource ('deal_value'), distinguishing it from sibling tools like get_segment_attainment or get_reps_at_risk.

  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 (computing pipeline value) and explains optional filters, but it does not explicitly name alternatives or when-not-to-use conditions. The context is unambiguous, so it earns a 4 rather than a 5.

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