Server Quality Checklist

Tool Scores

• create_docC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new doc' which implies a write/mutation operation, but doesn't disclose permissions needed, whether it's idempotent, error conditions, or what happens on success (e.g., returns a doc ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it could be slightly more structured (e.g., separating required vs optional parameters). Every part earns its place, making it concise and clear.

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

  Completeness2/5

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

  Given this is a mutation tool (create) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a doc object or ID), error handling, or dependencies like folder existence. For a 3-parameter creation tool, more context is needed to guide the agent effectively.

  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 all three parameters (title, text, folder). The description adds minimal value by listing the parameters but doesn't provide additional semantics like format examples or constraints beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Create') and resource ('new doc in Dart'), and specifies what can be configured (title, text content, folder). It distinguishes from siblings like update_doc or delete_doc by focusing on creation. However, it doesn't explicitly differentiate from other creation tools like create_task, which would require a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., folder existence), when not to use it, or compare it to siblings like create_task for task-related docs. This leaves the agent without contextual usage cues.

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

• create_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a task but doesn't mention potential side effects (e.g., notifications sent, audit logs), error conditions, or response format. This is inadequate for a mutation tool with complex parameters.

  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 a single, efficient sentence that front-loads the core action and enumerates key parameters. It avoids redundancy but could be slightly more structured by grouping related fields or highlighting required ones.

  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 complex mutation tool with 15 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects, error handling, or return values, leaving significant gaps for an AI agent to invoke it correctly.

  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 lists parameter fields (e.g., title, description, status) but doesn't add meaningful semantics beyond what the schema already provides (100% coverage). It serves as a high-level overview without clarifying interdependencies or usage nuances, meeting 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 verb ('Create') and resource ('new task in Dart'), making the purpose evident. However, it doesn't explicitly differentiate this tool from sibling tools like 'update_task' or 'list_tasks', which would be needed for 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 (e.g., 'update_task' for modifications, 'list_tasks' for retrieval). It also lacks prerequisites, such as required permissions or dependencies, leaving usage context unclear.

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

• get_docC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'retrieves' and 'returns' information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, or what happens with invalid IDs (e.g., errors vs. null returns). For a retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior 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.

  Conciseness4/5

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

  The description is concise and front-loaded, with two sentences that directly state the purpose and return value. Every sentence earns its place by specifying the action (retrieve by ID) and output (doc information including title, text, folder). However, it could be slightly more structured by explicitly listing key return fields or adding usage hints without becoming verbose.

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

  Completeness3/5

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

  Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return scope but lacks details on error handling, authentication needs, or how it fits with sibling tools. Without an output schema, it hints at return values but doesn't fully specify them, leaving room for improvement in completeness.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'id' parameter well-documented in the schema (12-character alphanumeric ID). The description adds no additional parameter semantics beyond what the schema provides, such as examples of IDs or where to obtain them. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the verb 'retrieve' and resource 'existing doc by its ID', specifying it returns doc information. It distinguishes from siblings like create_doc, delete_doc, update_doc, and list_docs by focusing on single-doc retrieval rather than creation, deletion, modification, or listing. However, it doesn't explicitly differentiate from get_folder or get_task, which are similar retrieval operations for other resources.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_doc over list_docs (e.g., for a specific known ID vs. browsing), or how it relates to get_folder (which might retrieve folder info containing docs). There's no context about prerequisites, such as needing a valid doc ID from list_docs or other sources.

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

• get_folderC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying it's read-only, but doesn't clarify permissions, error handling, or rate limits. The description adds some context about what information is returned, but lacks details on behavioral traits like whether it's idempotent or if it requires authentication.

  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 concise and front-loaded, with two sentences that efficiently convey the purpose and output. There's no wasted text, but it could be slightly more structured by separating usage guidelines or behavioral details into distinct parts.

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

  Completeness3/5

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

  Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is moderately complete. It covers the basic purpose and output but lacks usage guidelines and behavioral transparency. Without annotations or an output schema, more detail on error cases or return format would improve completeness for this read 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%, with the input schema fully documenting the 'id' parameter (including pattern and type). The description adds minimal value beyond the schema by mentioning 'ID' but doesn't provide additional semantics like examples or edge cases. Baseline score of 3 is appropriate as the schema handles most of 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: 'Retrieve an existing folder by its ID' specifies the verb (retrieve) and resource (folder), and 'Returns the folder's information including title, description, and all docs within it' details the output. However, it doesn't explicitly differentiate from sibling tools like 'get_doc' or 'get_view', which also retrieve resources by ID.

  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 like 'list_docs' for browsing folders or 'get_doc' for retrieving individual documents, nor does it specify prerequisites such as needing a valid folder ID. Usage is implied but not explicitly stated.

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

