Server Quality Checklist

Tool Scores

• get_stack_overviewB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It states the output format (JSON) and scope (all task details and relationships), but lacks behavioral details such as performance characteristics, rate limits, authentication needs, or whether it's read-only (implied by 'Get' but not explicit).

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Get structured data of your entire task stack') and adds essential format details. Every word earns its place with no 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 the tool's complexity (read-only overview with no parameters) and lack of annotations/output schema, the description is minimally adequate. It covers the purpose and output format but misses behavioral context and usage guidelines, leaving gaps for an agent to infer.

  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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, but this is appropriate given the empty schema, meeting the baseline for zero parameters.

  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 ('Get') and resource ('structured data of your entire task stack'), specifying the format ('JSON format with all task details and relationships'). It distinguishes from siblings like 'get_current_task' or 'get_completed_tasks' by emphasizing 'entire' scope, but doesn't explicitly contrast them.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'get_big_picture' or 'get_current_task'. The description implies a comprehensive overview, but doesn't specify use cases, prerequisites, or exclusions.

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

• list_siblingsB
  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 full burden. It mentions behavioral aspects like including 'both pending and completed tasks' and being 'left of current focus', but lacks details on permissions, rate limits, or response format. For a tool with no annotations, this leaves significant gaps in understanding its operation.

  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 two sentences, front-loaded with the core purpose and followed by additional context. It's efficient with no wasted words, though it could be slightly more structured by separating usage guidance into a distinct part.

  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 simple input schema, the description provides basic purpose and context but lacks details on return values, error handling, or deeper behavioral traits. It's minimally adequate for a read-only tool but doesn't fully compensate for the missing structured data.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with one parameter 'include_body' fully documented. The description doesn't add any parameter-specific information beyond the schema, such as examples or implications of setting 'include_body' to true. Baseline 3 is appropriate since the schema handles the parameter documentation.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'See all sibling tasks to the left of current focus' with the verb 'see' and resource 'sibling tasks'. It distinguishes from siblings like 'get_current_task' (single task) and 'get_completed_tasks' (all completed tasks) by focusing on leftward siblings. However, it doesn't explicitly contrast with 'get_stack_overview' which might show a broader view.

  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: 'Helpful for understanding your position in the current task sequence' suggests using it when orientation is needed. It doesn't provide explicit when-not-to-use guidance or name alternatives like 'get_stack_overview' for different perspectives, 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_current_taskB
  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 an update operation, implying mutation, but doesn't cover critical aspects like whether this requires specific permissions, if changes are reversible, what happens to existing content not mentioned, or any rate limits. The description adds minimal behavioral 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 a single, efficient sentence that front-loads the key information ('Update notes/content of the task') and includes a clarifying parenthetical ('current task only'). There is no wasted verbiage, and every word serves a clear purpose in conveying the tool's function and scope.

  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 no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, reversibility), doesn't explain the return value or potential errors, and offers minimal guidance on usage compared to siblings. The high schema coverage helps with parameters, but overall context is insufficient for safe and 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 input schema has 100% description coverage, with the 'body' parameter clearly documented as 'New body content for the task.' The description doesn't add any meaningful semantics beyond this, such as formatting examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 notes/content') and target resource ('the task you're currently focused on'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'extend_current_task' or 'complete_current_task', which likely also modify the current task in different ways.

  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 specifying 'current task only,' which suggests this tool is for modifying an existing focused task rather than creating new ones. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'extend_current_task' or 'complete_current_task,' leaving some ambiguity about the specific scenarios for each tool.

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

• get_current_taskA
  3.8/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 retrieves the current task (implying a read operation), explains how the current status is determined (manually via 'switch_focus' or automatically), and specifies the response in 'zen state' (returns an appropriate message). This covers the core functionality and edge cases without contradictions.

  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 concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose, how the current task is determined, and the behavior in 'zen state'. Every sentence adds value without redundancy, making it easy for an agent to parse 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 (simple retrieval with no parameters) and the absence of annotations and output schema, the description is moderately complete. It explains what the tool does and edge cases ('zen state'), but lacks details on the return format (e.g., structure of the task object or message) and does not fully integrate with sibling tools, leaving some gaps for an agent to infer.

  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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, as there are no parameters to document. It appropriately focuses on the tool's behavior and context, earning a high baseline score for this dimension.

  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: to retrieve the task with CURRENT status, which is defined as the active focus. It specifies that this status can be set manually via 'switch_focus' or automatically determined, and describes behavior in 'zen state'. However, it doesn't explicitly differentiate from sibling tools like 'get_completed_tasks' or 'get_stack_overview', which would require a more direct comparison.

  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 mentioning that the current task may be set via 'switch_focus' or automatically determined, and references 'zen state' scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_big_picture' or 'peek_context', and does not specify prerequisites or exclusions, leaving some ambiguity for the agent.

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

