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?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that notes are added and displayed/referenced, but lacks critical details such as required permissions, whether this is a mutation (implied by 'Add'), error conditions, or response format. This is a significant gap for a tool with no 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 appropriately sized with two sentences that directly support the tool's purpose. The first sentence states the action and context, while the second explains the utility of notes. There is no wasted text, 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?

  Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on parameter meanings, behavioral traits like permissions or side effects, and does not reference sibling tools. For a mutation tool with zero structured coverage, this is inadequate.

  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 notes contain 'important information about the project, such as user preferences or guidelines,' which loosely relates to 'content' but does not explain 'requestId' or 'title' parameters. This adds minimal value 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 action ('Add a note') and target resource ('to a request'), specifying that notes contain project information like user preferences or guidelines. However, it does not explicitly differentiate from sibling tools like 'update_note' or 'delete_note', which would require a 5.

  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 that notes are displayed in the task progress table and can be referenced when working on tasks, implying usage for tracking project details. However, it provides no explicit guidance on when to use this tool versus alternatives like 'update_note' or 'delete_note', nor any prerequisites or exclusions.

  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 for behavioral disclosure. While 'Delete' implies a destructive operation, it doesn't specify whether this is permanent, reversible, requires specific permissions, or has side effects. The description lacks critical behavioral context for a destructive operation.

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

  Conciseness5/5

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

  The description is extremely concise with two sentences that directly address the tool's purpose and parameter requirements. Every word serves a clear purpose with zero wasted text, 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?

  For a destructive operation with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't address the permanence of deletion, error conditions, authorization requirements, or what happens to related data, leaving significant gaps in 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 mentions both parameters ('requestId' and 'noteId') and their purpose ('of the note to delete'), but with 0% schema description coverage, it doesn't provide format details, constraints, or examples. It adds basic semantic meaning but doesn't fully 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.

  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 ('a note from a request'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_subtask' or 'delete_task', which also perform deletion operations on 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'update_note' or other deletion tools. It doesn't mention prerequisites, consequences, or any context about when deletion is appropriate versus modification.

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

• list_archived_requestsC
  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 'overview of all archived requests with their metadata and completion information' which gives some output context, but lacks critical details like pagination behavior, rate limits, authentication requirements, or whether this is a read-only operation (implied but not stated).

  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 each add value. The first sentence states the core functionality with key capabilities, and the second adds context about what information is returned. No wasted words, though it could be slightly more front-loaded.

  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 list/read tool with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and output content but lacks important behavioral context (pagination, limits, side effects) that would be needed for robust agent usage.

  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 both parameters. The description mentions 'optional search and filtering capabilities' which aligns with the schema but adds no additional semantic context beyond what the parameter descriptions provide.

  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 archived requests' (verb+resource) and mentions 'with optional search and filtering capabilities' which adds specificity. However, it doesn't explicitly differentiate from its sibling 'list_requests' (which presumably lists non-archived requests), missing full sibling 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. It doesn't mention the sibling 'list_requests' or explain when archived vs. active requests should be listed, nor does it provide any context about prerequisites or exclusions.

  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?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states that marking a subtask as done triggers a progress table display and mentions workflow constraints, but doesn't cover critical aspects like whether this is a destructive/mutative operation (implied by 'mark as done'), permission requirements, error conditions, or what happens if subtasks aren't completed. The behavioral context is incomplete 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 that each serve a purpose: stating the core action, describing the visual feedback, and providing workflow context. It's front-loaded with the primary function. While efficient, the third sentence about task completion could be slightly more integrated with the first sentence for better flow.

  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 a mutation tool with 3 parameters (0% schema coverage), no annotations, and no output schema, the description is insufficient. It covers the basic action and some behavioral effects but lacks details on parameter semantics, error handling, return values, and full behavioral implications. The context provided doesn't adequately compensate for the missing structured information.

  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 three required parameters ('requestId', 'taskId', 'subtaskId') but provides no semantic context about what these IDs represent, their format, how to obtain them, or their relationships. The description adds minimal value beyond naming the parameters, failing to address the complete lack of schema documentation.

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

  Purpose4/5

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

  The description clearly states the verb 'mark' and resource 'subtask' with the specific action 'as done', making the purpose immediately understandable. It distinguishes from sibling tools like 'mark_task_done' by specifying subtask-level operation. However, it doesn't explicitly contrast with other subtask-related tools like 'update_subtask' or 'delete_subtask' beyond the 'done' 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 description implies usage context through the statement 'All subtasks must be completed before a task can be marked as done,' suggesting this tool is part of a workflow sequence. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'update_subtask' for status changes or 'mark_task_done' for parent tasks, nor does it specify prerequisites beyond the required parameters.

  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 of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe permissions needed, whether changes are reversible, error conditions (e.g., invalid noteId), or side effects. For a mutation 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.

  Conciseness4/5

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

  The description is appropriately concise with two sentences. The first sentence states the purpose, and the second explains the parameters. There's no wasted text, and it's front-loaded with the core functionality. A minor improvement would be combining sentences for better flow, but it's efficient overall.

  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 mutation tool with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It covers the basic operation and parameters but misses critical context: no error handling, no details on what the update does (e.g., overwrites or merges), no information on return values, and no guidance on usage relative to siblings. This is inadequate for safe and effective tool 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 0%, so the schema provides no parameter documentation. The description adds value by listing the parameters ('requestId', 'noteId', 'title', 'content') and indicating which are required versus optional. However, it doesn't explain what these parameters represent (e.g., format of IDs, constraints on title/content) or provide examples, which is insufficient given the low coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Update an existing note's title or content.' It specifies the verb ('update') and resource ('note'), and distinguishes it from sibling tools like 'add_note' (creation) and 'delete_note' (deletion). However, it doesn't explicitly differentiate from 'update_subtask' or 'update_task', which are similar operations on different resources, so it's not 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 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 (e.g., cannot update archived notes), or compare it to sibling tools like 'update_subtask' or 'update_task'. The only implied usage is for modifying notes, but this is redundant with the purpose statement.

  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 full burden for behavioral disclosure. It mentions that a 'progress table will be displayed' as output, which adds some behavioral context beyond the basic update action. However, it doesn't address important aspects like whether this is a destructive operation, what happens to unchanged fields, error conditions, or authentication requirements.

  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 clear sentences. The first sentence states the core functionality and constraint, while the second describes the output behavior. No wasted words, though it could be slightly more structured with bullet points for constraints.

  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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. While it provides basic purpose and one constraint, it lacks information about parameter meanings, error handling, return values beyond the progress table mention, and comparison to sibling update tools.

  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 4 parameters, the description provides minimal parameter information. It mentions 'title and/or description' as updatable fields, which maps to two of the four parameters. However, it doesn't explain 'requestId' or 'taskId' parameters at all, leaving half the parameters undocumented in both schema and 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 ('Update') and resource ('existing task's title and/or description'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'update_note' or 'update_subtask', but the focus on tasks provides some implicit distinction.

  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 one explicit usage guideline: 'Only uncompleted tasks can be updated.' This gives important context about when NOT to use the tool. However, it doesn't mention alternatives (like 'mark_task_done' for completion) or other contextual factors like permissions or prerequisites.

  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
  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. It mentions that 'All subtasks must be completed before a task can be marked as done' and that 'A progress table will be displayed', adding some behavioral context about dependencies and output format. However, it lacks critical details like whether this is a mutation (implied by 'add'), what permissions are needed, if there are rate limits, or how errors are handled.

  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 front-loads the purpose and parameters. The second explains subtasks concisely. The third describes the output behavior. There's minimal waste, though the second sentence could be slightly more integrated.

  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 coverage, the description is moderately complete. It covers the purpose, parameters at a high level, and some behavioral aspects like dependencies and output display. However, it lacks details on error handling, authentication, or the full impact of the mutation, leaving gaps for a tool with three required parameters.

  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 the parameters ('requestId', 'taskId', and 'subtasks array') and explains that subtasks are 'smaller units of work' with 'title' and 'description', adding meaning beyond the bare schema. However, it doesn't detail the purpose of 'requestId' or 'taskId', or provide examples or constraints for the subtasks array.

  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 'add' and resource 'subtasks to an existing task', making the purpose specific. It distinguishes from siblings like 'add_tasks_to_request' (which adds tasks to requests) and 'update_subtask' (which modifies existing subtasks). However, it doesn't explicitly contrast with all siblings like 'plan_task' or 'mark_task_done'.

  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 'to an existing task', suggesting prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_task' or 'plan_task', nor does it provide exclusions or clear context about when this is the appropriate choice among sibling tools.

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

• delete_taskB
  3.2/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 deletion constraint and that a progress table will be displayed, but it doesn't disclose critical behavioral traits like whether this action is reversible, what permissions are required, or potential side effects on dependencies. For a destructive operation with zero annotation coverage, this is insufficient.

  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. The first sentence states the core action and constraint, while the second describes the output behavior. There's no wasted text, and it's front-loaded with essential information.

  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 destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on error conditions, return values beyond the progress table mention, and how this tool fits into the broader workflow with siblings like 'delete_subtask'.

  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 doesn't explain what 'requestId' or 'taskId' represent, their formats, or how to obtain them. The baseline is 3 because the schema provides the structure, but the description adds no meaningful parameter semantics beyond what's implied by the tool name.

  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 tools like 'delete_subtask' or 'delete_note', which reduces 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 Guidelines3/5

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

  The description provides some usage guidance by stating 'Only uncompleted tasks can be deleted,' which implies when NOT to use it. However, it doesn't explicitly mention when to use this tool versus alternatives like 'archive_completed_requests' or 'update_task' for modifying tasks instead of deleting them.

  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?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for 'inspecting' information, implying a read-only operation, but does not clarify if it requires authentication, has rate limits, returns specific data formats, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is highly concise and front-loaded, consisting of two clear sentences: the first states the core functionality, and the second adds contextual usage. There is no redundant or verbose language, making it efficient and easy to parse.

  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 task management tools, no annotations, no output schema, and incomplete parameter documentation (0% schema coverage), the description is insufficient. It does not explain what details are returned, error conditions, or how it fits into broader workflows with siblings like 'update_task'. More context is needed for effective use.

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

  Parameters3/5

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

  The description adds meaning by specifying that 'taskId' is used to get details of a specific task, which clarifies the parameter's role beyond the schema's basic type definition. However, with 0% schema description coverage and only one parameter, the description does not fully compensate by explaining the format or constraints of 'taskId' (e.g., expected string pattern). The baseline is appropriate given the minimal parameter count.

  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: 'Get details of a specific task by 'taskId''. It specifies the verb ('Get details'), resource ('task'), and key identifier ('taskId'), making the action explicit. However, it does not differentiate from sibling tools like 'get_next_task' or 'list_requests', which also retrieve task-related information, so it falls short of 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 'This is for inspecting task information at any point', suggesting it can be used flexibly. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_next_task' or 'list_requests', and does not mention prerequisites or exclusions. This leaves room for ambiguity in tool selection.

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

• add_dependencyB
  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 describes the basic action but lacks critical details: whether this is a mutating operation (implied by 'add'), what permissions are required, if there are rate limits, how conflicts are handled, or what the response looks like. For a tool with 3 parameters and nested objects, this is insufficient.

  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 each add value: purpose statement, dependency type clarification, and parameter logic explanation. It's front-loaded with the core purpose. One minor improvement could be combining the first two sentences for even tighter structure.

  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 (3 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't explain the response format, error conditions, authentication requirements, or the full parameter semantics. For a mutating tool with significant parameter complexity, this leaves too many unknowns for 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 0%, so the description must compensate. It explains the conditional logic between 'taskId' and request-level addition, and clarifies that dependencies can be 'libraries, tools, or other requirements'. However, it doesn't explain the structure of the 'dependency' object or the purpose of 'requestId', leaving significant gaps. The baseline would be lower without the parameter context provided.

  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 'add' and the resource 'dependency', specifying it can be added to either a request or task. It distinguishes from siblings like 'add_note' or 'add_subtasks' by focusing on dependencies. However, it doesn't explicitly differentiate from all siblings, keeping it at 4 instead of 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 clear context on when to use this tool: when needing to add dependencies to projects or tasks. It specifies the conditional logic based on 'taskId' presence. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, 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.

• add_tasks_to_requestB
  3.3/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 all tasks including the newly added ones,' which adds some behavioral context about output. However, it lacks details on permissions, side effects (e.g., whether this is a mutation), error handling, or rate limits, which are critical for a tool that modifies data.

  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 in the first sentence, followed by additional details in two more sentences. It avoids redundancy and is appropriately sized, though the last sentence about the progress table could be more integrated or omitted if not critical.

  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, the description is moderately complete. It covers the tool's purpose and some parameter semantics but lacks behavioral details like mutation effects, error cases, or return values, which are important for a tool that adds tasks to requests.

  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 for 2 parameters, the description must compensate. It clarifies that 'tasks' can include 'subtasks and dependencies,' providing meaningful context beyond the schema's structural definition. However, it doesn't explain the 'requestId' parameter or provide examples, leaving some gaps in full 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 ('to an existing request'), with the additional context that it 'allows extending a request with additional tasks.' This provides a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like 'add_subtasks' or 'add_dependency' beyond the scope of tasks vs. subtasks/dependencies.

  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's for 'extending a request with additional tasks,' which suggests it should be used when you have an existing request and want to add more tasks. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'add_subtasks' or 'update_task,' nor does it mention prerequisites or exclusions.

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

• archive_completed_requestsB
  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 but lacks critical behavioral details. It mentions archiving moves requests to a separate file, but doesn't specify if this is reversible, what permissions are needed, whether it's destructive to original data, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap.

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

  Conciseness4/5

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

  The description is well-structured with three sentences: purpose, parameter logic, and rationale. Each sentence adds value without redundancy, though the third sentence slightly rephrases the first, making it slightly less than perfectly 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 no annotations, no output schema, and a single parameter with full schema coverage, the description covers basic purpose and parameter logic adequately. However, for a mutation tool that likely changes system state, it should provide more behavioral context like reversibility or error handling to be fully complete.

  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 description adds meaningful context beyond the schema's 100% coverage by explaining the conditional logic: if requestIds is provided, only those are archived; if not, all completed requests are archived. This clarifies the parameter's semantic impact, though it doesn't add format or validation details.

  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 archives completed requests to keep the active tasks file clean, specifying the verb (archive) and resource (completed requests). It distinguishes from siblings like list_requests or restore_archived_request by focusing on archiving, though it doesn't explicitly contrast with them.

  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 when wanting to clean the active tasks file by moving completed work to archive storage. It doesn't provide explicit when-not-to-use guidance or name alternatives like list_archived_requests for checking archives, leaving usage context somewhat inferred rather than clearly defined.

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

• remove_promptsB
  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 the full burden of behavioral disclosure. It describes the conditional removal behavior based on 'fields', which is useful, but fails to address critical aspects: it doesn't specify if this is a destructive operation (implied by 'remove' but not explicit), what permissions are required, whether changes are reversible, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, with two sentences that directly address the core functionality without waste. The first sentence states the purpose, and the second explains the parameter-driven behavior, making it easy to scan and understand quickly. Every sentence earns its place by adding essential information.

  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 mutation operation with conditional behavior), no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It covers the basic parameter logic but misses critical context: it doesn't explain the return value, error handling, side effects, or how this interacts with sibling tools like 'update_prompts'. For a tool that modifies configuration, this leaves too many unknowns for reliable agent 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?

  The schema has 1 parameter with 0% description coverage, so the description must compensate. It effectively explains the semantics of the 'fields' parameter: if provided, only those specific fields are removed; if not, the entire configuration is removed. This adds clear meaning beyond the schema's enum values ('instructions', 'taskPrefix', 'taskSuffix'), though it doesn't detail what each field represents or the impact of removal.

  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 'remove' and the resource 'prompts configuration or specific fields from it', making the purpose understandable. It distinguishes from siblings like 'get_prompts', 'set_prompts', and 'update_prompts' by focusing on deletion rather than retrieval, creation, or modification. However, it doesn't explicitly contrast with 'delete_task' or 'delete_subtask', which might cause minor confusion about scope.

  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 through conditional logic based on the 'fields' parameter, suggesting when to use it for partial vs. full removal. However, it lacks explicit guidance on when to choose this tool over alternatives like 'update_prompts' for modifications or 'set_prompts' for replacement, and doesn't mention prerequisites or error conditions. This leaves some ambiguity in decision-making.

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

• restore_archived_requestB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions the action 'moves the request from the archive back to active status', which implies a mutation but doesn't disclose behavioral traits like permissions needed, whether it's reversible, potential side effects (e.g., impact on dependencies), or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action ('Restore a specific archived request back to the active tasks file') and followed by a clarifying sentence. Every sentence earns its place by explaining the purpose and effect without redundancy or fluff, making it highly efficient.

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

  Completeness3/5

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

  Given the tool has one parameter with full schema coverage but no annotations or output schema, the description is moderately complete. It explains what the tool does but lacks details on behavioral aspects (e.g., success/failure outcomes, error conditions) and doesn't leverage the sibling context to guide usage more precisely. For a mutation tool, this leaves room for improvement in completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single parameter 'requestId' documented as 'The ID of the archived request to restore'. The description adds no additional parameter semantics beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

  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 'restore' and resource 'archived request', specifying it moves the request 'back to active status'. It distinguishes from siblings like 'archive_completed_requests' and 'list_archived_requests' by focusing on restoration rather than archiving or listing. However, it doesn't explicitly contrast with 'list_requests' (which might show active requests) or other task management tools, keeping it from a perfect score.

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

  Usage Guidelines3/5

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

  The description implies usage when you need to 'continue working on' an archived request, suggesting it's for reactivation. However, it lacks explicit guidance on when to use this versus alternatives like creating new tasks or using other request tools, and doesn't mention prerequisites (e.g., the request must be archived first). This leaves some ambiguity in context.

  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. It mentions the tool lists 'basic information and summary of tasks' but doesn't disclose key behavioral traits: whether it's paginated, sorted, filtered, or if it requires specific permissions. For a list 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 two sentences, front-loaded with the core purpose and followed by a clarifying context sentence. Every word earns its place, with no redundancy or fluff. It's appropriately sized for a simple list 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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior (e.g., pagination, sorting) and output format. For a list tool with no structured output documentation, this leaves gaps in completeness.

  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, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is applied since there are no parameters to document, and the description doesn't introduce unnecessary complexity.

  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') and resource ('requests'), and distinguishes it from siblings like 'list_archived_requests' by implying it lists active/non-archived requests. However, it doesn't explicitly contrast with 'list_archived_requests', so it's not 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 Guidelines3/5

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

  The description implies usage context: 'provides a quick overview of all requests in the system' suggests this is for high-level scanning rather than detailed inspection. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_archived_requests' or 'open_task_details', nor does it mention any prerequisites or exclusions, leaving room for 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.4/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. It discloses that updates are restricted to uncompleted subtasks and mentions a progress table display, adding useful behavioral context. However, it lacks details on permissions, error handling, or mutation effects, leaving gaps for a tool with no 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 appropriately sized with three sentences: the first states the purpose and parameters, the second adds a constraint, and the third describes output behavior. It's front-loaded with essential info, though the last sentence could be 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 no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers purpose, parameters, a key constraint, and output indication, but lacks details on error cases, auth needs, or return values, which are important for a mutation tool.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It lists all 5 parameters and indicates that 'title' and 'description' are optional, adding meaning beyond the bare schema. However, it doesn't explain parameter formats, constraints, or examples, providing only basic semantics.

  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 the resource 'subtask's title or description', making the purpose specific. It distinguishes from sibling tools like 'update_task' by focusing on subtasks, though it doesn't explicitly contrast with 'update_note' or 'update_prompts'.

  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 implies when not to use it. However, it doesn't explicitly guide when to choose this over alternatives like 'update_task' or 'mark_subtask_done', leaving usage partly implied.

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

• get_promptsA
  3.6/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. It discloses that this is a read operation ('Get', 'view') and specifies the scope ('global prompts settings applied to all tasks'), which is useful behavioral context. However, it lacks details on permissions, rate limits, or response format, leaving gaps for a tool with no 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 and efficient: the first sentence clearly states the purpose and key fields, and the second sentence adds useful context about global application. Both sentences earn their place without redundancy or fluff, making it appropriately sized for a simple 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 reasonably complete for basic understanding. It explains what the tool retrieves and its scope. However, without annotations or output schema, it could benefit from more detail on return format or error conditions, leaving some contextual gaps.

  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, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output semantics (e.g., 'including instructions, taskPrefix, and taskSuffix settings'), adding value beyond the empty schema. Baseline for 0 parameters is 4.

  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: 'Get the current prompts configuration' with specific fields (instructions, taskPrefix, taskSuffix). It distinguishes from siblings like 'set_prompts' and 'update_prompts' by focusing on retrieval rather than modification. However, it doesn't explicitly contrast with 'remove_prompts' or other prompt-related tools.

  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 it 'helps you view the current global prompts settings that are applied to all tasks,' suggesting it's for configuration inspection. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'set_prompts' or 'update_prompts,' nor does it mention prerequisites or exclusions.

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

• set_promptsA
  3.8/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 adds useful context: 'This replaces any existing prompts settings with the new values provided,' indicating a destructive overwrite behavior. However, it doesn't cover other important aspects like permissions needed, rate limits, error handling, or what happens if only some parameters are provided.

  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 well-structured. It starts with a clear purpose statement, follows with a critical behavioral note, and then provides bullet-point explanations for each parameter. Every sentence earns its place with no wasted words, making it easy to scan and understand.

  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 (mutating global configuration with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose, destructive behavior, and parameter meanings well, but lacks information about return values, error conditions, permissions, or how partial updates are handled, which would be helpful for a mutation tool.

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

  Parameters5/5

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

  The schema description coverage is 0%, so the description must compensate. It does so effectively by listing all three parameters ('instructions', 'taskPrefix', 'taskSuffix') and providing clear semantic explanations for each: 'General instructions or context shown at the top of each task', 'Text to prepend before each task description', and 'Text to append after each task description'. This adds significant value beyond the bare 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 tool's purpose: 'Set the global prompts configuration with instructions, taskPrefix, and/or taskSuffix.' It specifies the verb ('Set'), resource ('global prompts configuration'), and scope ('instructions, taskPrefix, and/or taskSuffix'), though it doesn't explicitly differentiate from sibling tools like 'update_prompts' or 'remove_prompts'.

  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 'This replaces any existing prompts settings with the new values provided,' which suggests it should be used when replacing all prompts settings. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_prompts' or 'remove_prompts,' nor does it provide clear exclusions or prerequisites.

  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.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 operation (implied by 'mark as done'), triggers a progress table display, and enforces a workflow pause until user approval. It doesn't cover potential side effects like task status changes in related systems or error conditions, but provides substantial operational context.

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

  Conciseness3/5

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

  The description is front-loaded with the core purpose but becomes verbose with workflow instructions that might be better placed elsewhere. The three sentences vary in focus: first states the action, second describes an output behavior, third gives procedural constraints. While all content is relevant, the structure mixes operational details with core tool description.

  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 mutation tool with no annotations and no output schema, the description does well by explaining the action, parameters, immediate visual feedback (progress table), and critical workflow constraints. It misses details about return values, error handling, and the exact nature of the 'progress table', but provides sufficient context for basic safe usage 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?

  With 0% schema description coverage for 3 parameters, the description partially compensates by mentioning all parameters ('requestId', 'taskId', 'completedDetails') and indicating which are required vs. optional. However, it doesn't explain what these parameters represent (e.g., format of IDs, content of completedDetails) or provide examples, leaving significant semantic 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 action ('Mark a given task as done') and the resource ('task'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'mark_subtask_done' or 'update_task' which might have overlapping functionality, 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 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 [a task]') and when not to use alternatives ('DO NOT proceed to 'get_next_task' again until the user has explicitly approved'). It also mentions the workflow context and user approval requirement, offering comprehensive usage instructions.

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

• delete_subtaskA
  4.1/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 destructive nature ('delete'), the constraint on uncompleted subtasks, and the output behavior ('A progress table will be displayed showing the updated task with its remaining subtasks'). This covers key aspects like mutability, preconditions, and visual feedback, though it lacks details on error handling or permissions.

  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, followed by essential constraints and output details in three concise sentences. Each sentence adds critical information without redundancy, making it efficient and well-structured for quick comprehension by an agent.

  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 destructive tool with no annotations and no output schema, the description does a decent job by covering the action, constraints, and visual output. However, it misses details like error cases (e.g., invalid IDs), side effects, or confirmation requirements, which are important for safe invocation. Given the complexity of deletion operations, this leaves room for improvement.

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

  Parameters3/5

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

  The schema description coverage is 0%, so the description must compensate. It lists the three required parameters ('requestId', 'taskId', and 'subtaskId') but doesn't explain their meaning, format, or relationships (e.g., that subtaskId must belong to taskId). This adds minimal semantic value beyond naming the parameters, failing to fully address the coverage gap.

  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 siblings like 'delete_task' (which deletes entire tasks) and 'mark_subtask_done' (which completes rather than removes subtasks). The verb 'delete' is precise and unambiguous.

  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 NOT to use this tool ('Only uncompleted subtasks can be deleted'), which helps the agent avoid errors. However, it doesn't mention alternatives like 'mark_subtask_done' for completed subtasks or clarify prerequisites beyond the required parameters, leaving some contextual gaps.

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

• update_promptsA
  4.3/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 the tool's behavior as a partial update operation, which implies mutation but doesn't specify permissions, side effects, or response format. It adds some context (e.g., fields that can be modified) but lacks details on error handling or constraints, 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 front-loaded with the core purpose in the first sentence, followed by usage guidance. Both sentences are essential, with no redundant information, making it efficiently structured and appropriately sized for the tool's complexity.

  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, 0% schema coverage, no output schema, and a mutation tool with 3 parameters, the description is incomplete. It covers the purpose and usage well but lacks behavioral details (e.g., permissions, side effects) and parameter specifics, making it adequate but with clear gaps for safe agent invocation.

  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 and 3 parameters, the description compensates by listing the specific fields that can be updated ('instructions, taskPrefix, or taskSuffix'), providing meaningful semantics beyond the bare schema. However, it doesn't detail the format or constraints of these fields, so it doesn't fully cover all parameter aspects.

  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 ('Update specific parts of the prompts configuration') and resource ('prompts configuration'), distinguishing it from sibling tools like 'set_prompts' (which likely replaces the entire object) and 'get_prompts' (which reads). It explicitly mentions the partial update nature versus full replacement.

  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 ('to modify individual fields... while keeping other settings unchanged') and implies when not to use it (e.g., use 'set_prompts' for full replacement or 'get_prompts' for reading). It clearly differentiates from alternatives like 'set_prompts' by specifying partial updates.

  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.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 full burden and does well by disclosing key behavioral traits: it creates a file output (write operation), explains path resolution logic (directory vs. full path, relative paths), and describes auto-generation rules for filenames. It doesn't mention error conditions, permissions needed, or rate limits, but covers substantial operational 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 well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds specific value: what gets saved, parameter explanations, and path handling rules. There's zero wasted text, and the bullet points enhance readability without verbosity.

  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 tool with 4 parameters, no annotations, and no output schema, the description provides strong coverage of inputs, behavior, and output format options. It lacks details on error cases, exact file naming conventions (beyond extension), and what the exported content structurally contains, but it's largely complete for practical use given the 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?

  Schema description coverage is 50% (2 of 4 parameters have descriptions). The description compensates effectively by explaining all parameters: it clarifies 'format' options, distinguishes 'outputPath' usage (directory vs. file), explains 'filename' auto-generation, and implies 'requestId' is required (though not explicitly stated). This adds meaningful context beyond the schema's limited descriptions.

  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 with specific verbs ('Export', 'saves') and resources ('current status of all tasks in a request', 'tasks, subtasks, dependencies, and notes'), distinguishing it from sibling tools that focus on individual operations like add/delete/update tasks or notes. It explicitly identifies what gets exported and to what format.

  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: to save task status for reference. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., list_requests for overview vs. this for detailed export), though the context implies it's for archival/reference purposes rather than real-time querying.

  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
  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 so effectively. It discloses key behavioral traits: progress table display with each response, state-dependent outcomes (pending task vs. all_tasks_done), and critical workflow constraints (user approval requirements after task completion). It doesn't cover rate limits or error handling, but provides substantial operational context.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with core functionality, but contains some redundancy (repeating approval requirements) and could be more streamlined. The bullet points help structure but add length. Most sentences earn their place, but some phrasing could be tighter.

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

  Completeness4/5

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

  Given the tool's complexity (stateful workflow with user interactions) and absence of both annotations and output schema, the description provides substantial context about behavior, outcomes, and integration with sibling tools. It doesn't describe the progress table format or error cases, but covers the essential workflow comprehensively.

  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% with 1 parameter, so the description must compensate. It explains that 'requestId' identifies which request's tasks to process, adding meaningful context beyond the bare schema. However, it doesn't specify format or constraints for the requestId value.

  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 with specific verbs ('return the next pending task') and resource ('given a requestId'), distinguishing it from siblings like 'list_requests' or 'open_task_details'. It explicitly defines what constitutes a 'next task' (not done yet) versus completion state.

  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 when-to-use guidance, including prerequisites (need 'requestId'), when not to use (after 'mark_task_done' without user approval), and alternatives for completion scenarios ('add_tasks_to_request' or 'plan_task'). It directly addresses sibling tool interactions with clear sequencing rules.

  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 key behaviors: it initiates a workflow, creates a Markdown file if 'outputPath' is provided, and explains the workflow's interactive nature (requiring user approval after each task). However, it doesn't mention potential side effects like file system changes or error handling, leaving some gaps.

  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 the core purpose and required parameters, but it becomes verbose with an extensive workflow explanation (9 steps) that might be better suited for general documentation. While informative, some sentences (e.g., the detailed workflow steps) could be condensed without losing essential guidance, making it less concise than ideal.

  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, no annotations, no output schema), the description is largely complete. It covers the tool's role in a workflow, parameter semantics, and usage guidelines. However, it lacks details on return values (since no output schema exists) and doesn't address error conditions or validation rules, which are important for a tool with nested object parameters.

  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 adds significant meaning: it explains that 'originalRequest' and 'tasks' are required, 'splitDetails' is optional, 'dependencies' are project/task-specific, 'notes' are general guidelines, and 'outputPath' saves a Markdown file with absolute path recommendations. It also clarifies that tasks can include subtasks and dependencies. However, it doesn't detail the structure of 'tasks' objects beyond mentioning subtasks and dependencies.

  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 verb 'register' and resource 'user request and tasks,' distinguishing it from siblings like 'add_tasks_to_request' (which adds to existing requests) or 'list_requests' (which only lists).

  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 usage guidelines, detailing when to use this tool (to initiate a new workflow) versus alternatives (e.g., 'add_tasks_to_request' for adding tasks to existing requests). It outlines the entire workflow sequence, including when to use sibling tools like 'get_next_task' and 'mark_subtask_done,' and specifies prerequisites (must provide 'originalRequest' and 'tasks').

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