Server Quality Checklist

Tool Scores

• todoist_get_projectB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide key behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal context beyond this, only stating it 'Get details' and specifying the return content. It doesn't disclose additional traits like rate limits, authentication needs, or error handling, but it doesn't contradict the annotations either.

  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, starting with the core purpose. The 'Args' and 'Returns' sections are structured clearly, though slightly verbose. Every sentence adds value, but it could be more streamlined by integrating the parameter details 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 low complexity (1 parameter), rich annotations, and the presence of an output schema (which handles return values), the description is mostly complete. It covers the purpose, input parameters, and return content adequately. However, it lacks usage guidelines and deeper parameter context, leaving minor gaps for the 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%, but the description compensates by explaining the 'params' input structure and its components ('project_id' and 'response_format'), including valid values for 'response_format'. However, it doesn't fully detail parameter semantics beyond what's implied, such as the format of 'project_id' or default behavior. With 0% schema coverage, the description adds some value but not comprehensively.

  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 details of a specific project.' This is a specific verb ('Get') and resource ('project'), but it doesn't explicitly distinguish it from sibling tools like 'todoist_get_task' or 'todoist_list_projects' beyond the singular focus on a specific project. The description is clear but lacks 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 sibling tools like 'todoist_list_projects' for listing all projects or 'todoist_get_task' for task details, nor does it specify prerequisites or contexts for usage. The agent must infer usage from the tool name alone.

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

• todoist_create_labelB
  3.4/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false (indicating mutation), destructiveHint=false (non-destructive), openWorldHint=true (can create new resources), and idempotentHint=false (non-idempotent). The description adds that it 'Returns created label details including the new label ID,' which provides useful context about the return value. However, it doesn't mention potential constraints like rate limits, authentication needs, or error conditions beyond what annotations cover.

  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, context, args, returns) and uses bullet points efficiently. It's appropriately sized at 5 sentences, though the second sentence about label purpose could be considered slightly extraneous. Overall, it's front-loaded with the core action and wastes little space.

  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 has annotations covering key behavioral traits (mutation, non-destructive, open-world) and an output schema exists (implied by 'Returns' statement), the description provides adequate context. It explains the parameters well despite low schema coverage and mentions the return value. For a creation tool with good annotation support, this is reasonably complete, though it could benefit from more usage guidance.

  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 input schema has 0% description coverage (parameter 'params' has no description in schema), but the description compensates by listing the three nested parameters (name, color, is_favorite) and their purposes. It explains that name is required and color is optional with specific values, adding meaningful context beyond the bare schema. However, it doesn't fully detail color enum values or name constraints like length limits.

  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 creates a new label ('Create a new label'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like todoist_create_project or todoist_create_task beyond mentioning labels specifically, which is implied but not contrasted.

  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 labels help organize tasks, but doesn't specify when to create a label versus using existing ones or when this tool is preferred over other creation tools like todoist_create_project. 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.

• todoist_create_projectB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint: false) that's non-destructive and non-idempotent. The description adds minimal behavioral context beyond this - it mentions the return format ('Created project details including the new project ID') but doesn't cover important aspects like error conditions, authentication requirements, rate limits, or what happens with duplicate project names.

  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 for Args and Returns, making it easy to parse. It's appropriately sized for a creation tool with multiple parameters, though the color enum values could have been referenced rather than listed in full to improve conciseness.

  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 that this is a creation tool with annotations covering safety aspects and an output schema presumably documenting return values, the description provides adequate context. It explains the parameter structure thoroughly and mentions the return format. For a project creation tool in a Todoist context, this is reasonably complete.

  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 schema has no top-level description), the description carries the full burden. It provides a clear breakdown of the CreateProjectInput structure with meaningful explanations of each parameter, including the optional nature of parent_id, color, and is_favorite, and the required name parameter. This compensates well for the schema 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 verb 'Create' and resource 'new project in Todoist', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like todoist_create_task or todoist_create_label, which also create resources in Todoist.

  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 todoist_list_projects for viewing existing projects or todoist_get_project for retrieving a specific project, nor does it explain when creating a project is appropriate versus creating tasks or labels.

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

