Server Quality Checklist

Tool Scores

• cozi_add_itemC
  2.9/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 item 'will be added to the specified list,' which implies a write operation but doesn't cover permissions, error handling, or response format. For a mutation tool without annotations, this leaves significant gaps in understanding how it behaves beyond the basic action.

  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, efficient sentence that front-loads the core action ('Add a new item to a Cozi list') and adds a clarifying detail. There's no wasted verbiage, and it's appropriately sized for a simple tool. However, it could be slightly more structured by explicitly separating purpose from constraints.

  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 the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits like authentication needs, error cases, or what the response contains. For a tool that modifies data, this minimal description doesn't provide enough context for safe and effective use by an AI agent.

  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 both parameters (listId and text) clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 action ('Add a new item') and resource ('to a Cozi list'), making the purpose unambiguous. It distinguishes this from sibling tools like cozi_create_list or cozi_edit_item by focusing on item addition rather than list creation or item modification. However, it doesn't explicitly differentiate from cozi_mark_item_complete/incomplete, which are also item-related but for status changes.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing list), exclusions, or comparisons to siblings like cozi_edit_item for modifying items or cozi_remove_item for deletion. Usage is implied through the action but lacks explicit context for selection.

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

• cozi_create_listC
  2.9/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 states the tool creates a list but doesn't disclose behavioral traits such as whether it requires specific permissions, what happens on success/failure, if it's idempotent, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

  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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly with zero waste.

  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 the tool's complexity as a mutation operation (creating a list) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, error handling, or what the tool returns, which are crucial for an AI agent to use it correctly in context.

  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 clear descriptions for both parameters (title and type, including enum values). The description adds no additional meaning beyond the schema, such as examples or constraints. Baseline 3 is appropriate as the schema adequately documents parameters without extra value from the description.

  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 verb ('Create') and resource ('new Cozi list'), specifying it can be either a shopping or todo list. However, it doesn't explicitly differentiate from siblings like cozi_add_item (which adds items to existing lists) or cozi_get_list (which retrieves lists), leaving some ambiguity about when to use this versus other list-related tools.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication), when not to use it (e.g., for updating existing lists), or direct alternatives among siblings like cozi_edit_item for modifying lists. Usage is implied but not explicitly stated.

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

• cozi_edit_itemC
  2.9/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 tool edits text but does not cover critical aspects such as whether this requires authentication, if it's a destructive mutation, error handling, or rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

  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, direct sentence that efficiently conveys the core action without any fluff or redundancy. It is front-loaded with the key information, making it highly concise and well-structured for quick 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?

  Given the complexity of a mutation tool (editing an item) with no annotations and no output schema, the description is insufficient. It lacks details on permissions, side effects, response format, or error conditions, which are crucial for safe and effective use, leaving the agent with incomplete context.

  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 has 100% description coverage, clearly documenting all three parameters (itemId, listId, text) with their purposes. The description adds no additional semantic details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for adequate but not enhanced parameter understanding.

  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 action ('Edit') and resource ('text of an existing item in a Cozi list'), making the purpose specific and understandable. However, it does not explicitly differentiate from siblings like 'cozi_add_item' or 'cozi_remove_item', which involve adding or removing items rather than editing text, so it falls short of a perfect score.

  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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing item), exclusions, or comparisons to siblings like 'cozi_mark_item_complete', leaving the agent to infer usage context without explicit help.

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