• get_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation and describes the return content, but lacks critical details: whether authentication is required, if there are rate limits, error handling for invalid IDs, or if the operation is idempotent. For a read operation with zero annotation coverage, this leaves significant gaps.

  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 a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating retrieval details from return content, but it avoids redundancy and wastes no words.

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

  Completeness3/5

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

  For a simple retrieval tool with one well-documented parameter and no output schema, the description is minimally adequate. It covers what the tool does and what it returns, but lacks behavioral context (e.g., permissions, errors) and usage guidance relative to siblings, leaving room for improvement.

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

  Parameters3/5

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

  The input schema has 100% description coverage, fully documenting the 'id' parameter with its format and requirement. The description adds no additional parameter semantics beyond implying the ID is for task retrieval, which the schema already covers. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 'Retrieve' and the resource 'an existing task by its ID', specifying it returns task information. However, it doesn't explicitly differentiate from sibling tools like 'get_doc' or 'get_folder', which have similar retrieval patterns for different resources.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_tasks' (for browsing tasks) or 'get_doc' (for retrieving documents). It mentions retrieving by ID but doesn't clarify prerequisites or when this is the appropriate choice over other get_* tools.

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

• list_docsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions filtering capabilities, it doesn't describe important behavioral aspects like whether this is a read-only operation, pagination behavior (implied by limit/offset but not explained), rate limits, authentication requirements, or what happens when no filters are applied. The description is insufficient for a tool with 10 parameters and no annotation coverage.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences that efficiently convey the core functionality. It's front-loaded with the main purpose and follows with filtering capabilities. No wasted words, though it could be slightly more structured.

  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 tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (document list format), doesn't mention pagination behavior despite having limit/offset parameters, and provides minimal behavioral context. The description should do more to compensate for the lack of structured metadata.

  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 'filter by folder, title, text content, and more' but doesn't provide additional context beyond what's in the schema. 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 as 'List docs from Dart' with optional filtering, which is a specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'list_tasks' or 'list_task_comments' beyond mentioning 'docs' specifically.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_doc' (for single document retrieval) or 'list_tasks' (for different resource types). It mentions filtering capabilities but doesn't explain when filtering is appropriate or when other tools might be better suited.

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

• list_task_commentsC
  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 full burden for behavioral disclosure. While 'List' implies a read operation, the description doesn't address critical behavioral aspects like pagination behavior (beyond mentioning parameters), rate limits, authentication requirements, or what happens when no comments match filters. It mentions filtering but lacks operational context.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences that efficiently communicate core functionality. The first sentence states the primary purpose, and the second highlights filtering capabilities. No wasted words, though it could be slightly more structured for clarity.

  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 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain return format, error conditions, or operational constraints. For a complex filtering tool with rich parameters, more context about behavior and results is needed to guide 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?

  Schema description coverage is 100%, providing detailed parameter documentation. The description adds minimal value by listing filter types (author, task, text content, dates) but doesn't explain parameter interactions, default behaviors, or provide examples beyond what's in the schema. With high schema coverage, baseline 3 is appropriate.

  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 as 'List comments from Dart' with filtering capabilities, providing a specific verb ('List') and resource ('comments from Dart'). However, it doesn't explicitly differentiate from sibling tools like 'get_task' or 'add_task_comment', which would require a more specific distinction to earn a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It mentions filtering parameters but doesn't specify scenarios where this tool is preferred over other comment-related operations or list operations like 'list_tasks'. 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.

