Server Quality Checklist

Tool Scores

• create_columnC
  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 creation operation but doesn't mention permission requirements, rate limits, side effects, or what happens if the board doesn't exist. The authentication parameter hints at security needs, but the description doesn't explain authorization requirements or error conditions.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, Args, Returns) and uses minimal sentences. The opening statement is front-loaded with the core functionality. However, the Args section could be more concise by integrating parameter explanations into the main description rather than as a separate block.

  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 that there's an output schema (yokan_models.Column), the description doesn't need to detail return values. However, for a creation tool with 3 parameters and no annotations, the description should provide more behavioral context about permissions, errors, and constraints. It covers the basics but leaves significant gaps for safe and effective use.

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

  Parameters3/5

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

  The description includes an Args section that documents all three parameters with basic types, but schema description coverage is 0%, so the schema provides no additional documentation. The description adds value by naming and typing parameters, but doesn't explain constraints (e.g., name length limits, valid board_id ranges) or the AuthContext structure beyond what's in the schema definition.

  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 ('creates') and resource ('new column in a specified board'), making the purpose immediately understandable. It distinguishes from siblings like create_board or create_task by specifying the resource type. However, it doesn't explicitly differentiate from update_column or reorder_columns in terms of when to use each.

  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 (like needing an existing board), when not to use it, or how it differs from similar tools like update_column or reorder_columns. The agent must 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.

• delete_taskC
  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 'Deletes a task' which implies a destructive, irreversible mutation, but doesn't disclose behavioral traits like permissions needed (beyond auth param), confirmation prompts, cascading effects (e.g., if deletion affects other tasks), error handling, or rate limits. The description is minimal and lacks critical operational context for a destructive tool.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly, though they could be more integrated. There's minimal waste, but the formatting as a docstring-like block slightly reduces readability compared to plain prose.

  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 (destructive mutation with 3 params), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values (just 'None' without context), error conditions, side effects, or security implications. For a delete operation, this leaves significant gaps that could lead to misuse by 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 0%, so the description must compensate. It lists all three parameters with brief explanations: 'board_id' specifies the board containing the task, 'task_id' identifies the task to delete, and 'auth' provides authentication context. This adds basic meaning beyond the bare schema types, but doesn't detail format constraints (e.g., ID formats), validation rules, or how auth is used. It partially compensates for the coverage gap.

  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 ('Deletes') and resource ('a task from a board'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_board' or 'delete_column' by specifying the target is a task, not a board or column. However, it doesn't explicitly differentiate from 'move_task' or 'update_task' in terms of destructive nature.

  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., task must exist), when-not-to-use scenarios (e.g., if task is in progress), or direct alternatives among siblings like 'move_task' for relocation instead of deletion. The agent must infer usage from the name alone.

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