• cozi_mark_item_completeC
  2.9/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 action ('checks off') but doesn't mention whether this is reversible, if it requires specific permissions, what happens to the item after marking (e.g., hidden or archived), or any side effects. This leaves significant gaps for a mutation tool.

  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 with two short, direct sentences that communicate the core action without any fluff. It's front-loaded and every word serves a clear purpose, making it efficient and easy to parse.

  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?

  For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'complete/done' means in this context, whether the change is permanent, what the expected response looks like, or how it integrates with other tools. Given the complexity and lack of structured data, more context is needed.

  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 description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline for adequate but not exceptional coverage.

  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 verb ('mark as complete/done', 'checks off') and resource ('item in a Cozi list'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'cozi_mark_item_incomplete' beyond the opposite state, missing an opportunity for clearer sibling distinction.

  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 provides no guidance on when to use this tool versus alternatives like 'cozi_edit_item' or 'cozi_remove_item'. It mentions the action but lacks context about prerequisites, typical workflows, or when this is the appropriate choice among sibling tools.

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

• cozi_get_listB
  3.2/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 mentions retrieving details but doesn't disclose behavioral traits such as whether this is a read-only operation, potential error conditions (e.g., invalid ID), or response format. This is inadequate for a tool with no annotation coverage, leaving significant gaps in understanding how it behaves.

  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 appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the purpose, and the second provides usage guidance, with no wasted words, making it highly concise and well-structured.

  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 the complexity of retrieving a list with items, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'full details' includes, how items are returned, or any behavioral aspects, making it insufficient for an agent to fully understand the tool's operation and output.

  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 description coverage is 100%, with the parameter 'listId' documented as 'The ID of the list to retrieve'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without extra value from the description.

  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 verb 'Get' and resource 'a specific Cozi list by ID with all its items', specifying what the tool does. It distinguishes from the sibling 'cozi_get_lists' by focusing on a single list rather than multiple lists. However, it doesn't explicitly mention the sibling name for comparison, keeping it at 4 instead of 5.

  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 with 'Use this to see the full details of a single list', suggesting it's for detailed viewing. However, it doesn't explicitly state when to use this versus alternatives like 'cozi_get_lists' for multiple lists or provide exclusions, leaving the guidance somewhat vague.

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

• cozi_get_listsB
  3.3/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 full burden. It states the tool retrieves data (implied read-only) and returns 'complete list of all lists including item counts and contents', but lacks details on permissions, rate limits, pagination, error conditions, or whether it returns archived lists. For a read operation with zero annotation coverage, this is insufficient.

  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 two concise sentences that efficiently convey the core functionality. It is front-loaded with the main purpose, though it could be slightly more structured by separating scope from return details.

  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 zero parameters, no annotations, and no output schema, the description adequately covers the basic purpose but lacks sufficient behavioral context (e.g., response format, error handling). For a read-all tool, it should ideally specify output structure or limitations, but the absence of an output schema increases the burden on the description.

  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 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for zero-parameter tools as no compensation is needed.

  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 verb ('Get') and resource ('Cozi lists'), specifying that it retrieves both shopping and todo lists with their items. It distinguishes from 'cozi_get_list' (singular) by indicating it returns 'all lists', but doesn't explicitly contrast with other siblings beyond this scope difference.

  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 when needing all lists with items, but provides no explicit guidance on when to use this versus alternatives like 'cozi_get_list' (singular) or other list/item manipulation tools. No exclusions or prerequisites are mentioned.

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

• cozi_mark_item_incompleteA
  3.7/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 of behavioral disclosure. While it states the action ('mark incomplete') and effect ('unchecks the item'), it doesn't mention permissions required, whether the change is reversible, error conditions, or what happens if the item is already incomplete. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 with two short sentences that directly communicate the tool's purpose and effect. Every word earns its place, with no redundant information or unnecessary elaboration.

  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 this is a mutation tool with no annotations and no output schema, the description provides basic purpose but lacks important contextual details about permissions, side effects, error handling, and response format. The 100% schema coverage helps with parameters, but overall completeness is only adequate for this simple tool.

  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 description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional parameter semantics beyond what's already in the schema (itemId and listId are self-explanatory). This meets the baseline of 3 when schema coverage is high.

  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 specific action ('Mark an item as incomplete/not done') and resource ('in a Cozi list'), with the additional clarifying detail 'This unchecks the item.' It distinguishes from the sibling tool 'cozi_mark_item_complete' by specifying the opposite state change.

  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 specifying it's for marking items incomplete in Cozi lists, but it doesn't explicitly state when to use this tool versus alternatives like 'cozi_edit_item' or 'cozi_remove_item'. The naming convention with 'cozi_mark_item_complete' as a sibling provides some implicit differentiation, but no explicit guidance is given.

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

• cozi_remove_itemA
  3.7/5.0
  Behavior4/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 explicitly states that the deletion is 'permanent,' which is crucial context beyond the basic action. However, it doesn't cover other behavioral aspects like error conditions, permissions required, or response 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?

  The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part of the text earns its place by clarifying the action and its permanence.

  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 complexity (a destructive operation with 2 parameters) and no annotations or output schema, the description is minimally complete. It covers the permanent nature of the action but lacks details on error handling, permissions, or return values, leaving gaps for an AI agent.

  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%, so the schema already documents both parameters (itemId and listId) adequately. The description adds no additional meaning or context about the parameters beyond what the schema provides, such as format examples or relationship details.

  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 specific action ('Remove/delete') and resource ('an item from a Cozi list'), distinguishing it from siblings like cozi_mark_item_complete or cozi_edit_item. It uses precise verbs that indicate a destructive operation rather than modification.

  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 provides no guidance on when to use this tool versus alternatives like cozi_edit_item or cozi_mark_item_complete. It doesn't mention prerequisites, such as needing to retrieve item IDs first, or exclusions, such as not using it for temporary removal.

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

• cozi_delete_listA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a destructive operation ('permanently removes') and specifies scope ('list and all its items'). However, it doesn't mention permissions, error conditions, or confirmation requirements, leaving some 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?

  Two sentences, zero waste. The first sentence states the core action, and the second adds critical behavioral context (permanent removal). Every word earns its place, and it's front-loaded with essential 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?

  For a destructive tool with no annotations and no output schema, the description is adequate but has clear gaps. It covers the destructive nature and scope but lacks details on permissions, response format, or error handling. Given the complexity, it's minimally viable but incomplete.

  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%, so the schema already documents the listId parameter fully. The description adds no additional meaning beyond implying the ID is used for deletion, which is redundant with the schema. Baseline 3 is appropriate when schema does the heavy lifting.

  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 specific action ('Delete a Cozi list by ID') and resource ('list'), distinguishing it from siblings like cozi_remove_item (which removes items) and cozi_get_list (which retrieves lists). It provides a complete verb+resource+identifier combination.

  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 specifying 'by ID' and mentioning permanent removal, but it doesn't explicitly state when to use this vs. alternatives like cozi_remove_item (for items) or cozi_get_list (for viewing). It provides clear intent but lacks explicit sibling differentiation.

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