• list_tasksC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering but doesn't describe pagination behavior (implied by limit/offset parameters), authentication requirements, rate limits, or what happens when no filters are provided. For a list operation with 24 parameters, this leaves significant behavioral gaps.

  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 brief (two sentences) and front-loaded with the core purpose. The second sentence efficiently lists key filter categories without being exhaustive. There's no wasted verbiage, though it could be slightly more structured.

  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 tool with 24 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, pagination strategy, error conditions, or how multiple filters interact. The agent would need to guess about important behavioral aspects despite the comprehensive parameter 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?

  The description mentions filtering by assignee, status, dartboard, priority, due date 'and more,' which partially maps to the 24 parameters. However, with 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema, meeting the baseline for high 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 verb ('List') and resource ('tasks from Dart'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_task' or 'list_docs' beyond the resource type, 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 like 'get_task' (for single task retrieval) or 'list_docs' (for different resource types). It mentions filtering capabilities but doesn't help the agent choose between this and other list/retrieval tools in the sibling set.

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

• update_docC
  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 full burden. It states this is an update operation (implying mutation) but doesn't disclose behavioral traits like permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Update an existing doc') and specifies modifiable fields. There is no wasted verbiage, and every word contributes to understanding the tool's function.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral constraints. While the schema covers parameters well, the overall context for safe and effective use is lacking, especially for an update 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 fully documents all four parameters (id, title, text, folder). The description lists modifiable fields ('title, text content, and folder'), which aligns with the schema but adds no additional semantic context beyond what's already in the parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Update') and resource ('an existing doc'), and specifies what can be modified ('title, text content, and folder'). It distinguishes from creation tools like 'create_doc' by emphasizing 'existing'. However, it doesn't explicitly differentiate from other update tools like 'update_task' beyond the resource name.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the doc ID), when not to use it (e.g., for creating new docs), or compare it to sibling tools like 'update_task'. Usage is implied through the action and resource but not explicitly stated.

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

• update_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose critical behavioral traits such as required permissions, whether changes are reversible, error handling, or rate limits. The description mentions what can be modified but lacks operational context needed for safe and effective use.

  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 a single, efficient sentence that front-loads the core action ('Update an existing task') and follows with a comprehensive list of modifiable properties. There's no wasted text, and it's appropriately sized for the tool's complexity. However, it could be slightly more structured by separating core and optional updates.

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

  Completeness2/5

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

  Given the tool's complexity (16 parameters, mutation operation, no annotations, no output schema), the description is incomplete. It covers what can be updated but lacks essential context such as response format, error conditions, side effects, or dependencies. For a mutation tool with rich parameters, this leaves significant gaps for an AI agent to use it correctly.

  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%, meaning all parameters are documented in the schema itself. The description adds minimal value beyond the schema by listing some updatable properties (e.g., 'title, description, status'), but doesn't provide additional syntax, format details, or constraints. This meets the baseline of 3 when the schema does the heavy lifting.

  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 ('an existing task'), and specifies the scope of modifications ('any of its properties including title, description, status, priority, dates, assignees, tags, custom properties, and task relationships'). It distinguishes from sibling tools like 'create_task' by focusing on updates rather than creation, though it doesn't explicitly compare to other update tools like 'update_doc'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the task ID), when not to use it (e.g., for deleting tasks), or how it differs from other update tools like 'update_doc'. Usage is implied through the action 'update an existing task', but no explicit context or exclusions are provided.

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