• move_taskC
  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 the action ('moves') but lacks behavioral details: it doesn't specify permissions needed (beyond auth), whether the move is reversible, error conditions (e.g., invalid IDs), or side effects (e.g., task history updates). This is inadequate for a mutation tool with zero 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 well-structured and appropriately sized: a clear purpose sentence followed by Args and Returns sections. Every sentence adds value, with no fluff. It could be slightly more front-loaded by integrating parameter hints into the purpose, but it's efficient overall.

  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 complexity (a mutation tool with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It covers the basic action and parameters but misses critical context: error handling, return values (beyond 'None'), permissions, and how it differs from sibling tools. This leaves the agent under-informed.

  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 0%, so the description must compensate. It lists all 4 parameters with brief explanations in the Args section, adding meaning beyond the bare schema (e.g., 'destination column' for new_column_id). However, it doesn't clarify parameter relationships (e.g., board_id must contain task_id) or constraints (e.g., ID formats), leaving gaps.

  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: 'Moves a task from one column to another.' This specifies the verb ('moves') and resource ('task'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'update_task' or 'reorder_columns', which might also involve task/column modifications.

  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., task/column existence), exclusions (e.g., invalid moves), or comparisons to sibling tools like 'update_task' (which might handle other task changes). The agent must infer usage from the purpose alone.

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

• update_boardC
  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. While 'Updates' implies a mutation, the description lacks details on permissions (e.g., who can update), side effects (e.g., if it affects other board properties), error handling, or rate limits. It only states the basic action without behavioral 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 well-structured and front-loaded with the core purpose. The 'Args' and 'Returns' sections are organized, but the 'auth' parameter explanation could be more specific (e.g., 'required for authentication'). Overall, it's efficient with minimal waste.

  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 mutation nature, 0% schema coverage, and no annotations, the description is moderately complete. It covers parameters and return value, but lacks behavioral details like error cases or permissions. The output schema exists, so return values are documented, but overall context for safe use is insufficient.

  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 0%, so the description must compensate. It lists all three parameters (board_id, name, auth) with brief explanations, adding meaning beyond the bare schema. However, it doesn't provide format details (e.g., name length limits) or deeper context for 'auth', leaving gaps in parameter understanding.

  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: 'Updates the name of a Kanban board.' It specifies the verb ('Updates') and resource ('name of a Kanban board'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'update_column' or 'update_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., needing an existing board), exclusions, or comparisons to siblings like 'update_column' or 'update_task'. This leaves the agent without context for tool selection.

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

• update_columnC
  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 an update operation but doesn't cover critical aspects like required permissions, whether changes are reversible, error conditions (e.g., invalid IDs), or side effects. The description adds minimal context beyond the basic action.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. It front-loads the purpose in the first sentence, followed by clear 'Args' and 'Returns' sections. Every sentence adds value, with no redundant information. Minor improvement could be made by integrating the sections more fluidly.

  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 (a mutation with 4 parameters), no annotations, and an output schema (which covers return values), the description is moderately complete. It explains the action and parameters but lacks behavioral details like error handling or permissions. The output schema reduces the need to describe returns, but more context on usage and constraints would enhance 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?

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description includes an 'Args' section that lists and briefly describes all four parameters, adding essential meaning (e.g., 'board_id' is for the containing board, 'name' is the new name). However, it doesn't elaborate on constraints (e.g., name length limits) or the 'AuthContext' structure beyond what's in the schema.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Updates the name of a column.' It specifies the verb ('Updates') and resource ('name of a column'), making the action explicit. However, it doesn't distinguish this from sibling tools like 'update_column_color' or 'update_board', which would require mentioning it's specifically for renaming columns.

  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 board/column IDs), exclusions, or comparisons to siblings like 'update_column_color' for color changes or 'reorder_columns' for position updates. Usage is implied only by the tool name and parameters.

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

• create_taskB
  3/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. It identifies this as a creation/mutation operation but doesn't disclose behavioral traits like required permissions, error conditions, rate limits, or whether the operation is idempotent. The auth parameter is mentioned but not explained in behavioral terms.

  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 appropriately sized but not optimally structured. The first sentence is clear, but the Args/Returns sections are verbose. Some information (like the Returns section) could be streamlined since an output schema exists.

  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 creation tool with no annotations, the description covers parameters well but lacks behavioral context. The existence of an output schema means return values don't need explanation, but other aspects like error handling, side effects, and usage context are incomplete.

  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?

  With 0% schema description coverage, the description compensates well by explaining all 6 parameters in the Args section, including data types, optionality, defaults, and examples (e.g., due date format). It adds meaning beyond the bare schema, though some parameter purposes could be clearer (e.g., auth context).

  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 ('Creates') and resource ('new task') with specific location context ('in a specified column'). It distinguishes from siblings like create_board or create_column by focusing on tasks, but doesn't explicitly contrast with create_tasks (plural).

  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 like create_tasks (batch creation) or update_task (modification). The description mentions the required board and column context but doesn't provide usage context, prerequisites, or exclusions.

  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?

  No annotations are provided, so the description carries full burden. It states this is an update operation but doesn't disclose behavioral traits like required permissions (implied by auth parameter but not explained), whether changes are reversible, what happens to unspecified fields, rate limits, or error conditions. The description adds minimal context beyond the basic operation.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by organized parameter and return sections. Every sentence earns its place, though the Returns section stating 'None' could be slightly more informative (e.g., 'Returns nothing on success').

  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 complexity (mutation tool with 7 parameters, no annotations, no output schema), the description is moderately complete. It covers parameters well but lacks behavioral context (permissions, side effects) and output details. For a mutation tool, this leaves gaps an agent would need to infer or test.

  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?

  With 0% schema description coverage, the description compensates well by explaining all 7 parameters in the Args section, including their types, optionality, defaults, and examples (e.g., due date format 'YYYY-MM-DD'). It adds meaningful semantics beyond what the bare schema provides, though it doesn't explain the AuthContext structure in detail.

  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: 'Updates the title, description, due date, and/or subtasks of an existing task.' This specifies the verb (updates) and the resource (task) with the specific fields that can be modified. However, it doesn't distinguish this from sibling tools like 'update_board' or 'update_column' beyond mentioning it operates on 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task), exclusions, or comparisons to sibling tools like 'move_task' or 'create_task'. The agent must infer usage from the purpose statement alone.

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

• create_boardB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the tool creates a new board but doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens on failure, or any rate limits. The mention of 'auth' parameter hints at authentication needs, but this isn't explicitly explained in the description text.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. The first sentence states the purpose clearly, followed by a parameter list and return value. Every sentence adds value, though the parameter descriptions could be slightly more concise (e.g., 'auth' explanation is minimal but adequate).

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

  Completeness4/5

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

  Given the tool's moderate complexity (creation operation with auth), no annotations, and an output schema that specifies the return type (int ID), the description is reasonably complete. It covers the core action and parameters, though it lacks behavioral context like error handling or side effects, which would be helpful for a mutation tool.

  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 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'name' is for the board name, 'auth' is for authentication context, and 'columns' is for initial column names. This goes beyond the bare schema, though it doesn't detail format constraints (e.g., length limits for name).

  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: 'Creates a new Kanban board with an optional list of initial column names.' It specifies the verb ('creates') and resource ('Kanban board'), distinguishing it from sibling tools like create_column or create_task. However, it doesn't explicitly differentiate from update_board or get_board beyond the action verb.

  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., authentication requirements), when not to use it, or how it relates to sibling tools like create_column (which might be used after board creation) or update_board (for modifying existing boards).

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

