Server Quality Checklist

Tool Scores

• add_noteC
  2.7/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 lacks critical behavioral details. It mentions notes are displayed in task progress and can be referenced, but doesn't cover permissions, rate limits, whether notes are editable/deletable, or what happens on success/failure. 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.

  Conciseness4/5

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

  The description is appropriately concise with two sentences that avoid redundancy. The first sentence states the purpose, and the second provides context about display and reference, though it could be more front-loaded with key details.

  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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameters, behavioral traits, error handling, and output, leaving significant gaps for an AI agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate but adds no parameter-specific information. It doesn't explain what 'requestId', 'title', or 'content' represent, their formats, or constraints. The mention of 'important information about the project' vaguely relates to 'content' but is insufficient.

  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 note') and target resource ('to a request'), specifying that notes contain project information like user preferences or guidelines. It distinguishes from siblings like 'delete_note' and 'update_note' by focusing on creation, but could be more explicit about differentiation.

  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_note' or 'add_tasks_to_request', nor does it mention prerequisites like needing an existing request. It only implies usage through context about note content and display.

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

• add_tasks_to_requestC
  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 that 'A progress table will be displayed' as an outcome, which adds some context. However, it lacks critical details: whether this is a mutation (implied but not stated), what permissions are needed, if tasks are appended or replace existing ones, or error handling for invalid requestIds.

  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 appropriately sized with three sentences that are front-loaded: the first states the core purpose, the second adds context about task structure, and the third describes an outcome. No wasted words, though it could be slightly more structured for clarity.

  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 (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on return values (beyond mentioning a progress table), error conditions, side effects, or how this tool fits into the broader workflow with sibling tools.

  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 0%, so the description must compensate. It mentions 'tasks can include subtasks and dependencies', which clarifies the structure of the 'tasks' array parameter beyond the schema. However, it doesn't explain 'requestId' (e.g., format or source) or provide examples, leaving gaps in 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 ('Add new tasks') and target resource ('to an existing request'), making the purpose evident. However, it doesn't explicitly differentiate this from similar sibling tools like 'add_subtasks' or 'update_task', which would be needed for 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 mentions 'extending a request with additional tasks' but provides no explicit guidance on when to use this tool versus alternatives like 'add_subtasks' (for adding subtasks to existing tasks) or 'update_task' (for modifying existing tasks). No prerequisites or exclusions are stated.

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

• delete_noteC
  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 offers minimal behavioral insight. It states the action is 'Delete', implying a destructive mutation, but doesn't disclose critical details like whether deletion is permanent, requires specific permissions, or has side effects (e.g., affecting request status). This leaves significant gaps for a tool that alters data.

  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 highly concise and front-loaded, with two sentences that directly state the purpose and parameters without any fluff. Every word serves a functional role, making it efficient for an agent 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 complexity (a destructive operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral risks, parameter details, or expected outcomes, leaving the agent with insufficient information to use the tool safely and effectively.

  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 0%, so the description must compensate but only partially does. It names the parameters ('requestId' and 'noteId') and indicates they identify the note to delete, adding basic context. However, it doesn't explain what these IDs represent, their format, or where to obtain them, leaving the schema's undocumented parameters inadequately clarified.

  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 note from a request'), making the purpose immediately understandable. It distinguishes itself from siblings like 'update_note' or 'add_note' by specifying deletion. However, it doesn't explicitly differentiate from other deletion tools like 'delete_subtask' or 'delete_task', which keeps 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. It doesn't mention prerequisites (e.g., note must exist), exclusions, or compare with siblings like 'update_note' for modification instead of deletion. The agent must infer usage from context alone.

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

• mark_subtask_doneC
  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 mentions that 'A progress table will be displayed showing the updated status of all tasks and subtasks', which adds some behavioral context about output. However, it lacks details on permissions, side effects (e.g., if this is irreversible), or error handling, which are important 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.

  Conciseness4/5

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

  The description is appropriately sized with three sentences. The first sentence states the purpose and parameters, the second describes the output, and the third provides a prerequisite. It is front-loaded with the core action, though the third sentence could be more integrated.

  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 no annotations, 0% schema coverage, no output schema, and 3 parameters for a mutation tool, the description is incomplete. It mentions output behavior but lacks details on return values, error conditions, or dependencies, leaving gaps for an AI agent to understand full usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It lists the parameters ('requestId', 'taskId', 'subtaskId') but does not explain their meaning, format, or relationships. This adds minimal value beyond the schema, which already specifies the required parameters without descriptions.

  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 a subtask as done') and specifies the required parameters ('requestId', 'taskId', 'subtaskId'), which distinguishes it from siblings like 'mark_task_done' or 'update_subtask'. However, it does not explicitly differentiate from all siblings, such as 'delete_subtask', which also operates on subtasks.

  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 stating 'All subtasks must be completed before a task can be marked as done', which suggests a prerequisite but does not explicitly say when to use this tool versus alternatives like 'mark_task_done' or 'update_subtask'. No exclusions or clear alternatives are provided.

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

• update_noteC
  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 mentions the tool updates an existing note, implying mutation, but lacks details on permissions, whether updates are reversible, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

  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 front-loaded with the core purpose in the first sentence, followed by parameter guidance. Both sentences earn their place by clarifying the action and inputs, with no wasted words. It's appropriately sized for a simple update 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?

  Given the tool's complexity (mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It covers basic purpose and parameters but misses behavioral details like side effects, permissions, or return values, which are critical for safe 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 0%, so the description must compensate. It lists all four parameters ('requestId', 'noteId', 'title', 'content') and specifies required vs. optional, adding value beyond the bare schema. However, it doesn't explain parameter meanings (e.g., what 'requestId' refers to) or formats, leaving gaps.

  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 ('Update') and resource ('an existing note's title or content'), making the purpose evident. It distinguishes from siblings like 'add_note' (creation) and 'delete_note' (deletion), but doesn't explicitly differentiate from other update tools like 'update_subtask' or 'update_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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing note), compare to siblings like 'add_note' or 'delete_note', or specify context for updates. 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.

• update_taskC
  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 mentions that a 'progress table will be displayed,' hinting at output behavior, but lacks details on permissions, error handling, or mutation effects (e.g., whether updates are reversible). This is a significant gap for a mutation tool with zero annotation coverage.

  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 constraint in the first sentence, followed by output behavior. It uses two sentences efficiently with minimal waste, though it could be slightly more structured by separating constraints from output details.

  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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers some aspects (purpose, constraint, output hint) but misses critical details like parameter meanings, error scenarios, and full behavioral context, making it inadequate for reliable agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'title and/or description,' which maps to two of the four parameters (title, description), but doesn't explain 'requestId' or 'taskId' (the required ones). This partial coverage leaves key parameters unexplained, failing to fully address the schema gap.

  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 task's title and/or description'), making the purpose evident. However, it doesn't explicitly differentiate this from sibling tools like 'update_note' or 'update_subtask', which share similar naming patterns but target different resources.

  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 provides some usage context by stating 'Only uncompleted tasks can be updated,' which implies a constraint on when to use this tool. However, it doesn't offer explicit guidance on when to choose this over alternatives like 'mark_task_done' or 'delete_task,' nor does it mention prerequisites beyond the constraint.

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

• add_subtasksB
  3.2/5.0
  Behavior3/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 that this is a write operation ('Add'), mentions the outcome ('A progress table will be displayed showing the updated task with its subtasks'), and explains the relationship between subtasks and tasks ('All subtasks must be completed before a task can be marked as done'). However, it lacks details on permissions, error conditions, or whether this operation is idempotent, which are important 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.

  Conciseness4/5

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

  The description is appropriately sized with four sentences that are front-loaded: the first sentence states the purpose and parameters, the second explains subtasks, the third adds context about task completion, and the fourth describes the output. There's minimal waste, though the second sentence could be slightly more 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?

  Given the complexity (a mutation tool with 3 parameters, no annotations, and no output schema), the description is moderately complete. It covers the purpose, parameters at a high level, behavioral context (subtask-task relationship and output display), but lacks details on parameter formats, error handling, and exact return values. For a tool that modifies data without annotations, this leaves gaps in operational understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It lists the required parameters ('requestId', 'taskId', and 'subtasks array') and explains that subtasks have 'title' and 'description' fields, which adds meaning beyond the schema. However, it doesn't clarify what 'requestId' and 'taskId' represent (e.g., their format or how to obtain them), leaving key parameters partially undocumented.

  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 subtasks') and target resource ('to an existing task'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'add_tasks_to_request' (which adds tasks to requests) and 'add_dependency' (which adds dependencies between tasks). However, it doesn't specify what type of tasks/subtasks these are (e.g., project management tasks), leaving some context implicit.

  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 by stating 'Add subtasks to an existing task' and mentioning that 'All subtasks must be completed before a task can be marked as done,' which suggests this should be used when breaking down tasks into smaller units. However, it doesn't explicitly state when to use this versus alternatives like 'plan_task' (which might also involve subtask planning) or 'update_task' (which might modify existing subtasks), nor does it mention prerequisites like needing an existing task ID.

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

• open_task_detailsB
  3.2/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 this is for 'inspecting' (implying read-only) and 'at any point' (suggesting availability), but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or what 'details' include. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 highly concise and well-structured in two sentences: the first states the core functionality, and the second adds contextual intent. Every word earns its place with no redundancy or fluff, 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 complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't specify what 'details' are returned, error handling, or dependencies, which are crucial for an agent to use this tool effectively. The description alone is insufficient for full contextual understanding.

  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 adds minimal semantic context by naming the parameter ('taskId') and implying it identifies a specific task. However, with 0% schema description coverage and only one parameter, the baseline is 4 for zero parameters, but here it's adjusted to 3 because the description doesn't fully compensate—it doesn't explain the format, constraints, or examples for 'taskId,' leaving the schema to define it purely as a string type.

  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 with a specific verb ('Get details') and resource ('a specific task'), making it immediately understandable. However, it doesn't explicitly differentiate from potential sibling tools like 'get_next_task' or 'list_requests' that might also retrieve task information, preventing 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 Guidelines3/5

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

  The description provides implied usage context with 'for inspecting task information at any point,' suggesting it's for viewing rather than modifying. However, it lacks explicit guidance on when to use this versus alternatives like 'get_next_task' or 'list_requests,' and doesn't mention prerequisites or exclusions, leaving some ambiguity.

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

• update_subtaskB
  3.3/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 that a 'progress table will be displayed showing the updated task with its subtasks,' which adds some output context. However, it lacks details on permissions needed, whether updates are reversible, error conditions, or rate limits—critical for a mutation tool with zero annotation coverage.

  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 well-structured and front-loaded with the core purpose, followed by parameter guidance and behavioral notes. Each sentence adds value: the first defines the tool, the second lists parameters, the third gives a constraint, and the fourth describes output. It could be slightly more concise by integrating the parameter list more fluidly.

  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 complexity (a mutation tool with 5 parameters, no annotations, and no output schema), the description is moderately complete. It covers the basic action, parameters, a key constraint, and output behavior, but lacks details on error handling, authentication, or side effects, which are important for safe usage.

  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?

  Schema description coverage is 0%, so the description must compensate. It lists all parameters ('requestId', 'taskId', 'subtaskId', 'title', 'description') and clarifies that 'title' and 'description' are optional, adding meaningful context beyond the bare schema. However, it doesn't explain the purpose or format of 'requestId', 'taskId', or 'subtaskId', leaving some ambiguity.

  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 a subtask's title or description') and specifies the resource ('subtask'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'update_task' by focusing specifically on subtasks, though it doesn't explicitly contrast with other update tools like 'update_note'.

  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 provides some usage context by stating 'Only uncompleted subtasks can be updated,' which gives a conditional rule. However, it doesn't explicitly guide when to choose this tool over alternatives like 'update_task' or 'mark_subtask_done,' nor does it mention prerequisites or exclusions beyond completion status.

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

• list_requestsB
  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 mentions listing 'all requests' but doesn't specify aspects like pagination, sorting, filtering, rate limits, or authentication requirements. The phrase 'quick overview' hints at a summary view, but without details on what 'basic information' includes or how tasks are summarized, behavioral traits are under-specified for a tool with no annotation support.

  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 that are front-loaded and efficient. The first sentence directly states the tool's purpose, and the second adds context about its use case. There is no wasted language or redundancy, making it appropriately sized for a simple listing tool.

  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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and usage intent but lacks details on behavioral aspects like response format or system constraints. Without annotations or output schema, the description should ideally specify what 'basic information' includes or how results are structured, but it falls short of being fully complete for operational clarity.

  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 input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are no parameters to describe. This meets the baseline for tools with zero parameters, as there's no need to compensate for schema gaps, but it doesn't provide extra value beyond the schema's emptiness.

  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: 'List all requests with their basic information and summary of tasks.' It specifies the verb ('List'), resource ('requests'), and scope ('all'), providing a specific action. However, it doesn't explicitly differentiate from sibling tools like 'get_next_task' or 'open_task_details', which also involve request/task retrieval, leaving some ambiguity about when to choose this tool over others.

  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 stating it 'provides a quick overview of all requests in the system,' suggesting it's for high-level summaries rather than detailed operations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_next_task' (which might fetch a specific task) or 'open_task_details' (which could provide more details). No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.

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

• add_dependencyA
  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 carries the full burden. It states this is an 'Add' operation, implying a mutation, but doesn't disclose behavioral traits like required permissions, whether dependencies are unique or can be duplicated, what happens on conflicts, or if there are rate limits. The description adds minimal context 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clarifying sentence on dependencies, and then specific usage guidance. Every sentence earns its place with no wasted words or redundancy.

  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 no annotations, no output schema, and 0% schema description coverage for a mutation tool with 3 parameters (including a nested object), the description is incomplete. It covers the basic action and parameter usage context but lacks details on behavioral traits, parameter specifics, and return values, leaving significant gaps for an agent to use it correctly.

  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 0%, so the description must compensate. It explains the semantics of 'taskId' vs. no 'taskId', which clarifies the optional parameter's role. However, it doesn't describe the 'dependency' object's fields (name, description, url, version) or 'requestId', leaving key parameters undocumented. The description adds some value but doesn't fully compensate for the coverage gap.

  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 dependency') and the target resources ('to a request or task'), with specific examples of what dependencies can be ('libraries, tools, or other requirements'). However, it doesn't explicitly differentiate from sibling tools like 'add_note' or 'add_subtasks' beyond the different resource type.

  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 on when to use this tool: 'If 'taskId' is provided, the dependency will be added to that specific task. Otherwise, it will be added to the request.' This gives explicit guidance on parameter usage, though it doesn't mention when not to use it or name specific alternatives among siblings.

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

• delete_taskA
  3.5/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 states the deletion constraint and mentions a progress table output, which adds useful context. However, it lacks details on permissions, reversibility, error handling, or the exact format of the progress table, leaving 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 appropriately sized with two concise sentences that are front-loaded with key information (deletion action and constraint). Every sentence adds value without waste, making it efficient and well-structured.

  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 as a deletion operation with no annotations and no output schema, the description is moderately complete. It covers the core action and constraint but misses parameter details, error cases, and full behavioral transparency, making it adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, and the description doesn't explain the parameters 'requestId' and 'taskId' at all—no details on format, sourcing, or meaning. Since the description fails to compensate for the low schema coverage, it scores below the baseline of 3.

  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 specific task from a request'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling deletion tools like 'delete_note' or 'delete_subtask' beyond the resource type, 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 Guidelines4/5

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

  The description provides clear context for when to use this tool ('Only uncompleted tasks can be deleted'), which helps guide usage. However, it doesn't specify when to choose this over alternatives like 'delete_subtask' or mention any prerequisites, so it falls short of explicit sibling differentiation.

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

• delete_subtaskA
  3.7/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 clearly indicates this is a destructive operation ('Delete'), mentions the constraint about uncompleted subtasks, and describes the visual feedback ('A progress table will be displayed'). However, it doesn't cover important aspects like authentication requirements, error conditions, or whether the deletion is permanent/reversible.

  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 efficient with three focused sentences: the core action, a critical constraint, and the visual feedback. Each sentence earns its place by providing essential information without any redundant or unnecessary content.

  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 operation with no annotations, no output schema, and 3 undocumented parameters, the description is insufficiently complete. While it covers the basic action and a key constraint, it lacks crucial information about error handling, permissions, the nature of the deletion, and what the 'progress table' actually contains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage and 3 undocumented parameters, the description adds minimal value beyond naming the parameters. It lists the three required IDs but provides no context about their format, where to obtain them, or their relationships. The description doesn't compensate for the complete lack of schema documentation.

  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 subtask from a task'), identifies the resource ('subtask'), and distinguishes it from sibling tools like 'delete_task' by specifying it operates on subtasks rather than entire tasks. This provides precise differentiation within the toolset.

  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 for when to use this tool ('Only uncompleted subtasks can be deleted'), which helps the agent understand a key constraint. However, it doesn't explicitly mention when NOT to use it (e.g., for completed subtasks) or name specific alternatives like 'update_subtask' for modifying instead of deleting.

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

• export_task_statusA
  4.1/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 what gets exported (tasks, subtasks, dependencies, notes) and the file creation aspect, but doesn't mention important behavioral traits like whether this requires specific permissions, if it overwrites existing files, error handling, or performance characteristics for large requests.

  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 efficiently structured with four sentences that each add value: purpose statement, elaboration of what's exported, format options, and path recommendation. No wasted words, and the most critical information appears first.

  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 file export tool with 3 parameters and no annotations or output schema, the description is adequate but has gaps. It covers the export purpose and format options well, but doesn't explain the requestId parameter, file overwriting behavior, error conditions, or what happens if the path doesn't exist - important context for a file creation operation.

  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?

  With 0% schema description coverage, the description compensates well by explaining the format parameter options ('markdown', 'json', or 'html') and providing guidance about the outputPath parameter ('recommended to use absolute paths'). However, it doesn't explain the requestId parameter's purpose or format, leaving one of the three parameters undocumented.

  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 ('Export'), resource ('current status of all tasks in a request'), and output destination ('to a file'). It distinguishes this tool from sibling tools like list_requests or get_next_task by focusing on export functionality rather than retrieval or task management.

  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 ('save the current state... for reference') and includes a recommendation about using absolute paths. However, it doesn't explicitly state when NOT to use it or mention alternatives like using list_requests for just viewing tasks without exporting.

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

• get_next_taskA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits. It explains the response behavior (returns next pending task, indicates all_tasks_done), includes a progress table display, specifies error handling (do not proceed if same task returns), and outlines prerequisites (user approval after mark_task_done). This covers mutation effects, user interaction needs, and workflow constraints comprehensively.

  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 sized but could be more front-loaded. The first sentence states the core purpose, but subsequent details on workflow rules are lengthy. Some sentences (e.g., 'In other words:') are redundant. It earns its place with necessary guidelines but lacks optimal structure.

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

  Completeness5/5

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

  Given the complexity (workflow tool with user interaction), no annotations, no output schema, and 1 parameter with 0% schema coverage, the description is complete. It explains the tool's role in a task management workflow, response behaviors, error conditions, and integration with siblings like mark_task_done and plan_task, covering all essential context.

  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 input schema has 1 parameter (requestId) with 0% description coverage. The description adds meaning by specifying that requestId is required to fetch tasks, implying it identifies a specific request context. However, it doesn't detail the format or source of requestId (e.g., from list_requests). Given low schema coverage, the description compensates well but not fully.

  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: 'return the next pending task (not done yet)' given a requestId. It specifies the resource (task) and verb (get/return), distinguishing it from siblings like list_requests or open_task_details. However, it doesn't explicitly differentiate from mark_task_done or other task-related tools beyond the 'get' action.

  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 guidance on when to use this tool: after a requestId is available, to fetch pending tasks. It also details when NOT to use it: after calling mark_task_done until approve_task_completion is called, or if the same task is returned/no new task appears. Alternatives are implied (e.g., plan_task for adding tasks when all are done).

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

• plan_taskA
  4.4/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 effectively describes the tool's role in initiating a workflow, the requirement for user approval after each task, and the iterative cycle until completion. However, it lacks details on error handling, performance characteristics, or what happens if inputs are invalid.

  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 front-loaded with core functionality but becomes verbose with detailed workflow instructions that might be better suited for general guidelines. While informative, some sentences (e.g., the entire numbered list) could be condensed or moved to a separate context, reducing the tool-specific focus.

  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 complexity (6 parameters, 0% schema coverage, no output schema, no annotations), the description does a good job explaining the tool's role, parameters, and integration into a workflow. It covers the initiation process and ties to siblings, but lacks details on return values or error conditions, which are important for a tool with no output schema.

  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?

  With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It explains the purpose of key parameters like 'originalRequest', 'tasks', 'dependencies', 'notes', and 'outputPath', including format recommendations for 'outputPath'. However, it does not fully detail the structure of 'tasks' objects or 'splitDetails'.

  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 tool's purpose: 'Register a new user request and plan its associated tasks.' It specifies the required inputs ('originalRequest' and 'tasks') and distinguishes it from siblings by explaining it initiates a workflow, unlike tools like 'add_tasks_to_request' or 'list_requests'.

  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 guidance on when to use this tool: 'This tool initiates a new workflow for handling a user's request.' It details the workflow steps, including when to use sibling tools like 'get_next_task' and 'mark_subtask_done', and explicitly states not to use it for adding tasks to existing requests (implied by the workflow initiation).

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

• mark_task_doneA
  4.5/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 effectively describes key behaviors: it's a mutation tool (implied by 'Mark... as done'), triggers a progress table display, and has workflow constraints (don't proceed until approval). However, it doesn't mention potential side effects like task status changes or error conditions.

  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 well-structured and front-loaded with the core purpose. The three sentences each serve distinct purposes: action definition, parameter guidance, and workflow rules. It could be slightly more concise by combining some workflow details.

  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 mutation nature, 3 parameters with 0% schema coverage, and no output schema, the description does a good job covering purpose, usage, and basic behavior. It lacks details on error handling, response format, and exact effects on the task, but provides sufficient context for basic use.

  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?

  Schema description coverage is 0%, so the description must compensate. It explains that 'requestId' and 'taskId' are required to identify the task, and 'completedDetails' is optional for adding notes. This adds meaningful context beyond the bare schema, though it doesn't detail parameter formats or constraints.

  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 a given task as done') and resource ('task'), distinguishing it from siblings like 'mark_subtask_done' (for subtasks) and 'update_task' (for general updates). It precisely defines the tool's function as completing a task with optional details.

  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 guidance on when to use this tool ('after you've completed it') and when not to proceed ('DO NOT proceed to 'get_next_task' again until the user has explicitly approved this completed task using 'approve_task_completion''). It clearly distinguishes this from the workflow of getting and approving tasks.

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