• get_configB
  3.1/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 describes what data is returned but lacks critical behavioral details: it does not mention whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, rate limits, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded: it starts with the core purpose ('Get information about the user's space') and follows with specifics on included data. Both sentences earn their place by clarifying scope, though it could be slightly more structured (e.g., bullet points for the list). No wasted words or 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 (configuration retrieval with multiple data types), lack of annotations, and no output schema, the description is moderately complete. It specifies what information is included but misses behavioral context (e.g., safety, format) and does not explain the return structure. This is adequate for a read operation but leaves gaps for an agent to infer usage.

  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 schema description coverage is 100% (empty schema). The description does not need to add parameter semantics, so it appropriately focuses on the tool's purpose and output. Baseline is 4 for zero parameters, as the description compensates by explaining what the tool returns without parameter distractions.

  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 information about the user's space' with a specific list of included data types (assignees, dartboards, folders, etc.). It uses a specific verb ('Get') and resource ('user's space'), but does not explicitly distinguish it from sibling tools like 'get_dartboard' or 'get_folder' that fetch specific resources rather than comprehensive configuration.

  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 mentions that the information 'can be provided to other endpoints,' but does not specify scenarios (e.g., for setup, reference, or filtering) or exclusions compared to sibling tools like 'get_dartboard' or 'list_tasks' that might overlap in data retrieval.

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

• get_dartboardB
  3.1/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 a retrieval operation and describes the return content, but it lacks critical details such as error handling (e.g., what happens if the ID is invalid), authentication needs, rate limits, or whether it's a read-only operation. This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's function and return value without any wasted words. Every sentence earns its place by providing essential information efficiently.

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

  Completeness3/5

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

  Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return content, but it lacks completeness in areas like error handling, authentication, or comparison to siblings, which would be helpful for an agent to use it correctly in context.

  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, clearly documenting the single required parameter 'id' with its format. The description adds no additional parameter semantics beyond what the schema provides, such as examples or context on where to find the ID. This meets the baseline score when schema coverage is high.

  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 with a specific verb ('Retrieve') and resource ('an existing dartboard by its ID'), and it distinguishes this from sibling tools like 'get_doc' or 'get_task' by specifying it returns dartboard information including tasks. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_view' might be similar), keeping it from a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid dartboard ID, or compare it to other retrieval tools like 'get_doc' or 'get_task', leaving the agent to infer usage from context alone.

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

• get_viewB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves by ID and returns view information including title, description, and tasks, which adds useful behavioral context beyond the schema. However, it doesn't cover aspects like error handling, permissions, or rate limits, leaving gaps for a tool with no annotations.

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

  Conciseness5/5

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

  The description is front-loaded and efficient: two sentences that directly state the action and return value without waste. Every sentence earns its place by conveying essential information clearly and succinctly.

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

  Completeness3/5

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

  Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and what it returns, but lacks details on error cases, permissions, or integration with siblings. Without annotations or output schema, more context would improve completeness for safe agent use.

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

  Parameters3/5

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

  The input schema has 100% description coverage, documenting the ID parameter's format and requirement. The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples or edge cases). According to the rules, with high schema coverage, the baseline is 3 even with no param info in the description.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Retrieve an existing view by its ID' specifies the verb (retrieve) and resource (view). It distinguishes from siblings like get_task or get_doc by focusing on views, though it doesn't explicitly contrast with them. The description is specific but lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use get_view over other get_* tools (e.g., get_task, get_doc) or list_tasks, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly stated.

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

• add_task_commentA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that comments support markdown formatting, which is useful behavioral context. However, it lacks details on permissions, rate limits, or response format, leaving gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is front-loaded and concise, consisting of two sentences that efficiently convey the tool's purpose and key feature (markdown support) without any wasted words. Every sentence earns its place.

  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 (a mutation with two parameters) and no annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and markdown support, but lacks details on behavioral aspects like error handling or return values, which are important for an agent.

  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 (taskId and text) thoroughly. The description adds minimal value by mentioning markdown formatting for the text parameter, but does not provide additional semantics beyond what the schema offers.

  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 a comment') and resource ('to an existing task'), distinguishing it from sibling tools like create_task, update_task, and list_task_comments. It explicitly notes that it does not modify the task description, which further clarifies 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 provides clear context by specifying that comments are added to existing tasks, implying when to use it (after task creation). However, it does not explicitly state when not to use it or name alternatives, such as using update_task for modifying the task description instead.

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

• delete_docA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the action is reversible ('can be recovered'), non-destructive to doc content ('Nothing else about the doc will be changed'), and specifies the outcome (moved to trash). However, it lacks details on permissions, error conditions, or confirmation prompts.

  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 with zero waste: the first states the core action and recoverability, the second clarifies side effects. It is front-loaded with essential information and appropriately sized for a single-parameter tool.

  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 (mutation with recovery), no annotations, and no output schema, the description is largely complete: it covers purpose, behavior, and limitations. However, it omits details like return values or error handling, which would be beneficial 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 the 'id' parameter's format and requirement. The description adds no additional parameter semantics beyond what the schema provides, such as examples or contextual meaning, meeting 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 ('Move to the trash') and resource ('an existing doc'), distinguishing it from siblings like 'delete_task' (different resource) and 'update_doc' (different action). It precisely defines what the tool does without being vague or tautological.

  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 moving docs to trash rather than permanent deletion, but does not explicitly state when to use this tool versus alternatives like 'update_doc' or 'delete_task'. No guidance is provided on prerequisites or exclusions, leaving usage context partially inferred.

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

• delete_taskA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a destructive operation (moving to trash), reversible (can be recovered), and idempotent (nothing else changes). It doesn't cover error conditions or permissions, but for a simple delete tool, this is reasonably comprehensive.

  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 concise sentences with zero waste: the first states the core action and recovery option, the second clarifies side effects. It's front-loaded with the primary purpose and appropriately sized for a single-parameter tool.

  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 low complexity (one parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, behavior, and recovery, though it lacks details on error responses or confirmation prompts. For a basic deletion tool, this is sufficient but not exhaustive.

  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 'id' parameter. The description doesn't add any parameter-specific details beyond what the schema provides, such as example IDs or context about task identification. 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 specific action ('Move to the trash') and resource ('existing task'), distinguishing it from siblings like delete_doc (which deletes documents) and update_task (which modifies tasks). It precisely communicates what the tool does without being vague or tautological.

  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 specifying 'existing task' and mentioning recovery, suggesting it's for soft deletion rather than permanent removal. However, it doesn't explicitly state when to use this vs. alternatives like update_task for status changes or delete_doc for document deletion, leaving some ambiguity in sibling tool selection.

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