Server Quality Checklist

Tool Scores

• create_taskC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavioral traits. It mentions returns but does not address side effects, authorization needs, rate limits, or error handling. The description is minimal and lacks important details for safe invocation.

  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 short but includes a vague second paragraph about parameters that adds little value. It is not overly verbose but could be rephrased to be more direct while remaining concise.

  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?

  While an output schema exists (not fully shown), the description omits error conditions, authentication requirements, or typical usage scenarios. For a task creation tool, more context is needed to ensure correct invocation.

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

  Parameters1/5

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

  The schema description coverage is 0%, meaning the description does not explain any parameter beyond referencing the nested type name 'CreateTaskRequest'. It fails to add meaningful context about individual parameters such as list_id, name, or assignees, leaving the agent to interpret 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 explicitly states 'Create a new task in a list.' This clearly indicates the verb (create), resource (task), and context (in a list). It distinguishes itself from sibling tools like delete_task, get_task, update_task, and list_tasks.

  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, nor are there any prerequisites or exclusions mentioned. The description simply states what it does without contextual usage hints.

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

• get_taskC
  2.7/5.0
  Behavior2/5

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

  No annotations provided, so description must disclose behavior. It only states 'Returns: Task details from ClickUp API', missing important aspects like auth requirements, rate limits, and that this is a read-only operation. Does not mention error handling or response structure beyond vague 'details'.

  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 short (two sentences) and conveys the basic purpose, but lacks structure. It could benefit from clearly labeling sections like 'Parameters' and 'Returns' instead of inline text.

  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 an output schema exists, the description need not detail returns, but it still provides a vague mention. It omits important context such as the dependency between custom_task_ids and team_id, and does not explain potential error scenarios. Adequate for a simple retrieval tool but not complete.

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

  Parameters2/5

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

  The description merely lists parameter names from the schema ('task_id, custom_task_ids, and team_id') without adding meaning. The schema already provides descriptions for these sub-parameters, so the tool description adds no additional value. With 0% schema description coverage at top-level, the description should compensate but fails.

  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 'Get a specific task by ID', which is a specific verb-resource pair. It implicitly distinguishes from siblings like list_tasks (retrieves multiple) and update_task (modifies), but does not explicitly differentiate.

  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 on when to use this tool versus alternatives (e.g., list_tasks for multiple tasks). No mention of prerequisites or contextual conditions like requiring team_id when custom_task_ids is true.

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

• delete_taskC
  2.9/5.0
  Behavior2/5

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

  No annotations provided. Description does not disclose irreversible nature, permissions required, or side effects beyond 'delete'.

  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?

  Succinct description in bullet points, no unnecessary words. Could benefit from slightly more structure (e.g., separating behavior from params).

  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?

  Despite output schema existing, description omits deletion behavior (e.g., permanent, cascading effects). Incomplete for a destructive action.

  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%, yet description merely lists parameter names without adding meaning or context 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?

  Description clearly states 'Delete a task', a specific verb+resource, and distinguishes from sibling tools (create, get, list, update).

  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 on when to use versus alternatives (e.g., update_task). No prerequisites or exclusions provided.

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

• update_taskB
  3.1/5.0
  Behavior2/5

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

  The description only states 'Update an existing task' and 'Returns updated task details.' No annotations exist to carry behavioral context, so the description must disclose side effects, authentication needs, or rate limits. It fails to do so, offering minimal transparency.

  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 brief (three sentences plus a parameter line) and front-loaded with purpose. It includes a structured 'Parameters:' and 'Returns:' section, making it easy to scan. No excess text.

  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 moderate complexity (nested request object) and no annotations, the description should clarify that the task must exist, mention which fields are updatable, and describe the return format. It only gives a vague 'Updated task details' and omits error conditions or prerequisites.

  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 'request: UpdateTaskRequest with task_id and fields to update,' adding context beyond the schema name. However, the schema already describes fields individually. Since there is only one parameter and the description adds little new detail, a 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 'Update an existing task,' explicitly naming the verb (update) and resource (task). This distinguishes it from sibling tools like create_task, delete_task, and get_task, providing unambiguous purpose.

  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?

  There is no guidance on when to use this tool versus alternatives (e.g., create_task for new tasks, delete_task for removal). No preconditions or usage context are mentioned, leaving the agent without decision support.

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

• list_tasksA
  3.6/5.0
  Behavior3/5

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

  No annotations provided. The description states it returns a list of tasks, but does not disclose pagination behavior (e.g., that it returns one page at a time) or other side effects. The output schema partially compensates.

  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 brief, with one sentence stating purpose and a bullet list for parameters/returns. However, the parameter list is redundant with the schema, slightly reducing efficiency.

  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?

  The description fails to mention pagination details (page, limit) that are critical for using this tool correctly. It also omits authentication or rate limit info. However, output schema adds some 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?

  The description does not add significant meaning beyond the input schema, which already describes each parameter (e.g., list_id, pagination, status filter). Baseline 3 due to 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 'List tasks in a list with optional filtering', using a specific verb ('list') and resource ('tasks in a list'). It distinguishes from sibling tools like create_task, delete_task, and 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 Guidelines3/5

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

  The description implies usage for listing tasks with filtering, but lacks explicit guidance on when to use this tool vs alternatives (e.g., get_task for a single task). No exclusions or prerequisites are mentioned.

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

• get_userA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Clearly indicates read operation with no side effects, and mentions returned fields (id, email, name). Could mention rate limits but acceptable.

  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 efficient sentences, front-loaded with purpose. 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?

  Output schema exists but not shown; description partially covers returns (id, email, name). For zero-param tool, description is sufficient.

  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?

  No parameters exist, schema coverage is 100%. Baseline for 0 params is 4. Description adds no parameter info but none needed.

  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?

  Description clearly states 'Return the current ClickUp user profile' with specific verb and resource. Siblings are all task-related, so no confusion.

  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?

  Explicitly says 'Use this to verify authentication and retrieve your user details', providing clear context. No need for exclusions given sibling tools are unrelated.

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