• create_tasksB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation operation but doesn't mention permissions needed, rate limits, error conditions, or whether it's idempotent. For a mutation tool with zero annotation coverage, 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.

  Conciseness5/5

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

  The description is efficiently structured with a clear opening sentence followed by well-organized Arg and Return sections. Every sentence adds value without redundancy, making it easy to parse and understand.

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

  Completeness3/5

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

  Given the tool's complexity (mutation with 4 parameters) and no annotations, the description covers parameters well and includes output information. However, it lacks behavioral context (permissions, errors) and sibling differentiation, making it incomplete for optimal agent use despite the output schema.

  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 0%, but the description compensates well by explaining all four parameters: board_id and column_id identify the location, tasks is a list with dictionary structure, and auth provides authentication context. It adds meaningful context beyond the bare schema types.

  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 ('Creates') and resource ('multiple new tasks in a specified column'), making the purpose explicit. However, it doesn't distinguish this tool from its sibling 'create_task' (singular), which creates ambiguity about when to use one versus the other.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'create_task' (singular). The description mentions the column context but doesn't specify prerequisites, constraints, or comparative scenarios with sibling tools.

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

• get_boardB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention authentication requirements, rate limits, error conditions, or what happens if the board doesn't exist. The description is minimal beyond stating the basic function.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (Args, Returns) and uses minimal words to convey the core information. However, the 'Args' and 'Returns' sections could be integrated more naturally into the flow rather than appearing as separate documentation blocks.

  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 has an output schema (yokan_models.Board) and no annotations, the description adequately covers the basic purpose and parameters but lacks important context about authentication behavior, error handling, and differentiation from sibling tools. It's minimally complete but with significant gaps for a 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 0%, so the description must compensate. It adds semantic meaning by explaining board_id is 'The ID of the board to retrieve' and auth is 'The authentication context containing user ID and token', which provides context beyond the bare schema. However, it doesn't fully compensate for the coverage gap with details on format constraints or auth requirements.

  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 ('Retrieves') and resource ('a specific Kanban board by its ID'), distinguishing it from sibling tools like get_boards (plural) and other CRUD operations. It precisely communicates the tool's function without ambiguity.

  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_boards, nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.

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

