Server Quality Checklist

Tool Scores

• updateTaskC
  2.6/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. 'Update an existing task' implies a mutation operation, but it doesn't specify permissions needed, whether changes are reversible, rate limits, or what happens to unspecified fields. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with just three words, which is efficient and front-loaded. However, it's arguably too brief for a mutation tool with no annotations, as it leaves critical behavioral aspects unspecified, slightly reducing its effectiveness.

  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 this is a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. The agent lacks sufficient context to use this tool safely and effectively compared to siblings.

  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 all 5 parameters with their types, optionality, and enum values. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update an existing task' clearly states the verb (update) and resource (task), but it's quite generic and doesn't differentiate from sibling tools like 'completeTask' or 'startTask' which also modify tasks. It specifies 'existing' which distinguishes from 'createTask', but lacks specificity about what aspects can be updated compared to other mutation 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?

  No explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, when to choose this over 'completeTask' or 'startTask', or any constraints. The agent must infer usage from the tool name and schema alone.

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

• deleteTaskC
  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 'Delete' implies a destructive mutation, the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., cascading deletions). For a destructive operation 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, achieving optimal conciseness for a simple tool.

  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 incomplete. It lacks critical context: behavioral traits (permanence, permissions), usage guidelines versus siblings, and expected outcomes. The high schema coverage doesn't compensate for these gaps, making it inadequate for safe and effective agent 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%, with the single parameter 'id' documented as 'Task ID'. The description adds no additional semantic context beyond what the schema provides (e.g., format examples, validation rules, or where to find the ID). Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is added.

  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 resource ('a task by its ID'), making the purpose immediately understandable. It distinguishes from siblings like 'completeTask' or 'updateTask' by specifying deletion. However, it doesn't explicitly mention what 'task' refers to in the system context, 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 'completeTask' or 'updateTask'. There's no mention of prerequisites (e.g., task must exist), consequences (e.g., permanent deletion), or when deletion is appropriate versus other operations. This leaves the agent with insufficient context for optimal tool selection.

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

• completeTaskB
  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 the full burden. It mentions 'complete a task and get the next task,' implying a mutation (completion) and a read operation (getting next task), but doesn't disclose behavioral traits like whether completion is irreversible, what permissions are needed, if it triggers side effects, or how the next task is determined. This leaves critical 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 two sentences, front-loaded with the core purpose and followed by a usage tip. Every sentence earns its place by providing essential information without waste, 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 a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on what 'complete' means behaviorally, how the next task is returned, error conditions, or output format. For a tool that modifies state and provides a result, this leaves significant 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?

  The input schema has 100% description coverage, with 'id' and 'resolution' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples or constraints for 'resolution'), so it meets the baseline of 3 for high schema coverage without compensating value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool 'Complete[s] a task and get[s] the next task to execute,' which provides a clear verb ('complete') and resource ('task'), but it's vague about what 'complete' entails (e.g., marking as done, resolving, closing) and doesn't differentiate from siblings like 'updateTask' or 'deleteTask' that might also affect task status. It's not tautological but lacks specificity.

  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 explicitly states 'To start the next task, execute `startTask`,' providing a clear alternative and context for usage. However, it doesn't specify when to use this tool versus other siblings like 'updateTask' for partial completions or 'deleteTask' for removal, nor does it mention prerequisites (e.g., task must be in progress). The guidance is helpful but incomplete.

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

• getTaskB
  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 for behavioral disclosure. While 'Get' implies a read operation, it doesn't explicitly state whether this requires authentication, what happens if the ID doesn't exist (error behavior), or any rate limits. For a 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 perfectly concise at just 5 words ('Get a task by its ID'). It's front-loaded with the core purpose and contains zero wasted words. Every element of the description earns its place by communicating essential information efficiently.

  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 read operation with 1 parameter and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it doesn't describe what the tool returns (task object structure) or error conditions. The description meets basic requirements but leaves gaps that could hinder effective tool selection and 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 the single parameter 'id' clearly documented as 'Task ID' in the schema. The description adds no additional parameter information beyond what the schema already provides. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 action ('Get') and resource ('a task by its ID'), making the purpose immediately understandable. It distinguishes this from siblings like listTasks (which retrieves multiple tasks) and createTask/updateTask (which modify tasks). However, it doesn't explicitly mention that this retrieves a single task, which would make it fully specific.

  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 that this is for retrieving a specific known task ID, while listTasks is for browsing/searching tasks, or that it should be used instead of siblings like updateTask when only read access is needed. No exclusions or prerequisites are stated.

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