• get_big_pictureA
  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 full burden. It discloses behavioral traits: output includes 'current task with 'YOU ARE HERE'' marking and 'zen state when no tasks exist OR all tasks are completed', which are useful context. However, it doesn't mention permissions, rate limits, or what 'zen state' entails (e.g., empty response vs message), leaving some 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by clarifying details. Each sentence adds value (e.g., 'living document', 'YOU ARE HERE', 'zen state') without redundancy, making it efficient and well-structured.

  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 no annotations and no output schema, the description does well by explaining key behavioral aspects (marking current task, zen state) and scope (ALL tasks, full context). However, for a tool with 1 parameter and no output schema, it could more fully describe the output format or examples, though the parameter covers format options. It's largely complete but has minor gaps in output details.

  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 'format' fully documented in the schema (enum: text/json, default: text). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the verb 'see' and resource 'ALL tasks in your task stack (including completed ones)', specifying scope comprehensively. It distinguishes from siblings like get_current_task (single task), get_completed_tasks (only completed), and get_stack_overview (likely summary vs full context) by emphasizing 'ALL tasks' and 'full work context as a living document'.

  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 implies usage context: 'See ALL tasks... Shows full work context' suggests it's for comprehensive review, and 'Marks current task with 'YOU ARE HERE'' indicates it helps orient within the stack. However, it doesn't explicitly state when to use this vs alternatives like get_stack_overview or peek_context, nor does it provide exclusions or prerequisites.

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

