Server Quality Checklist

Tool Scores

• create_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 for behavioral disclosure. It mentions 'validation' but doesn't specify what validation entails (e.g., format checks, uniqueness, permissions). For a creation tool with mutation implications, this lack of detail about behavior, error handling, or side effects 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, efficient sentence that directly states the tool's function. It's front-loaded with the core purpose and avoids unnecessary 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?

  For a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on what happens after creation (e.g., returns an ID, error responses), validation specifics, and how it fits with sibling tools, leaving critical context gaps for effective use.

  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%, providing detailed documentation for all parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline but doesn't enhance understanding of the inputs.

  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 ('Create a new todo item') and resource ('todo item'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_todo' or specify what kind of validation occurs, which prevents 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 'list_todos'. There's no mention of prerequisites, context for creation, or comparison with sibling tools, leaving usage decisions ambiguous.

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

• delete_todoC
  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 full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, it doesn't specify whether deletion is permanent or reversible, what permissions are required, whether it affects related data, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.

  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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's simple function.

  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 destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks critical context about behavioral consequences, error handling, return values, and differentiation from sibling tools, leaving significant gaps for an agent to safely and correctly invoke this 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% with the single parameter 'id' documented as 'UUID of the todo to delete'. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for adequate but unenriched parameter documentation.

  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 ('Delete') and target resource ('a todo item'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_todo' which could also modify or remove todos, nor does it specify whether this is a soft or hard deletion.

  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. With siblings like 'update_todo' that might handle status changes to 'completed' instead of deletion, and 'get_todo'/'list_todos' for verification, there's no indication of appropriate contexts, prerequisites, or exclusions for this destructive operation.

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

• get_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. It doesn't disclose behavioral traits such as error handling (e.g., what happens if the ID is invalid), performance aspects (e.g., speed, rate limits), or response format. This leaves gaps for an AI agent to understand operational context.

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

  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 simplicity (one parameter, no output schema, no annotations), the description is minimal but incomplete. It lacks context on usage scenarios, error cases, or output expectations, which could hinder an AI agent's ability to invoke it correctly without additional inference.

  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 'id' fully documented as a UUID. The description adds minimal value beyond the schema by implying the parameter is for retrieval, but doesn't provide additional context like format examples or constraints. 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 ('Get') and resource ('a specific todo by ID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_todos' or 'search_todos' beyond the 'by ID' specification, which is implied but not contrasted directly.

  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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid todo ID), exclusions, or compare it to siblings like 'list_todos' for multiple todos or 'search_todos' for queries. The description assumes context without stating it.

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

• list_todosC
  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. While 'List todos' implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what format the results come in, or how pagination works beyond mentioning it exists.

  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 at just 6 words, front-loading the core purpose ('List todos') and efficiently mentioning key capabilities ('with filtering and pagination'). Every word earns its place 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?

  For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how results are structured, or provide context about the filtering logic beyond what's in the schema. The agent would need to guess about the output format and behavioral characteristics.

  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?

  With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond confirming filtering and pagination capabilities, which the schema already details through parameter descriptions and enums. 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 ('List todos') and mentions key capabilities ('with filtering and pagination'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'search_todos', which appears to be a similar listing/search tool.

  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 'search_todos' or 'get_todo'. It mentions filtering capabilities but doesn't specify when this filtering approach is preferred over other tools in the server.

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

• search_todosC
  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 for behavioral disclosure but offers minimal information. It doesn't describe whether this is a read-only operation, how results are returned (format, pagination), performance characteristics, or error conditions. The description only states what the tool does at a high level without operational details.

  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 at just 5 words with zero wasted language. It's front-loaded with the core functionality and uses efficient phrasing. Every word serves a purpose in conveying the tool's basic function.

  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 search tool with 3 parameters and no output schema, the description is inadequate. It doesn't explain what constitutes a match (exact, partial, case-sensitive), how multiple parameters interact, what the return format looks like, or any limitations. The description provides only the most basic functional statement without necessary operational 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 description mentions searching by title or description, which aligns with the 'searchTerm' parameter but doesn't add meaningful context beyond what the schema already provides. With 100% schema description coverage that includes clear parameter descriptions and enum values, the description adds minimal value. The baseline of 3 is appropriate when 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 tool's purpose as searching todos by title or description, which is a specific verb+resource combination. However, it doesn't distinguish this tool from the sibling 'list_todos' tool, which might offer different filtering capabilities or scope.

  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 'list_todos' or 'get_todo'. There's no mention of prerequisites, performance considerations, or appropriate contexts for choosing this search functionality over other todo-related tools.

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

• update_todoC
  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 full burden for behavioral disclosure. 'Update an existing todo item' implies a mutation operation but reveals nothing about permissions, side effects, error handling, or response format. It doesn't indicate whether all fields are optional (beyond required 'id'), if updates are atomic, or what happens with invalid data. 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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place by establishing the tool's fundamental purpose without unnecessary elaboration or redundancy.

  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 (mutation with 6 parameters), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't address behavioral aspects like error conditions, idempotency, or response structure, nor does it clarify parameter interactions (e.g., partial updates). For a mutation tool in this context, more comprehensive guidance is needed to support reliable agent invocation.

  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 well-documented in the schema (e.g., 'id' as UUID, 'priority' with enum values). The description adds no parameter-specific information beyond the generic 'update' context, so it doesn't enhance understanding of individual parameters. This meets the baseline of 3 for high schema coverage, but doesn't compensate with additional semantic context.

  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') and resource ('an existing todo item'), making the purpose immediately understandable. It distinguishes from siblings like 'create_todo' (new items) and 'delete_todo' (removal), though it doesn't explicitly differentiate from other update-like operations since none exist in the sibling list. The verb+resource combination is specific but lacks nuance about what aspects can be updated.

  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 todo ID), contrast with 'create_todo' for new items, or specify scenarios where partial updates are allowed. With siblings like 'get_todo' and 'list_todos' available, the absence of usage context leaves the agent to infer appropriate application.

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