Server Quality Checklist

Tool Scores

• update_todoC
  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 full burden but only states the basic action of updating fields. It doesn't disclose behavioral traits such as whether updates are idempotent, what permissions are required, how errors are handled, or the impact on existing data. The mention of 'existing todo item' implies mutation but lacks depth.

  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. It could be slightly more structured by grouping fields or adding brief context, but it avoids redundancy and wastes no words.

  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 (9 parameters, mutation operation) and no annotations, the description is incomplete—it lacks behavioral context, usage guidelines, and error handling. However, the presence of an output schema reduces the need to explain return values, and the schema covers parameters well, making it minimally adequate but with clear gaps.

  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 fully documents all 9 parameters. The description adds minimal value by listing some updatable fields (text, completed, dueDate, role) but omits others like archived, completionNotes, and classification, and doesn't clarify semantics beyond what the schema provides.

  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 ('Update fields') and resource ('existing todo item'), and lists specific fields that can be updated. It distinguishes from siblings like create_todo (new items) and delete_todo (removal), though not explicitly. However, it doesn't fully differentiate from complete_todo which might overlap with updating the completed field.

  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 complete_todo or create_todo. It mentions updating fields but doesn't specify prerequisites (e.g., requires an existing todo ID) or contextual cues (e.g., use for partial updates vs. complete_todo for marking as done).

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

• complete_todoB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action ('Mark as completed'). It doesn't disclose behavioral traits such as permissions needed, whether completion is reversible, error handling, or how it interacts with other tools. This is inadequate 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 a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it highly efficient.

  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 has an output schema (which handles return values) and 100% schema coverage, the description's minimal content is somewhat acceptable. However, as a mutation tool with no annotations, it should provide more behavioral context to be complete, leaving gaps in understanding its full impact.

  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 fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining parameter interactions or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Mark as completed') and target ('an existing todo item'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'update_todo' which might also handle completion status changes, so it doesn't reach the highest 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 like 'update_todo' or 'delete_todo'. It mentions 'existing todo item' but doesn't specify prerequisites or exclusions, leaving usage context implied at best.

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

• create_todoB
  3.1/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 mentions adding an item but fails to describe key traits like whether this is a write operation (implied but not stated), authentication needs, error handling, or what the output contains (though an output schema exists). 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy 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?

  Given the tool's complexity (6 parameters, mutation operation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete behavioral transparency, it lacks details on permissions, side effects, or error cases, which are important for a creation 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?

  Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds no additional meaning or context beyond what's in the schema, such as explaining parameter interactions or usage examples. This meets the baseline for high schema 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 action ('Add a new todo/task item') and target ('to the user's store'), which is specific and unambiguous. However, it doesn't differentiate this tool from its sibling 'update_todo' or explain why one would create versus update, keeping it from 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 like 'update_todo' or 'complete_todo', nor does it mention prerequisites or contextual cues. It merely states what the tool does without indicating appropriate scenarios.

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

• list_todosB
  3.1/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 mentions 'list' and 'optional filters' but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, pagination behavior beyond the limit parameter, rate limits, or what happens when no filters are applied. The description is minimal and doesn't compensate for missing annotations.

  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. It's front-loaded with the core action and resource, with no wasted words 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 6 parameters, no annotations, but with 100% schema coverage and an output schema (which handles return values), the description is minimally adequate. However, for a tool with multiple siblings and no annotations, it should provide more context about usage scenarios and behavioral traits to be 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?

  Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond mentioning 'optional filters' generically, which is already implied by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('List') and resource ('todo items from the user's todos store') with optional filtering. It distinguishes from siblings like create_todo or delete_todo by focusing on retrieval, but doesn't explicitly differentiate from other potential list operations (though none exist in siblings).

  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 on when to use this tool versus alternatives is provided. The description mentions optional filters but doesn't specify scenarios for using filters or how this tool relates to other todo operations like complete_todo or update_todo.

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

• delete_todoA
  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 destructive nature ('Delete') but does not mention behavioral traits like permissions required, whether deletion is permanent or reversible, error handling, or confirmation prompts. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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 a single, efficient sentence that front-loads the key action and resource. It contains zero waste, making it appropriately sized and easy to parse for an AI agent.

  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 complexity (simple deletion with one parameter), high schema coverage (100%), and presence of an output schema (which handles return values), the description is mostly complete. However, it lacks details on behavioral aspects like permissions or reversibility, which are important for a destructive operation, slightly reducing 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%, so the schema already documents the 'id' parameter fully. The description adds no additional meaning beyond what the schema provides (e.g., format constraints or examples). With high schema coverage, the baseline is 3, as the description does not compensate but also does not detract.

  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'), resource ('a todo item'), and scope ('from the user's Firestore 'todos' collection by id'), distinguishing it from sibling tools like 'create_todo' or 'update_todo'. It precisely defines what the tool does without ambiguity.

  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 by specifying deletion by ID, but does not explicitly state when to use this tool versus alternatives (e.g., 'complete_todo' for marking as done) or any prerequisites. It provides basic context but lacks explicit guidance on exclusions or comparisons with siblings.

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