Server Quality Checklist

Tool Scores

• get_expensesB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It merely states 'Get a list of expenses' without explaining that filtering is optional, whether the result is paginated, or any access requirements. The behavior is minimally transparent but lacks useful context beyond the action 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 sentence that effectively communicates the core function. It contains no filler, is immediately clear, and is appropriately sized for a simple read tool.

  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 and full schema coverage, the description is mostly adequate. However, it lacks any mention of optional filters or how the result relates to get_summary, leaving some contextual gaps. It does not need to explain return values since no output schema exists, but more behavioral detail would improve completeness.

  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 each parameter (year, month, category) already has a description. The tool description adds no additional parameter semantics. Baseline of 3 is appropriate given the schema fully documents the parameters.

  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 'Get a list of expenses' uses a specific verb and resource, clearly indicating the tool's purpose. It is distinguishable from siblings add_expense, delete_expense, and get_summary, as it focuses on listing expenses rather than modifying or summarizing them.

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

  Usage Guidelines1/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 scenarios where get_expenses is preferred over get_summary, nor does it note any prerequisites or limitations. There is no explicit context or exclusions.

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

• add_expenseB
  3.3/5.0
  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 'Add a new expense' and does not mention that the operation is permanent, what the response will be, or any potential side effects. 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 redundant words or filler. It is appropriately sized for a simple tool and every word contributes to the 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?

  The tool is simple and the schema provides complete parameter details, but with no annotations or output schema, the description should ideally note what happens on success (e.g., a confirmation) or any lasting effects. The current description is minimal but adequate for a basic create 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 fully documents all parameters with descriptions, defaults, and formats (100% coverage). The description adds no additional meaning beyond the schema, so the baseline score 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 'Add a new expense to the tracker' clearly identifies the action (add), the resource (expense), and the context (tracker). It is distinct from sibling tools that get, summarize, or delete expenses.

  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 usage context is provided. The description does not mention when to use this tool, prerequisites, or when not to use it compared to alternatives like delete_expense. It simply states the action without any conditions.

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

• delete_expenseB
  3.3/5.0
  Behavior2/5

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

  There are no annotations to fall back on, and the description only states the action without disclosing behavioral traits such as permanence of deletion, return values, or error behavior. This is a minimal description for a mutating 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, focused sentence that directly states the operation and the key parameter. 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?

  Given the simplicity of the tool (one parameter, no output schema), the description is sufficient to convey the core operation. However, it omits potential details about outcomes or side effects, which are not covered by annotations or schema. For a simple delete, this is marginally 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 describes expense_id fully ('The ID of the expense to delete'), and the description's 'by its ID' adds no additional meaning. With 100% schema coverage, the baseline of 3 applies; no extra semantics 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 uses the specific verb 'Delete' with the object 'expense' and identifies the parameter 'by its ID,' clearly distinguishing this from sibling tools like add_expense, get_expenses, and get_summary. It says exactly what the tool does and on what resource.

  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 explicit guidance on when to use this tool rather than alternatives, nor any prerequisites or exclusions. The only hint is the verb 'Delete,' but no context about permissions, irreversibility, or when to choose this over sibling tools is provided.

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

• get_summaryA
  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 burden of behavioral disclosure. It states the core behavior (summarizing expenses by category for a month) but does not disclose details like whether the summary includes totals, counts, or only categories with expenses, nor does it mention what happens if no expenses exist.

  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 immediately conveys the tool's purpose and key qualifier (by category, for a specific month). It contains no fluff or redundant information.

  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 (two required parameters, no output schema, no annotations), the description adequately conveys the tool's function and required inputs. It could be slightly more complete by specifying the return format or edge cases, but the core selection and invocation information is present.

  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 each parameter described in the schema. The description adds context by noting the summary is for a 'specific month', linking both year and month parameters to the tool's purpose, but it does not provide extra syntax or format details beyond 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 specifies the action (Get), the resource (summary of expenses), and the exact scope (by category for a specific month). It distinguishes this from sibling tools like get_expenses, which likely returns detailed expense records rather than an aggregated summary.

  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 tool is for obtaining an aggregated view by category for a month, but it does not explicitly mention when to use this over get_expenses or list any exclusions. Sibling tool names are present but not referenced in the description, so usage context is only implied.

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