Server Quality Checklist

Tool Scores

• update_taskC
  2/5.0
  Behavior1/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure, but 'Update a task.' only restates the operation. It does not mention partial-update semantics, null handling, error behavior, or whether the updated task is returned.

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

  Conciseness2/5

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

  The description is short and front-loaded, but it is under-specified rather than concisely informative. It contains no content beyond the tool name, so the brevity does not contribute value.

  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 six parameters and no annotations, a one-sentence description is not sufficiently complete. It omits key invocation context such as whether null clears fields, whether status changes conflict with complete_task, and what happens on invalid task_id.

  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 coverage is 100%, with every parameter described in the input schema, so the baseline of 3 applies. The description itself adds no parameter-level meaning, but the schema adequately documents each optional field.

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

  Purpose2/5

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

  The description 'Update a task.' is a near-verbatim restatement of the tool name/title and provides no additional semantic content. It identifies the resource but does not distinguish this tool from complete_task or create_task beyond the name itself.

  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 given about when to use update_task versus alternatives like create_task, complete_task, or delete_task. The description contains no context about partial field updates or how this differs from completing a task.

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

• delete_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral burden. 'Delete a task' only signals a destructive action; it does not disclose irreversibility, side effects, permissions, soft-delete behavior, or failure semantics.

  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, front-loaded sentence with no filler; every word contributes to the core purpose. It is concise, though it sacrifices valuable behavioral context for brevity.

  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 one-parameter destructive tool with an output schema, 'Delete a task' plus the schema is minimally sufficient for a correct call. However, the absence of any behavioral or usage context leaves meaningful gaps for an agent deciding whether deletion is permanent or appropriate.

  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 coverage is 100% and the single task_id parameter is already described as 'Task UUID'. The description adds no parameter-level meaning, so the schema fully carries the burden; baseline 3 applies.

  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 states a specific verb ('Delete') and a resource ('task'), making the core operation unambiguous and distinct from siblings like create_task or complete_task. However, it adds no scope or nuance beyond the tool name/title, so it does not fully distinguish edge cases like permanent deletion vs. completion.

  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?

  There is no guidance on when to use this tool versus alternatives such as complete_task or update_task. No contexts, prerequisites, or exclusions are provided; the agent must infer usage solely from the name.

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

• list_tasksC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden, but it only says 'List tasks with optional filters.' It does not explicitly state that this is a read-only operation, mention pagination or defaults, or explain how filters interact. The word 'List' is only weak evidence of non-mutating 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 extremely short and front-loaded, with no filler. It could arguably be a bit more informative, but as a one-line summary it is concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The rich input schema and presence of an output schema reduce the burden, and the description explains the core operation. However, it omits high-level behavioral context such as whether all tasks are returned by default, ordering, or how multiple filters interact.

  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 parameter details are already fully documented. The description merely repeats that filters are optional, adding no new meaning beyond the schema.

  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 ('List') and resource ('tasks'), and it mentions filters. It distinguishes itself from sibling CRUD operations by the plural 'list' concept, though it does not explicitly contrast with get_task.

  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?

  There is no guidance about when to use this tool versus get_task or the other siblings, and no mention of prerequisites or scenarios. 'List tasks' only implies the obvious collection-retrieval use case.

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

• create_taskB
  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 of behavioral disclosure. It only states that a task is created, but does not mention side effects, validation constraints, permission requirements, or what happens on duplicate titles or invalid inputs.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. For a simple creation tool whose parameters are fully documented in the schema, this is appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description and schema together give enough information to construct a basic create_task call. However, the lack of usage guidance relative to sibling tools and absence of behavioral context makes it only minimally complete for an agent deciding when and how to invoke it.

  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 all parameters are already documented in the input schema. The description itself adds no extra meaning to the parameters, matching the baseline for full 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 states a clear verb ('Create') and resource ('a new task'), making the core purpose unambiguous. It is distinct from the sibling operations (get, list, update, delete, complete) by naming the create action, though it does not elaborate on scope or behavior.

  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 such as update_task or complete_task. There are no usage contexts, prerequisites, or exclusions mentioned.

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

• get_taskB
  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 of behavioral disclosure. It only restates the operation without explaining what happens when the task is not found, whether the ID must be a valid UUID, or any error/edge-case behavior. This is a meaningful gap for a retrieval tool.

  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 one concise sentence with no filler and appropriate for a simple single-parameter tool. It is not wasteful, though it could add a little context without harming conciseness.

  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 low-complexity get-by-ID tool with an output schema, the description is minimally viable. However, with no annotations and no mention of not-found behavior or response shape, it leaves some operational ambiguity. An agent could call it correctly, but the description is not 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% and the task_id parameter is already documented as 'Task UUID'. The description adds no new semantic detail beyond aligning 'by ID' with the schema. The baseline of 3 applies because the schema fully carries parameter meaning.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Get a task by ID.' It clearly names the retrieval operation and distinguishes itself from sibling tools like list_tasks, create_task, update_task, delete_task, and complete_task. An agent can tell this is the single-item fetch without opening the schema.

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

  Usage Guidelines3/5

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

  The intended use is implied by 'by ID' and the sibling set: use when you need one specific task rather than listing all tasks. However, the description does not explicitly state when not to use it or name alternatives. Usage guidance is present only by inference.

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

• complete_taskA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It states the outcome (marking the task completed) but does not mention idempotency, behavior on already-completed tasks, invalid task IDs, or whether this is a direct status update versus a more comprehensive mutation. For a state-changing tool, this is a notable 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 five-word sentence that directly states the tool's purpose with zero redundancy. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, has one well-documented parameter, and includes an output schema, so the description need not explain return values. However, the lack of behavioral caveats or guidance on when to use this instead of update_task leaves a small but real completeness gap for an agent making a routing decision.

  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 fully documents the only parameter (task_id as a Task UUID), and the description adds no additional meaning beyond what is already in the schema. With 100% schema description coverage, the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('mark') and a clear resource ('a task') and conveys the exact state transition to completed. It is immediately distinguishable from sibling tools like create_task, get_task, list_tasks, and delete_task, and even from update_task by signaling a focused finalization action.

  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 action itself is obvious, but the description gives no guidance on when to prefer this over update_task, which could also modify task state. It provides no explicit conditions, exclusions, or prerequisites such as the task needing to exist or be in an open state.

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