• peek_contextA
  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 of behavioral disclosure. It effectively communicates the non-destructive nature ('without changing focus') and the tool's purpose for understanding context. However, it doesn't address potential limitations like what happens if there's no parent/previous sibling, performance characteristics, 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.

  Conciseness5/5

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

  The description is perfectly concise with zero wasted words - a single sentence that front-loads the core functionality ('Look at parent task and previous sibling') followed by clarifying context. Every element earns its place, making it highly efficient for agent comprehension.

  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 moderate complexity (context inspection without mutation), no annotations, and no output schema, the description provides good contextual coverage. It clearly explains what the tool does and its purpose, though it could benefit from mentioning what information is returned or how results are structured since there's no output schema.

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

  Parameters3/5

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

  With 100% schema description coverage for the single parameter, the description adds no additional parameter information beyond what's already documented in the schema. The baseline score of 3 reflects adequate but minimal value addition, as the schema already fully describes the 'include_body' parameter with its type, description, and default 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 ('Look at') and resources ('parent task and previous sibling'), while distinguishing it from siblings by emphasizing it doesn't change focus. The 'understand WHY you're doing current task' clause adds valuable context about the tool's intent beyond basic functionality.

  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 ('understand WHY you're doing current task'), which implicitly suggests it's for contextual understanding rather than task manipulation. However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list that might serve similar purposes.

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

• extend_current_taskA
  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 full burden for behavioral disclosure. It describes the tool's function (creating hierarchical subtask structure) and mentions freedom to work on tasks in any order, but doesn't cover important behavioral aspects like whether this operation is reversible, what permissions are needed, or how it affects existing task structures beyond the basic creation.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. It starts with the core purpose, explains the hierarchical structure concept, provides usage guidance, and gives an example. Every sentence adds value, though the example could be slightly more concise.

  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 2 parameters, 100% schema coverage, and no output schema, the description provides good context. It explains the tool's purpose, distinguishes it from alternatives, and gives usage examples. The main gap is lack of information about return values or error conditions, but given the tool's relative simplicity, the description is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It focuses on the tool's purpose and usage rather than parameter details, which is appropriate given the complete schema coverage.

  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 ('Add a subtask', 'Creates hierarchical structure') and resources ('organize and decompose work', 'complex tasks'). It distinguishes from sibling tools by explicitly mentioning 'create_new_task' for unrelated work, showing clear differentiation.

  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 vs alternatives: 'For unrelated work, use create_new_task.' It also mentions 'switch_focus' for working on tasks in any order, giving clear context for usage decisions among sibling tools.

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

• switch_focusA
  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 explains key behaviors: 'Current task retains its status, target task becomes current' and that it works with 'ANY task by ID' including completed ones. However, it doesn't address potential side effects, error conditions, or what happens if an invalid ID is provided, leaving some behavioral aspects unclear.

  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 distinct purpose: stating the core function, explaining its role in navigation, and providing usage guidance. It's front-loaded with the primary action. There's minimal redundancy, 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.

  Completeness4/5

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

  Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description provides good contextual coverage. It explains the tool's purpose, usage context, and behavioral effects. The main gap is the lack of output information, but for a focus-switching tool, the behavioral description ('target task becomes current') provides adequate context about the expected outcome.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'task_id' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'ANY task by ID' and referring to sibling tools for finding IDs, but doesn't provide additional semantic context about the parameter format or constraints. This meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the verb ('switch focus') and resource ('ANY task by ID'), specifying it's the primary navigation method for the task workspace. It distinguishes from siblings by mentioning specific alternatives (get_big_picture, get_stack_overview) for finding IDs, rather than overlapping with task manipulation tools like update_current_task or complete_current_task.

  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?

  It provides explicit guidance on when to use this tool ('primary way to navigate your task workspace') and when to use alternatives ('Use get_big_picture or get_stack_overview to see task IDs'). The description also clarifies the tool's role in the workflow by mentioning it can be used to 'jump between tasks in any order, revisit completed work, or change priorities on the fly'.

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

• create_new_taskA
  4.2/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 explains that the new task is independent and top-level, and that the previous task retains its status, which adds useful context. However, it lacks details on permissions, error handling, or what happens if creation fails, leaving some behavioral aspects unclear.

  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 usage guidelines and an example. Every sentence adds value—none are redundant or vague—and it efficiently conveys necessary information in a compact form.

  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 moderate complexity (creation operation with 2 parameters) and no annotations or output schema, the description does a good job of explaining the tool's purpose, usage, and behavioral context. However, it could be more complete by addressing potential errors or the absence of an output schema, which might leave the agent uncertain about the return value.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so the schema already documents both parameters (title and body) adequately. The description does not add any parameter-specific semantics beyond what the schema provides, such as formatting examples or constraints beyond the schema's max 256 chars for title.

  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: 'Create an INDEPENDENT task for unrelated work' and 'Adds a new top-level task to your workspace.' It specifies the verb (create), resource (task), and scope (independent/top-level), and distinguishes it from sibling tools like extend_current_task.

  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 ('for: new topics, context switches, or parallel workstreams') and when not to use it ('For breaking down current work, use extend_current_task'). It includes a concrete example and names the alternative tool, making it highly actionable.

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

• get_completed_tasksA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a read-only operation ('view'), the data is permanent/archival ('permanent archive'), tasks persist even after workspace removal, and it provides chronological history. It doesn't mention rate limits or authentication needs, but covers the core behavior adequately.

  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 three sentences that each add value: first states the core function, second explains archival nature, third gives usage context. It's front-loaded with the main purpose and has zero wasted words.

  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 simple read tool with one parameter (fully documented in schema) and no output schema, the description provides good context about the archival nature and persistence of data. It could mention the return format or pagination, but given the low complexity, it's reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents the single parameter 'order' with its enum values and default. The description doesn't add any parameter-specific information beyond what the schema provides, meeting the baseline expectation.

  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 ('view chronological history') and resource ('ALL completed tasks'), and distinguishes it from siblings by emphasizing it's a 'permanent archive separate from the visible structure' and that tasks remain even after removal from the workspace.

  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 ('useful for reviewing what you've accomplished over time'), but doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools (like get_current_task or get_stack_overview).

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

• remove_taskA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden and discloses key behavioral traits: it explains that removed tasks go to 'completed_tasks history if it was completed', clarifies it 'can remove any task (completed or not)', and warns that 'removing a parent task removes all its subtasks'. This covers mutation effects and side effects, though it doesn't mention permissions or error handling.

  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 action, the second adds behavioral details, and the third provides usage guidance. Every sentence adds value, though it could be slightly more streamlined by integrating the ID reference into the first sentence.

  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 (a destructive operation with cascading effects), no annotations, and no output schema, the description does well by explaining the mutation behavior and history implications. However, it lacks details on return values or error cases, which would enhance completeness for such a critical tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the 'task_id' parameter. The description adds no additional meaning about the parameter beyond implying its purpose through context (e.g., referencing 'task IDs' from other tools), which meets the baseline for high schema coverage.

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

  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 ('remove a task from the structure') and resource ('task'), distinguishing it from siblings like 'complete_current_task' or 'update_current_task' that modify tasks rather than removing them. The phrase 'cleanup your workspace' reinforces the purpose without being tautological.

  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?

  It explicitly provides when to use this tool ('to see task IDs, use get_big_picture or get_stack_overview'), which helps differentiate from sibling tools for viewing tasks. The description also implies usage for cleanup, though it doesn't specify when not to use it or name direct alternatives beyond the ID lookup tools.

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

• complete_current_taskA
  4.6/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: the task remains visible (living document approach), focus moves automatically, and a permanent history record is created. However, it doesn't address potential side effects like error conditions or what happens if no incomplete tasks are nearby.

  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 concise sentences, each adding distinct value: the core action, visibility behavior, focus movement, history recording, and explicit alternative tools. There is no wasted text, and information is front-loaded with the primary purpose.

  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 (a mutation with behavioral nuances), no annotations, and no output schema, the description does well by covering the core action, persistence model, focus behavior, and alternatives. However, it lacks details on error handling or the exact criteria for 'nearby incomplete task,' leaving minor 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 the baseline is 4. The description appropriately adds no parameter information since none are needed, focusing instead on behavioral aspects. No compensation is required for missing parameter details.

  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 current task as COMPLETED') and resource ('current task'), distinguishing it from siblings like 'remove_task' (which deletes) and 'update_current_task' (which modifies). It explicitly mentions the 'living document approach' where tasks remain visible, providing clear differentiation.

  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 alternatives: 'Use switch_focus to work on any specific task instead' and 'Use remove_task to clean up workspace later.' It also implies usage context by noting that focus automatically moves to a nearby incomplete task after completion.

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