Server Quality Checklist

Tool Scores

• get_my_workA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the burden. It discloses the scope (all open tasks assigned to the user) and grouping logic (overdue/today/this week/later), which is useful. However, it does not mention the effect of include_closed on grouping, potential large volumes, or explicitly state that the operation is read-only.

  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 long, front-loaded with the core functionality and followed by specific usage scenarios. Every sentence serves a purpose with no redundancy.

  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 simplicity (one optional boolean parameter, no output schema), the description is sufficiently complete: it covers what the tool does, the grouping, and when to use it. It does not describe the return format or explicitly contrast with search_tasks, but these are minor omissions for a personal task list 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?

  The schema covers 100% of parameters, including a clear description of include_closed with its default. The tool description adds no additional parameter-specific semantics, so it stays at the baseline of 3.

  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 function: it returns every open task assigned to the user, grouped by overdue/today/this week/later. It differentiates itself from siblings by focusing on personal tasks across the whole workspace, making it distinct from search_tasks or get_task.

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

  Usage Guidelines4/5

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

  The description explicitly names use cases: standup, 'what's on my plate', and backlog sweep, positioning this as the go-to tool for these. It does not explicitly exclude alternatives, but the strong recommendation gives clear contextual guidance.

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

• update_taskA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. It adds valuable info about bulk updates and per-item reporting ('Each update is reported individually'). However, it does not disclose whether updates are partial replacements, how errors are handled, or any permission requirements, leaving gaps for a mutating 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 two sentences long, immediately states the core action, and each sentence adds value: the first lists what can be updated, the second explains bulk behavior and reporting. No redundant or filler content.

  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 moderate complexity (nested update object with multiple fields) and no output schema, the description provides adequate context: it clarifies bulk usage and per-item results. It could improve by explaining partial update semantics or return format, but the current level is sufficient for an AI agent to understand the tool's basic behavior.

  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 has 0% description coverage, so the description must compensate. It maps some fields via examples (status, assignees, due dates, renames) and explains the 'updates' array for bulk usage. Yet it does not elaborate on nuanced parameters like add_assignees vs remove_assignees, archived, or priority, leaving the agent to infer from the schema alone.

  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 function: updating existing tasks, with specific examples (status changes, re-assignment, due dates, renames). It distinguishes from sibling create_task by emphasizing 'existing tasks' and from search/get tools by focusing on mutation.

  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 that this tool is for modifying existing tasks, which implies using create_task for new tasks. It also gives specific usage guidance: 'Pass the whole array for a bulk change.' However, it does not explicitly name alternatives or state when NOT to use the tool, so it falls short of a 5.

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

• create_taskA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description must disclose behavior on its own. It reveals that each task is reported individually and that a single failure does not abort others, which is valuable operational knowledge. It does not go into idempotency or permissions, but this partial-failure semantics raises it above a bare 'create' statement.

  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?

  A single sentence conveys creation, batch capability, a use case, and failure behavior—no redundant words. 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 the nested array schema and absence of output schema, the description gives the critical behavior (non-atomic batch creation) and a use case. It does not elaborate on return format beyond 'reported individually', but that suffices given the simplicity. It hints at when to use it (backlog creation) but doesn't cover all preconditions.

  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 'the whole array' but not individual fields. The schema provides descriptions for parent, status, list_id, due_date, priority, and assignees, so the bulk of parameter meaning comes from the schema. The description adds only the batch nuance, hence a mid score.

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

  Purpose5/5

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

  The description uses the verb 'Create' with 'tasks' and clarifies scope ('one or many in one go'). It distinguishes from repeated calls by suggesting array usage, which separates it from other task operations. The example use case ('breaking a discussion into a backlog') further anchors its purpose.

  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 tells the agent to pass the whole array and avoid repeated calls, implying batch creation is preferred. It does not explicitly name alternative sibling tools, so exclusions are absent. The context is clear for the creation scenario.

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

• search_tasksA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It does mention that 'Paginates automatically and says so if it hits the cap' and that filters combine, which is valuable. But it omits other relevant behaviors such as default ordering, potential rate limiting, or how results are returned, leaving some gaps in the behavioral profile.

  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 purpose, and every phrase earns its place. It conveys purpose, scope, filter semantics, and pagination behavior without any fluff or redundancy.

  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 (12 parameters) and lack of output schema, the description covers the primary use case, scope, filter combination, and pagination behavior. It does not detail the return format or edge cases, but for a query tool with strong schema-level parameter documentation, it provides sufficient context to guide invocation. It is not over-stuffed but leaves a few areas for further clarification.

  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 83% (baseline 3). The description adds meaningful semantics beyond the schema: 'Every filter is optional and they combine' clarifies AND logic, and 'Paginates automatically' contextualizes max_pages. These additions go beyond the static parameter descriptions, enriching the model's understanding.

  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 'Filtered task query across the entire workspace in one request', which identifies the specific verb (search/filter) and resource (tasks) with a clear scope (entire workspace). It also distinguishes itself from siblings like get_task and get_my_work by emphasizing its role for reports/analytics across all tasks.

  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 it ('the tool to build any report or analytics on') and explains that every filter is optional and combines, which helps define its usage. However, it stops short of explicitly naming alternatives like 'use get_task for a single task' or stating exclusions, so it lacks explicit when-not guidance.

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

• get_workspace_mapA
  4.4/5.0
  Behavior4/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 adds valuable behavioral context by disclosing the 15-minute caching mechanism and the specific data types returned, including the user ID. However, it doesn't explicitly mention read-only semantics, permissions, or error conditions, which are minor gaps.

  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?

  Two concise sentences, front-loaded with the core content. The first sentence states what is returned, while the second adds usage guidance and caching behavior. No 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?

  Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the return contents and caching behavior. It could be more explicit about the return structure, but the list of included items is sufficient for an agent to know what to expect.

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

  Parameters3/5

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

  Schema coverage is 100% for the single optional boolean parameter, and the schema description already explains its purpose and cost. The tool description adds no additional parameter-level detail, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the workspace's spaces, folders, lists (with status names), members, and user ID. This is a specific verb+resource description that distinguishes it from sibling task-focused tools, and the 'Call this first' guidance reinforces its role as an ID lookup.

  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?

  Explicitly instructs to call this first when needing an ID for any other tool, establishing a clear usage context. The caching note also implies repeat calls are efficient, giving practical guidance. It doesn't mention when not to use, but the primary use case is clearly stated.

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

• get_taskA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It discloses what data is returned (description, custom fields, subtasks, optional comments) and notes that comments are optional. It does not detail error behavior or auth requirements, but for a simple read operation this is adequate context.

  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?

  Two sentences, front-loaded with the core purpose, and the usage guidance is a single concise clause. No wasted words or repetition of schema details.

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

  Completeness5/5

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

  For a simple single-task retrieval tool with two parameters and no output schema, the description sufficiently explains what it returns and when to invoke it. It does not need to describe return structure since it lists the main fields, and the output schema is absent by design.

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

  Parameters3/5

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

  Schema coverage is 50%: include_comments has a description ('Costs one extra request. Default false.'), but task_id has only a type. The description adds the semantic of 'one task' but does not elaborate on task_id format. The optional comments behavior is echoed but not expanded beyond 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 uses a specific verb ('get') and resource ('one task'), clearly distinguishing it from siblings like search_tasks (which narrows down) and get_my_work. It enumerates the returned components: description, custom field values, subtasks, and optionally comments.

  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?

  Explicitly states when to use it: 'after search_tasks or get_my_work has narrowed things down to a single task.' This gives clear context and implies it is not for bulk listing or discovery.

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