• get_columnsB
  3.3/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 it's a retrieval operation but doesn't mention authentication requirements (implied by the auth parameter), potential rate limits, error conditions, or whether it returns all columns or is paginated. The description is minimal beyond stating the basic function.

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

  Conciseness5/5

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

  The description is efficiently structured with a clear purpose statement followed by well-organized Args and Returns sections. Every sentence adds value: the first states the action, and the subsequent lines document inputs and outputs without 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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, parameters, and return type. The output schema handles return values, so the description doesn't need to detail them. However, it lacks behavioral context like error handling or usage constraints.

  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 description explicitly documents both parameters (board_id and auth) with their types and purposes, adding meaningful context beyond the schema's structural definition. Since schema description coverage is 0%, this parameter documentation is essential and well-handled, though it could elaborate on auth requirements (e.g., valid token needed).

  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 ('Retrieves') and resource ('all columns for a given board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_board' or 'get_tasks', which also retrieve data but 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. It doesn't mention prerequisites (e.g., needing a valid board_id), nor does it contrast with other retrieval tools like 'get_board' or 'get_tasks' that might be more appropriate in certain contexts.

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

• delete_boardB
  3.4/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 but only minimally describes behavior. It states the destructive action ('Deletes') and mentions authentication, but lacks critical details like permission requirements, whether deletion is permanent/reversible, side effects on related data, or error conditions.

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

  Conciseness4/5

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

  The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose, though the authentication explanation could be slightly more detailed given the lack of annotations.

  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 destructive operation with no annotations and 0% schema coverage, the description provides basic purpose and parameter semantics but lacks sufficient behavioral context. The output schema exists (Returns: int), so describing return values isn't needed, but critical mutation details are missing.

  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 0%, but the description compensates by explaining both parameters: board_id ('The ID of the board to delete') and auth ('The authentication context containing user ID and token'). This adds meaningful semantics beyond the bare schema types.

  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 ('Deletes') and resource ('a Kanban board by its ID'), distinguishing it from siblings like delete_column and delete_task which target different resources. The verb+resource combination is precise and unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like update_board or get_board, nor are prerequisites or exclusions mentioned. The description only states what it does without contextual usage information.

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

• delete_columnB
  3.4/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. While 'Deletes' implies a destructive mutation, the description doesn't address important behavioral aspects like whether this action is reversible, what permissions are required, what happens to tasks in the deleted column, or whether there are rate limits. The return value description is helpful but insufficient for a mutation tool with zero 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 well-structured with clear sections (Args, Returns) and front-loads the core purpose. Every sentence adds value, though the authentication explanation could be slightly more concise. The structure helps the agent quickly parse parameter requirements and expected outcomes.

  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 destructive mutation tool with no annotations, the description provides adequate parameter documentation and return value information (thanks to the output schema). However, it lacks critical context about the mutation's consequences, permissions needed, and relationship to other board operations. The presence of an output schema helps, but doesn't fully compensate for the behavioral gaps.

  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?

  With 0% schema description coverage, the description fully compensates by clearly documenting all 3 parameters (board_id, column_id, auth) with their types and purposes. The auth parameter explanation ('authentication context containing user ID and token') adds valuable semantic context beyond what the bare schema provides. Only minor deduction for not explaining parameter constraints or formats.

  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 ('Deletes') and target resource ('a column from a board'), distinguishing it from sibling tools like delete_board or delete_task. It provides a complete verb+resource+scope statement that leaves no ambiguity about what this tool does.

  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 update_column or reorder_columns. While it's clear this deletes columns, there's no mention of prerequisites, consequences, or appropriate contexts for choosing deletion over other column-modification operations available in the sibling tool set.

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

• reorder_columnsA
  3.5/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 but only states the basic operation. It doesn't disclose behavioral traits like whether this is a destructive mutation, what permissions are needed, how errors are handled, or what happens to tasks in reordered columns. The description is minimal beyond the core function.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, followed by structured Args and Returns sections. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

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

  Completeness3/5

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

  Given a mutation tool with no annotations, 0% schema coverage, but an output schema (returns int ID), the description is moderately complete. It covers parameters and return value, but lacks behavioral context like side effects or error conditions, which is a gap for a tool that modifies data.

  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 0%, but the description compensates by explaining all three parameters: board_id identifies the board, column_ids specifies the new order as a list, and auth provides authentication context. It adds meaningful semantics beyond the bare schema types, though it could detail format constraints (e.g., column_ids must match existing columns).

  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 ('reorders columns') and resource ('within a board'), distinguishing it from siblings like update_column or move_task. 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 Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like update_column or get_columns. The description lacks context about prerequisites, permissions, or scenarios where reordering is appropriate versus other column modifications.

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

• get_boardsA
  3.6/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 but only states it's a retrieval operation. It doesn't disclose behavioral traits like pagination, rate limits, error conditions, sorting, or whether it includes archived boards. The authentication requirement is mentioned but not elaborated.

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

  Conciseness4/5

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

  The description is appropriately sized with clear sections (purpose, args, returns). The first sentence efficiently states the core functionality. The args/returns sections are helpful but could be more integrated. No wasted sentences.

  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 1 parameter and an output schema (List[yokan_models.Board]), the description covers basic purpose and authentication. However, with no annotations and behavioral gaps (pagination, filtering, error handling), it's minimally adequate but lacks completeness for reliable agent use.

  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?

  With 0% schema description coverage and only 1 parameter, the description adds meaningful context by explaining that auth contains 'user ID and token' for authentication, which clarifies the parameter's purpose beyond the schema's structural definition. However, it doesn't detail how these fields are used.

  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 ('Retrieves') and resource ('all Kanban boards for the authenticated user'), distinguishing it from siblings like get_board (singular) and create/update/delete operations. It precisely defines scope and ownership.

  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 retrieving all boards for the current user, but doesn't explicitly state when to use this versus alternatives like get_board (for a specific board) or how it differs from other list operations. No explicit exclusions or prerequisites beyond authentication are mentioned.

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

• get_tasksA
  3.7/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 states this is a retrieval operation but doesn't mention authentication requirements (though auth parameter implies it), rate limits, pagination behavior, or what happens with invalid board_id/column_id values. The description adds minimal behavioral context beyond the basic operation.

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

  Conciseness4/5

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

  Well-structured with purpose statement followed by Args and Returns sections. The description is appropriately sized with no redundant information. Minor improvement could be integrating the optional filtering into the main purpose statement more seamlessly.

  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 (3 parameters, no annotations, but has output schema), the description is reasonably complete. It explains the operation, parameters, and return format. The output schema existence means it doesn't need to detail return values. Could benefit from more behavioral context given the lack of annotations.

  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?

  With 0% schema description coverage, the description provides excellent parameter semantics. It explains board_id purpose, auth context contents, and column_id's optional filtering behavior with clear default value explanation. The only gap is not explaining AuthContext structure, but the schema covers that.

  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 ('Retrieves all tasks'), target resource ('for a given board'), and optional scope ('optionally filtered by column'). It distinguishes this from sibling tools like get_board or get_columns by focusing specifically on tasks.

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

  Usage Guidelines3/5

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

  The description implies usage context through the optional column_id parameter, suggesting this tool can be used for both board-wide and column-specific task retrieval. However, it doesn't explicitly state when to use this versus alternatives like get_board (which might include tasks) or create_task for adding tasks.

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

• update_column_colorA
  3.7/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 states this is an update operation (implying mutation), it doesn't disclose critical behavioral traits: required permissions (e.g., board ownership), whether changes are reversible, rate limits, error conditions, or what happens if invalid color values are provided. The description mentions authentication but doesn't explain what permissions the auth context needs.

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

  Conciseness4/5

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

  The description is well-structured with purpose statement followed by Args and Returns sections. The first sentence clearly states the tool's purpose. The parameter explanations are efficient, though the auth parameter description could be more specific about required permissions. No wasted sentences, though the structure is slightly verbose for a simple 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 this is a mutation tool with no annotations but with output schema (yokan_models.Column), the description provides adequate context. It explains all parameters meaningfully and specifies the return type. However, for a write operation, it should ideally mention permission requirements or side effects. The presence of output schema reduces the need to describe return values in detail.

  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 0%, so the description must compensate. It successfully adds meaning for all 4 parameters: board_id ('The ID of the board containing the column'), column_id ('The ID of the column to update'), color ('The new highlight color for the column' with examples), and auth ('The authentication context containing user ID and token'). This provides clear semantic context beyond the bare schema types.

  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 ('Updates the highlight color') and target resource ('of a specified column'), distinguishing it from sibling tools like update_column (which likely updates other column properties) and update_board/update_task (which target different resources). The verb+resource combination is precise and unambiguous.

  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 when needing to change a column's color, but provides no explicit guidance on when to use this versus alternatives like update_column (which might handle other column properties) or when not to use it (e.g., if only read access is available). No prerequisites or exclusions are mentioned, leaving usage context partially implied rather than explicitly defined.

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