• todoist_get_taskA
  3.7/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by specifying the return content ('Full task details including content, description, due date, and labels') and mentioning the response_format parameter options. This provides useful context beyond the safety profile already covered by annotations.

  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 three clear sections: purpose statement, Args explanation, and Returns information. Every sentence earns its place, though the Args section could be slightly more concise by integrating the parameter details into the main flow rather than as a separate bulleted list.

  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 that annotations cover safety aspects (read-only, non-destructive, idempotent) and there's an output schema (though not shown here), the description provides adequate context. It explains what the tool does, its parameters, and return content. For a simple read operation with good annotations, this is reasonably complete, though could benefit from more explicit sibling differentiation.

  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% (parameters have no descriptions in the schema). The description compensates by explaining that params contains task_id and response_format with options 'markdown' or 'json', and that task_id is required. However, it doesn't fully document the GetTaskInput structure or provide examples for task_id format beyond what's implied.

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

  Purpose4/5

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

  The description clearly states 'Get details of a specific task' which is a specific verb+resource combination. It distinguishes itself from siblings like todoist_list_tasks (which lists multiple tasks) and todoist_update_task (which modifies tasks). However, it doesn't explicitly contrast with todoist_get_project, which has a similar 'get' pattern for a different resource.

  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 you need details of a specific known task (via task_id), but doesn't explicitly state when to use this versus alternatives like todoist_list_tasks (for browsing/searching) or todoist_get_project (for project details). No explicit 'when-not' guidance or prerequisite information is provided.

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

• todoist_update_taskA
  3.9/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it clarifies that updates are partial ('Only provided fields will be updated'), specifies a limitation for clearing due dates, and notes that labels replace existing ones. Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description enhances this with practical constraints, though it doesn't mention rate limits or auth needs.

  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 brief purpose statement, key behavioral notes, and organized parameter details. Every sentence adds value without redundancy, and it's front-loaded with essential information, making it easy to scan and understand quickly.

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

  Completeness4/5

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

  Given the tool's complexity (mutation with multiple parameters) and rich annotations, the description is mostly complete: it covers purpose, partial updates, parameter semantics, and a return confirmation. With an output schema present, it doesn't need to detail return values. However, it could improve by addressing prerequisites (e.g., task existence) or error scenarios.

  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 detailing all parameters in the 'Args' section, providing clear meanings (e.g., 'task_id: The task ID to update', 'due_string: New due date (natural language)'). It adds semantic value beyond the bare schema, though it could elaborate on edge cases or interactions between parameters like 'due_string' and 'due_date'.

  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 in Todoist'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'todoist_complete_task' or 'todoist_delete_task' beyond the basic action, missing a clear distinction in scope or effect.

  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 provides some implied usage context: 'Only provided fields will be updated' and 'To clear a due date, use the Todoist app' offer basic guidance on when to use this tool versus alternatives. However, it lacks explicit direction on when to choose this over other mutation tools like 'todoist_complete_task' or 'todoist_delete_task', leaving room for ambiguity.

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

• todoist_complete_taskA
  4.2/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it explains that for recurring tasks, completion closes the current occurrence and creates the next one. Annotations cover idempotency (idempotentHint: true) and non-destructive nature (destructiveHint: false), but the description provides specific operational details that enhance understanding.

  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 important behavioral details and parameter/return explanations. Every sentence adds value without redundancy, and the structure (purpose → behavior → args → returns) is logical and efficient.

  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 idempotency), rich annotations, and presence of an output schema, the description is largely complete. It covers purpose, behavior, parameters, and returns, though it could briefly mention idempotency or error cases for full 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%, but the description compensates by explaining the parameter in the Args section: 'task_id: The task ID to complete'. This adds meaning beyond the bare schema, though it doesn't elaborate on format or constraints. With one parameter clearly documented, it meets the baseline for adequate 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 verb ('Mark as complete') and resource ('a task'), making the purpose immediately understandable. It distinguishes from siblings like todoist_reopen_task (which reverses completion) and todoist_delete_task (which removes the task entirely), providing specific differentiation.

  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 mentioning the behavior for recurring tasks, which helps determine when to use it. However, it doesn't explicitly state when NOT to use it (e.g., vs. todoist_update_task for partial completion) or name specific alternatives, keeping it from a perfect score.

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

