Server Quality Checklist

Tool Scores

• keep_remove_itemsB
  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 states the destructive action ('delete') but does not disclose permanence, whether the operation is reversible, what happens if an item is not found, or how the target checklist is selected. For a deleting tool, this is a significant transparency 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, front-loaded sentence with no filler. Every word contributes to identifying the action, target, and selection method.

  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?

  The tool has three parameters, no annotations, and no schema-level descriptions, yet the description does not explain how to specify the checklist or what the deletion semantics are. The output schema mitigates return-value concerns, but the description is still too sparse for an agent to invoke the tool correctly in all realistic cases.

  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 for parameter meaning. The phrase 'by name' gives some semantics to the items parameter, but note_id and list_title are left unexplained. It is unclear whether one or both are required, which is which, or how they interact.

  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 states a specific verb and resource: 'Delete items from a Keep checklist by name.' It is clearly distinct from siblings like keep_add_items, keep_check_items, and keep_uncheck_items, which involve adding or toggling rather than removing.

  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 the use case: remove checklist items by name. However, it does not explicitly explain when to prefer this over alternatives, nor does it describe prerequisites such as specifying a note_id or list_title to locate the correct checklist. Usage guidance is mostly left to inference from the tool name and siblings.

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

• keep_uncheck_itemsB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose the state-changing effect ('untick' and 'put them back on the shopping list'), which is minimally informative. It does not mention idempotency, whether items must already be checked, authorization needs, or failure behavior, but for this simple operation the stated effect provides a basic transparency baseline.

  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 sentence with a useful clarifying parenthetical. It is front-loaded and contains no filler, making it easy for an agent to parse quickly.

  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 an output schema exists, so the description does not need to explain return values. However, the description is incomplete as a standalone guide because it does not explain the roles of the optional parameters or provide usage boundaries relative to sibling tools. It is minimally viable but no more.

  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 for parameter meaning. The description references 'items' only implicitly via 'checklist items', and says nothing about note_id or list_title, which are optional but likely affect which list/note is targeted. This leaves significant semantic gaps.

  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 ('Untick') and resource ('Keep checklist items'), and clarifies the result with a parenthetical effect. It is clear enough to be distinguished from keep_check_items semantically, though it does not explicitly name any sibling or contrast itself with 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 intended use is implied: use this tool when items need to be unchecked or returned to the shopping list. However, there is no explicit guidance about when not to use it, nor any comparison to sibling tools like keep_check_items, keep_remove_items, or keep_add_items.

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

• keep_check_itemsA
  3.6/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 does disclose the matching strategy, but it omits important behavior such as what happens when no item matches, which note/list is targeted when note_id and list_title are absent, and whether the operation is idempotent or can partially succeed.

  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 concise sentences with no filler. The core action and timing are front-loaded, and the matching rule earns its place because it directly affects how an agent should invoke the 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?

  The tool is simple enough that this description covers the common use case, and an output schema exists so return-value details are not required. However, the ambiguity around how note_id and list_title select the target checklist, plus the lack of failure behavior, leaves meaningful gaps for an agent deciding how to call it reliably.

  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 adds meaning for the required 'items' parameter by explaining item-name matching and substring behavior, but it gives no semantic guidance for the optional 'note_id' or 'list_title' parameters, which are ambiguous from the schema 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 uses a specific verb and resource: 'Tick off Keep checklist items'. It also states the trigger context, 'after they have been added to the Tesco basket (or bought)', which clearly differentiates this from sibling tools like keep_add_items, keep_uncheck_items, and keep_remove_items.

  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 gives a clear usage condition: items should be ticked off only after they have been added to the basket or bought. It also explains the matching rule, 'Match by item name; unique substrings are ok', but it does not explicitly state when to prefer a sibling tool such as keep_uncheck_items.

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

