Server Quality Checklist

Tool Scores

• add_expenseC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits itself. It states this is a DB insert, but does not mention permissions, idempotency, validation, side effects, or return value.

  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, front-loaded sentence with no filler. It is concise, though it sacrifices useful detail in favor of brevity.

  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 5 undocumented parameters, no annotations, and no output schema, the description is not complete enough for an agent to invoke the tool confidently. It conveys the high-level action but omits required input semantics and behavior.

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

  Parameters1/5

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

  The input schema has 5 parameters with 0% description coverage, and the description adds no parameter-level meaning. The agent must infer semantics solely from parameter names like 'amount' and 'category'.

  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 uses a specific verb and resource ('Add a new expense') that clearly identifies the operation. It is distinct from the sibling tools by nature, but it does not explicitly call out the differentiation.

  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?

  There is no guidance on when to use this tool versus list_expenses or summarize. The verb 'Add' implies creation, but no context, prerequisites, or exclusions are provided.

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

• summarizeC
  2.9/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 reveals that the tool summarizes expense data by category, but it does not clarify whether the category parameter filters or groups results, what happens when category is null, whether the operation is read-only, or what the returned summary looks like.

  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, compact sentence with no filler. It front-loads the operation and grouping dimension, though the word 'that' is slightly ambiguous and could have been replaced with 'specified' or 'given'.

  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 no annotations, no output schema, and 0% parameter coverage, the description is not complete enough for an agent to invoke the tool confidently. It leaves the category behavior ambiguous and omits date format and output-shape details.

  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 startdate/enddate have empty schemas, so the description must compensate. It adds only the notions of 'date range' and 'category', but it does not explain parameter formats, the meaning of the optional category default, or how the date range boundaries are handled.

  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 ('summarize'), a resource ('expenses'), and the grouping dimension ('by category') with a date range, which clearly conveys an aggregation purpose. It is distinct from list_expenses and add_expense by its verb, though it does not explicitly name those alternatives.

  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 aggregate reporting on expenses within a date range, rather than listing individual expenses or adding them. However, it gives no explicit when-to-use or when-not-to-use guidance and does not mention the sibling tools.

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

• list_expensesA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It discloses that this is a read-only listing operation and that it returns all entries rather than a filtered or aggregated subset, but it does not clarify date inclusivity, ordering, pagination, or the output structure.

  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 concise sentence with no redundant wording or repeated schema information. Every phrase contributes: the action, the resource scope, and the date constraint.

  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 two-parameter list tool, the description gives the core invocation intent, but there is no output schema and no annotation safety information. An agent would still need to infer the return format and the accepted date representation, so the description is adequate but not fully 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?

  The input schema provides no property descriptions, so the description is the only semantic source. It names both startdate and enddate and states that they define the range boundaries, which adds real meaning beyond the empty schema entries. However, it does not specify date format or whether the bounds are inclusive/exclusive.

  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 ('Listing') with a clear resource ('all expense entries') and a date-range constraint, so an agent immediately knows what the tool does. It is also distinguishable from the sibling tools add_expense and summarize, which are write/aggregation actions rather than retrieval.

  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 phrasing 'Listing all expense entries between startdate to enddate' clearly implies the tool is for retrieving every expense record in a specified range. It does not explicitly name alternatives or exclusion criteria, but the sibling tools are so different in purpose that the intended context is still obvious.

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