• todoist_reopen_taskA
  4.2/5.0
  Behavior3/5

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

  The description adds minimal behavioral context beyond annotations. Annotations already indicate this is a mutation (readOnlyHint: false), non-destructive (destructiveHint: false), idempotent (idempotentHint: true), and open-world (openWorldHint: true). The description confirms it reopens tasks but doesn't add details like permission requirements, rate limits, or what happens if the task isn't completed. No contradiction with annotations exists.

  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 perfectly structured and concise: a clear purpose statement followed by Args and Returns sections. Every sentence earns its place with no wasted words, and the information is front-loaded with the core action.

  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, simple mutation) and the presence of an output schema (implied by 'Has output schema: true'), the description is nearly complete. It covers purpose, parameter meaning, and return confirmation. A 5 would require more behavioral context, but it's adequate for this straightforward 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?

  With 0% schema description coverage (the schema has no parameter descriptions beyond titles), the description fully compensates by clearly explaining the single parameter: 'task_id: The task ID to reopen'. This adds essential meaning, though it doesn't specify format constraints (e.g., numeric vs. string). Since there's only one parameter, a 4 is appropriate rather than 5.

  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 ('Reopen a completed task') with the target resource ('task'), distinguishing it from sibling tools like todoist_complete_task (which does the opposite) and todoist_update_task (which modifies without reopening). The verb 'reopen' 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 Guidelines4/5

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

  The description implies usage context by specifying 'a completed task', indicating this tool should be used when a task needs to be moved from completed back to active status. However, it doesn't explicitly state when NOT to use it or name alternatives like todoist_update_task for other modifications, which would have earned a 5.

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

• todoist_list_labelsA
  4.3/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and behavior. The description adds that it lists 'personal labels' (implying scope) and mentions the return format, which is useful context beyond annotations, but doesn't detail rate limits or auth needs.

  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 main purpose, followed by brief context, and uses clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-structured.

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

  Completeness5/5

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

  Given the tool's low complexity (1 parameter), rich annotations covering safety, and an output schema implied by the Returns section, the description is complete enough. It explains what the tool does, parameter usage, and return values adequately for this simple list operation.

  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 the single parameter 'response_format' with options 'markdown' or 'json' and its purpose in the Returns section. It adds meaning beyond the bare schema, though it could detail default behavior more explicitly.

  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 ('List all personal labels') and resource ('in your Todoist account'), distinguishing it from siblings like todoist_list_projects or todoist_list_tasks by focusing on labels. It also explains what labels are used for, adding context.

  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 implies usage for viewing labels, with no explicit when-not-to-use or alternatives. It doesn't mention alternatives like filtering tasks by labels or using other list tools, but the context is clear for a read-only listing operation.

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

• todoist_list_projectsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context beyond annotations: it specifies what types of projects are returned (personal, shared, sub-projects) and mentions the return format options, which helps the agent understand scope and output behavior.

  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 well-structured and front-loaded with the core purpose. Each sentence adds value: the first states what it does, the second specifies scope, the third gives usage guidance, and the last two clarify parameters and returns. There's no wasted text.

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

  Completeness5/5

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

  Given the tool's low complexity (1 parameter), rich annotations covering safety and behavior, and the presence of an output schema (implied by 'Returns' section), the description is complete. It provides purpose, scope, usage guidance, parameter explanation, and return value overview without needing to duplicate structured data.

  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%, but the description compensates by explaining the 'response_format' parameter with its options ('markdown' or 'json') and their purposes. However, it doesn't fully cover the nested 'ListProjectsInput' structure or provide additional semantic context beyond what's implied by the parameter name and enum values.

  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 verb 'List' and resource 'projects in your Todoist account', making the purpose specific. It distinguishes from siblings like 'todoist_get_project' (singular) and 'todoist_list_tasks/labels' (different resources), establishing clear differentiation.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: 'Use this to get project IDs for creating tasks in specific projects.' This gives practical guidance. However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., 'todoist_get_project' for a single project), missing full sibling differentiation.

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