• startTaskB
  3.4/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 the status change to 'in_progress', which implies mutation, but fails to disclose critical behavioral traits like required permissions, whether the change is reversible, error conditions (e.g., invalid ID), or response format. This leaves significant gaps for an agent to understand 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and structured as a two-step list, making it efficient and easy to parse. However, the second sentence repeats the tool name ('completeTask') without adding new value, slightly reducing conciseness. Overall, it's well-structured but not perfectly tight.

  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 mutation operation with no annotations and no output schema), the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral aspects like permissions, errors, or return values. This makes it functional but incomplete for safe and effective use by an 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?

  The input schema has 100% description coverage, with the 'id' parameter documented as 'Task ID'. The description adds no additional meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3, which is appropriate here.

  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 ('Start a task') and specifies the effect ('change status to in_progress'), which distinguishes it from siblings like 'completeTask' or 'updateTask'. However, it doesn't explicitly mention what resource it operates on (e.g., a task management system), making it slightly less specific than a perfect 5.

  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 provides explicit guidance on when to use this tool ('Run this tool to start the task') and references an alternative ('call the `completeTask` tool to complete the task'), which helps differentiate it from siblings. It lacks explicit exclusions or prerequisites, such as when not to use it (e.g., if the task is already started), preventing a score of 5.

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

• listTasksA
  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 carries the full burden of behavioral disclosure. It describes the hierarchical nature of the data structure and the filtering behavior, which is valuable. However, it doesn't mention pagination, rate limits, authentication requirements, or what format the returned tasks will have (though there's no output schema). The description adds meaningful context but leaves gaps in behavioral understanding.

  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 perfectly concise - two sentences that efficiently convey purpose, parameter behavior, and default behavior. Every word earns its place with zero redundancy or unnecessary elaboration. The structure is front-loaded with the core purpose followed by parameter specifics.

  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 read operation with one optional parameter and 100% schema coverage, the description provides adequate context about the hierarchical nature and filtering behavior. However, with no annotations and no output schema, it doesn't address important behavioral aspects like pagination, rate limits, or return format. The description is complete enough for basic usage but lacks depth for production scenarios.

  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 fully documents the single optional parameter. The description adds marginal value by reinforcing the parent-child relationship context and clarifying that omitting parentId returns root tasks, but doesn't provide additional semantic meaning beyond what's in the schema description field.

  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 verb ('List') and resource ('tasks from hierarchical structure'), and distinguishes this tool from siblings by specifying it's for listing rather than creating, updating, or deleting tasks. The mention of hierarchical structure and parent-child relationships provides specific context beyond a generic list operation.

  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 provides clear context about when to use this tool (to list tasks, optionally filtered by parentId) and what happens with/without the parameter. However, it doesn't explicitly mention when to use alternatives like 'getTask' for single task retrieval or 'search' operations if available, though the sibling tool names suggest this is the primary listing tool.

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

• createTaskA
  4.2/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 explaining the hierarchical structure, ordering behavior, and mandatory workflow sequence. It doesn't mention permissions, rate limits, or error conditions, but provides substantial behavioral context beyond basic creation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately front-loaded with the core purpose, but the lengthy workflow explanation (6 steps) contains redundant information about sibling tools that belongs in general documentation rather than this specific tool's description. Some sentences don't directly earn their place in this tool's definition.

  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 creation tool with no annotations and no output schema, the description provides good context about the hierarchical system and workflow integration. It could better explain what happens on creation failure or the return format, but covers the essential behavioral expectations given the complexity.

  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 all 7 parameters thoroughly. The description mentions parentId and insertIndex semantics but doesn't add significant meaning beyond what the schema provides. The baseline of 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 ('Create a new task') and resource ('task'), distinguishing it from siblings like updateTask or deleteTask. It explicitly mentions optional parent and index positioning, which differentiates it from simple creation tools.

  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?

  The description provides explicit workflow guidance: 'you MUST always run this tool first' and outlines a complete sequence involving startTask and completeTask. It distinguishes when to use this tool versus alternatives by positioning it as the initial step in task management.

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