• keep_create_listA
  3.6/5.0
  Behavior2/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 prerequisite that the list should not exist, but it does not state what happens if the list already exists, whether duplicate titles cause errors, or what side effects creation has. For a mutating tool, this leaves important behavioral unknowns.

  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 short sentences with no filler. The primary action is front-loaded, and the usage constraint with alternative is stated immediately after. Every word earns its place.

  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, has an output schema, and the description includes key routing guidance. However, it lacks behavior for duplicate titles and fails to mention the optional items parameter. As a mutation tool with no annotations, these gaps prevent full self-contained understanding.

  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?

  Schema description coverage is 0%, so the description must compensate, but it says nothing about the 'title' or 'items' parameters. The title is somewhat self-evident from the tool name, but the optional items parameter is completely unexplained—an agent is left to guess whether items can be seeded during creation and how they should be formatted.

  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 and resource: 'Create a new Keep checklist.' It clearly differentiates this tool from the sibling keep_add_items by stating its distinct role of creating a new list rather than adding to an existing one.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool ('only if the shopping list does not already exist') and names the alternative to prefer in the opposite case ('prefer keep_add_items on the existing list'). This is direct, actionable guidance.

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

• keep_add_itemsA
  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 burden of behavioral disclosure. It usefully reveals that items are added unchecked and that duplicates are not prevented automatically. However, it does not explain side effects such as how the target list is resolved via note_id or list_title, or what happens if the target does not 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 two tight sentences. The purpose is front-loaded, and the second sentence adds a valuable caveat without redundancy. Every sentence earns its place.

  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 description covers the main workflow and the duplicate-prevention concern, which is essential. But it leaves the distinction between note_id and list_title unexplained, and does not clarify whether the shopping list is the default target. This makes the description minimally viable but incomplete for confident use with optional parameters.

  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 only hints at 'items' through 'one or more ... items'. The optional parameters note_id and list_title, which determine which checklist is modified, are not explained at all, leaving a meaningful gap for correct invocation.

  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 names a specific verb ('Add'), a concrete resource ('one or more unchecked items to a Keep checklist (the shopping list)'), and the resulting item state ('unchecked'). This clearly distinguishes the tool from siblings like keep_check_items, keep_uncheck_items, and keep_remove_items.

  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 gives actionable usage guidance: 'check keep_get first' to avoid duplicates, and it frames the target as the shopping list. It does not explicitly state when not to use this tool versus siblings like keep_check_items or keep_remove_items, so it falls short of a 5.

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

• keep_findA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description must carry behavioral disclosure. It explains the search scope and return fields (id, title, type, pinned, items), which is meaningful, but it does not state behavior of empty query, limit, sorting, or absence of side effects.

  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 short sentences with no filler. The core behavior and return fields are front-loaded, and the practical use case is a single helpful closing clause.

  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?

  For a simple two-parameter search tool with an output schema, it covers operation, match scope, return contents, and a concrete use case. It could add explicit empty-query/default-limit behavior, but overall the context is sufficient.

  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 0%, so the description must compensate. It does explain that query matches title or body text, but it never clarifies limit's meaning beyond its default, nor how an empty query behaves. Partial compensation, but not complete.

  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 ('Search') and resource ('Keep notes and checklists') and specifies matching criteria (title or body text). It also lists return fields, and the use-case framing (find shopping list without exact title) differentiates it from retrieve-by-id siblings like keep_get.

  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 gives a clear situational trigger: use when you do not know the exact title. It does not explicitly name alternatives or exclusions, but the 'if you do not know its exact title' condition implies when keep_find is preferable to a more exact lookup.

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

• keep_getA
  4.2/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 behavioral burden. It discloses the default selection behavior and that lists include each item's text and checked state, but it does not explicitly confirm the operation is read-only, nor does it explain precedence if both list_title and note_id are supplied.

  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?

  Three compact sentences with no filler. The core action is front-loaded, parameter guidance follows, and the only output detail included is the item text and checked state, which is directly useful.

  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?

  For a simple getter with two optional parameters and an output schema, the description covers the selection mechanism, the default behavior, and list output structure. The main gaps are the lack of an explicit read-only statement and behavior when both parameters are provided, but these are minor for 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?

  Schema description coverage is 0%, so the description must add meaning to the parameters, and it does: list_title is a named label like 'Shopping', and note_id comes from keep_find. It also clarifies the default when both are omitted. It could add what happens if both parameters 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 states a specific verb ('Get') and resource ('one Keep note or checklist'), and clearly distinguishes itself from keep_find by referencing note_id from keep_find. It is immediately obvious what this tool does and how it differs from the sibling reading tool.

  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 tells the agent exactly how to select a note: by list_title or note_id, with a concrete example, and what happens if both are omitted (KEEP_DEFAULT_LIST). It does not explicitly state when not to use this tool, but the sibling names make the alternative operations clear.

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