• todoist_list_tasksA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying the return format options ('markdown' or 'json') and listing common filter examples, which provides practical behavioral context beyond the 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 efficiently structured: a clear purpose statement, filter support explanation with examples, and a well-organized Args/Returns section. Every sentence adds value without redundancy, making it easy to parse.

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

  Completeness5/5

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

  Given the tool's moderate complexity (filtering capabilities), rich annotations, and the presence of an output schema, the description is complete. It covers purpose, parameters, usage examples, and return information, providing all necessary context for an agent to use the tool effectively.

  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 schema provides no parameter descriptions. The description compensates well by listing all parameters (project_id, label, filter, limit, response_format) with brief explanations and examples, adding significant meaning beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the verb ('List') and resource ('tasks from Todoist'), and specifies the optional filtering capability. It distinguishes this tool from siblings like todoist_get_task (single task) and todoist_complete_task (mutation).

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

  Usage Guidelines4/5

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

  The description provides clear context about when to use this tool ('List tasks... with optional filters') and offers examples of common filters. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the siblings, such as using todoist_get_task for a single task.

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

• todoist_delete_taskA
  4.7/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond annotations: it explicitly warns 'This action cannot be undone' and 'The task will be permanently removed', which reinforces the destructive nature. Annotations already indicate destructiveHint=true, but the description provides crucial user-facing warnings about irreversibility, enhancing 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 front-loaded with the main action, uses a warning icon for emphasis, and includes structured sections for Args and Returns. Every sentence adds value: the first states the purpose, the warning highlights critical behavior, and the structured parts clarify inputs and outputs without redundancy.

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

  Completeness5/5

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

  Given the tool's complexity (a destructive operation with one parameter) and the presence of annotations (e.g., destructiveHint=true) and an output schema (implied by 'Returns' statement), the description is complete. It covers purpose, irreversible nature, parameter meaning, and expected confirmation, leaving no significant gaps for agent understanding.

  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 adds meaningful context for the single parameter by specifying that 'params' contains 'task_id: The task ID to delete'. Since schema description coverage is 0% (the schema has no descriptions for properties), this compensates well by explaining the parameter's purpose, though it could provide more detail on format or constraints.

  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 ('Permanently delete a task') and distinguishes it from siblings like 'todoist_complete_task' or 'todoist_update_task' by emphasizing permanent removal. The verb 'delete' is precise and the resource 'task' is unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (to permanently delete a task) and includes a warning about irreversibility, which helps differentiate it from alternatives like 'todoist_complete_task' or 'todoist_reopen_task'. However, it does not explicitly state when not to use it or name specific alternatives.

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

• todoist_create_taskA
  4.8/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond annotations: the temporal check warning about LLM year defaults, support for natural language dates, priority scale explanation (4=highest/red), and return value details. Annotations provide basic hints (readOnly=false, destructive=false), but the description enriches this with practical implementation guidance.

  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: purpose statement, critical warning, key behavioral notes, then organized parameter and return sections. Every sentence adds value with no redundancy, and information is front-loaded appropriately.

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

  Completeness5/5

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

  Given the mutation nature (readOnlyHint=false), 8 parameters with no schema descriptions, and presence of output schema, the description provides complete context: purpose, warnings, parameter semantics, behavioral details, and return information. It adequately compensates for the lack of schema descriptions.

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

  Parameters5/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 explaining all 8 parameters in detail: content, description, project_id defaults, due_string examples, due_date format, priority scale, labels usage, and parent_id purpose. It adds meaning beyond the bare schema with examples, defaults, and clarifications.

  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 verb 'Create' and resource 'new task in Todoist', making the purpose specific and unambiguous. It distinguishes from siblings like todoist_update_task (modify existing) and todoist_delete_task (remove).

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (creating new tasks) and includes a temporal check warning about due_date years. However, it doesn't explicitly state when NOT to use it or name alternatives like todoist_update_task for modifying existing tasks.

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