Server Quality Checklist

Tool Scores

• create_goalC
  2/5.0
  Behavior1/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 but fails completely. 'Create a new goal' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether creation is idempotent, what happens on failure, what the response contains, or any side effects. For a mutation tool with zero annotation coverage, this is critically inadequate.

  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 maximally concise at just three words. While it's severely under-specified in terms of content, it's not verbose or poorly structured. Every word earns its place, and there's no wasted text. The extreme brevity represents efficient communication, even if the content is inadequate.

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

  Completeness1/5

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

  Given this is a mutation tool (creating new goals) with no annotations, no output schema, and sibling tools that suggest this is part of a task/goal management system, the description is completely inadequate. It doesn't explain what a 'goal' represents in this system, how it relates to tasks, what happens after creation, or what the agent should expect as a result. The description fails to provide the contextual understanding needed for effective tool 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 schema description coverage is 100%, with both parameters well-documented in the schema itself. The description adds no parameter information beyond what the schema already provides. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

  Purpose2/5

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

  The description 'Create a new goal' is essentially a tautology that restates the tool name without providing meaningful context. It doesn't specify what type of goal (software development goal as indicated in the schema), what system it creates it in, or how it differs from sibling tools like 'add_tasks' or 'complete_task_status'. The description lacks the specificity needed to distinguish this tool's purpose.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or how this tool relates to sibling tools like 'add_tasks' (which might add tasks to existing goals) or 'get_tasks' (which retrieves tasks). The agent receives no help in determining when this specific creation tool is appropriate.

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

• complete_task_statusC
  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 mentions that responses return simplified task objects without certain fields, which adds some context about output behavior. However, it fails to disclose critical traits like whether this is a mutation (implied by 'Update'), permission requirements, error handling, or side effects on child tasks beyond the parameter description.

  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 important details about ID format and response format. Both sentences earn their place by providing necessary context. It avoids redundancy and is appropriately sized for a tool with three parameters.

  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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (e.g., authentication needs, side effects), error conditions, and typical usage patterns. While it covers ID format and response simplification, it doesn't compensate for the absence of structured data about the tool's operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning the dot-notation format for task IDs, which is useful but not essential since the schema provides an example. No additional semantic context is given for parameters like 'goalId' or 'completeChildren' beyond what's in the schema.

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

  Purpose4/5

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

  The description clearly states the verb 'Update' and resource 'completion status of tasks', making the purpose immediately understandable. It distinguishes from siblings like 'add_tasks' or 'remove_tasks' by focusing on status modification rather than creation or deletion. However, it doesn't explicitly contrast with 'get_tasks' for read vs. write operations.

  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 'add_tasks' or 'remove_tasks'. The description mentions task ID format and response format but offers no context about prerequisites, error conditions, or typical scenarios for invoking this tool. Usage is implied only through the action of updating status.

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

• get_tasksB
  3.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 adds useful context beyond the input schema: it explains the dot-notation for task IDs and describes how 'includeSubtasks' affects response structure (hierarchical vs. simplified objects). However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a mutation-free but data-retrieval tool.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, with the core purpose stated first. Both sentences add value: the first explains task ID format, and the second details response variations based on 'includeSubtasks.' There's no wasted text, though it could be slightly more structured (e.g., bullet points for clarity).

  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 moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers key behavioral aspects like response formatting but omits details on permissions, error cases, or output structure. Without an output schema, more guidance on return values would be beneficial, but it's adequate for basic 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 input schema fully documents all parameters. The description adds marginal value by clarifying the dot-notation format for task IDs and the effect of 'includeSubtasks' on response objects, but it doesn't provide additional syntax or meaning beyond what the schema already covers. 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.

  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 tasks for a goal.' It specifies the verb ('Get') and resource ('tasks for a goal'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_tasks' or 'remove_tasks' beyond the basic verb distinction, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'add_tasks' for adding tasks or 'complete_task_status' for updating status) or clarify scenarios where this tool is preferred. Usage is implied only by the action 'Get,' with no explicit context or exclusions provided.

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

• add_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 of behavioral disclosure. It effectively describes key behavioral traits: the transactional nature (all-or-nothing success/failure) and the hierarchical structure handling (including parentId usage for existing tasks). It does not cover aspects like authentication needs, rate limits, or error handling, but provides substantial operational context beyond basic purpose.

  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 three sentences that each earn their place: the first states the core purpose, the second explains hierarchical and parentId usage, and the third discloses transactional behavior. There is no wasted text, and it efficiently conveys essential information.

  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 of a batch write operation with hierarchical data and no annotations or output schema, the description is largely complete. It covers purpose, usage context, and key behavioral traits like transactionality. However, it lacks details on response format, error cases, or prerequisites (e.g., goal existence), which would be helpful for full contextual understanding.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters ('goalId' and 'tasks') and their nested properties thoroughly. The description adds some semantic context by explaining the hierarchical structure and 'parentId' usage, but does not provide significant additional meaning beyond what the schema specifies, such as format examples or constraints not in the schema.

  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 ('Add multiple tasks to a goal') and resource ('tasks'), distinguishing it from siblings like 'create_goal' (different resource), 'get_tasks' (read vs write), 'complete_task_status' (update vs create), and 'remove_tasks' (delete vs add). It also specifies the hierarchical capability, which further differentiates it.

  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: for adding multiple tasks in a batch, including hierarchical structures. It explicitly mentions using 'parentId' for children of existing tasks, which helps differentiate from creating new subtasks within the batch. However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as using 'create_goal' for goals instead of tasks.

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

• remove_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 so effectively. It discloses key behavioral traits: the soft-delete mechanism (tasks remain in system), the dot-notation for task IDs, the simplified response format (excluding specific fields), and how soft-deleted tasks are handled in 'get_tasks' (excluded by default unless a parameter is set). It does not cover aspects like error handling or permissions, but provides substantial context beyond basic functionality.

  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, starting with the core action and key details (soft-delete, task ID format, response format). Every sentence adds value, with no redundant or unnecessary information, 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.

  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 (mutation with soft-delete behavior), no annotations, and no output schema, the description is largely complete. It explains the operation, task ID format, response format, and interaction with 'get_tasks'. However, it lacks details on error scenarios (e.g., what happens if 'goalId' is invalid) and does not describe the output structure beyond mentioning simplified objects, which could be improved 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?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as mentioning 'task IDs use a dot-notation' which aligns with the schema's example, but does not provide additional meaning or usage details for parameters like 'goalId' or 'deleteChildren'. Baseline 3 is appropriate as 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 specific action ('soft-delete multiple tasks from a goal'), distinguishes it from permanent deletion by explaining tasks are 'marked as deleted but remain in the system', and differentiates from siblings like 'get_tasks' by focusing on removal rather than retrieval or creation.

  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 (for soft-deleting tasks) and implicitly suggests alternatives by mentioning 'get_tasks' with 'includeDeletedTasks' for viewing deleted tasks. However, it does not explicitly state when NOT to use it or compare it directly to other sibling tools like 'add_tasks' or 'complete_task_status'.

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