Server Quality Checklist

Tool Scores

• 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 the full burden. It states 'Delete a task' which implies a destructive mutation, but doesn't disclose critical behavioral traits such as whether deletion is permanent, reversible, requires confirmation, affects related data, or has rate limits. This leaves significant gaps for safe agent 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 with two sentences: a clear purpose statement and a parameter list. It's front-loaded with the main action, though the parameter section could be integrated more smoothly. There's minimal waste, earning its place efficiently.

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

  Completeness3/5

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

  Given the tool's complexity (destructive operation with 1 parameter), no annotations, and an output schema exists (which handles return values), the description is moderately complete. It covers the basic purpose and parameter, but lacks behavioral details and usage context, making it adequate but with clear gaps for a mutation tool.

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

  Parameters3/5

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

  The description includes an 'Args' section that documents the single parameter 'task_id', adding meaning beyond the input schema which has 0% description coverage. However, it doesn't provide details on the format or source of task IDs (e.g., from 'get_tasks'), so it partially compensates but not fully.

  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 ('Delete') and resource ('a task'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'complete_task' or 'reopen_task' in terms of what specific type of task operation it performs, beyond the basic 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 like 'complete_task' or 'reopen_task', nor does it mention prerequisites (e.g., task must exist, user must have permissions). It only states what the tool does without context for selection.

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

• get_sectionsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination), or error conditions. 'Get' implies reading, but specifics are missing.

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

  Conciseness4/5

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

  The description is brief and front-loaded with the main purpose, followed by parameter notes. It avoids redundancy, though the parameter explanation could be more integrated. 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 tool has an output schema (which handles return values), the description's gaps in usage guidelines and behavioral transparency are somewhat mitigated. However, for a tool with no annotations and low schema coverage, it should provide more context on behavior and alternatives to be fully complete.

  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 adds that 'project_id' is optional, which is useful since the schema has 0% description coverage. However, it doesn't explain what happens when omitted (e.g., returns all sections across projects?) or provide format examples. With low schema coverage, this partial compensation earns a baseline score.

  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 'get' and resource 'sections from a project', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_projects' or 'get_tasks', which would require more specific scope definition to earn a 5.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives like 'get_projects' or 'get_tasks'. The description mentions the parameter is optional but doesn't explain the implications of providing or omitting it, leaving usage context unclear.

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

• get_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation ('Get'), implying it's likely read-only, but doesn't confirm this or describe any other behavioral traits like error conditions, authentication requirements, rate limits, or what happens if the task ID doesn't exist.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences that directly address purpose and parameters. The structure is front-loaded with the main purpose first, though the parameter documentation could be more integrated rather than appearing as a separate 'Args' section.

  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 (which handles return values) and only one parameter, the description is minimally adequate. However, for a retrieval tool with no annotations, it should ideally mention that this is a read-only operation and clarify what happens with invalid IDs to provide better context 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?

  The description adds basic meaning for the single parameter ('The ID of the task to retrieve'), which is helpful since schema description coverage is 0%. However, it doesn't provide format details, validation rules, or examples that would be valuable for a parameter with no schema documentation.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('a specific task by ID'), making it immediately understandable. However, it doesn't differentiate this tool from its sibling 'get_tasks' which presumably retrieves multiple tasks, missing an opportunity for sibling distinction.

  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_tasks' or other task-related tools. While the purpose is clear, there are no explicit instructions about prerequisites, appropriate contexts, or comparisons 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_tasksC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'optional filtering' but doesn't describe key behaviors like whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. The description is minimal and leaves critical behavioral traits unspecified.

  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 a clear opening sentence and a structured 'Args' section. It's front-loaded with the core purpose, and each sentence adds value without redundancy. Minor improvements could include integrating the parameter explanations more seamlessly.

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

  Completeness3/5

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

  Given the tool's moderate complexity (4 optional parameters) and the presence of an output schema (which handles return values), the description is partially complete. It covers the purpose and parameters but lacks behavioral context and usage guidelines. With no annotations, it should do more to compensate, especially for a tool with filtering capabilities.

  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 lists all four parameters with brief explanations, adding meaning beyond the input schema (which has 0% description coverage). However, the explanations are basic (e.g., 'Filter tasks by project ID') and don't provide detailed semantics like format examples (except for 'filter_query'), constraints, or interactions between parameters.

  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 ('Get') and resource ('tasks from Todoist') with optional filtering, making the purpose immediately understandable. It distinguishes itself from siblings like 'get_task' (singular) by implying it retrieves multiple tasks, though it doesn't explicitly contrast with other list-like tools like 'get_projects' or 'get_sections'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_tasks' over 'get_task' (singular), 'complete_task', or other siblings, nor does it specify prerequisites, contexts, or exclusions for usage.

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

• reopen_taskC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Reopen') which implies a state mutation, but doesn't describe what 'reopen' entails (e.g., changes status from 'completed' to 'open', preserves other attributes, requires permissions, or has side effects). The description lacks behavioral 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 appropriately concise with two sentences: a clear purpose statement followed by parameter documentation. It's front-loaded with the core functionality. However, the parameter documentation uses minimal formatting and could be slightly more structured for readability.

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

  Completeness3/5

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

  Given the tool's moderate complexity (state mutation), lack of annotations, and presence of an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic action and parameter, but lacks details on behavioral implications, error conditions, or integration with sibling tools, leaving room for improvement in completeness.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It provides a brief explanation for the single parameter ('The ID of the task to reopen'), which adds basic semantic context beyond the schema's title ('Task Id'). However, it doesn't elaborate on format requirements, validation rules, or where to obtain the ID, 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 action ('Reopen') and target resource ('a completed task'), making the purpose immediately understandable. It distinguishes from siblings like 'complete_task' by specifying the opposite state transition. However, it doesn't explicitly contrast with other update/mutation tools like 'update_task'.

  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 minimal guidance: it implies this tool should be used on 'completed' tasks, but doesn't specify when to choose this over alternatives like 'update_task' for status changes, or whether there are prerequisites (e.g., task must be in a specific state). No explicit when-not-to-use or sibling comparisons are provided.

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

• complete_taskB
  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 the action ('Mark a task as completed') but doesn't clarify if this is irreversible, requires specific permissions, affects related data (e.g., project progress), or has side effects like notifications. For a mutation tool, this leaves significant gaps in understanding its 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 highly concise and well-structured: a brief purpose statement followed by a parameter explanation, with no wasted words. Every sentence directly contributes to understanding the tool, making it easy to parse quickly.

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

  Completeness3/5

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

  Given the tool's moderate complexity (a mutation with one parameter) and the presence of an output schema (which likely handles return values), the description is minimally adequate. However, it lacks behavioral details and usage context, leaving gaps that could hinder effective 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?

  The description includes an 'Args' section that explains 'task_id: The ID of the task to complete', adding clear meaning beyond the schema's basic title ('Task Id') and type. Since schema description coverage is 0%, this fully compensates for the single parameter, though it doesn't detail format constraints (e.g., UUID).

  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 ('Mark') and resource ('a task') with the specific action ('as completed'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'reopen_task' or 'update_task' that also modify task status, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'reopen_task' (for undoing completion) or 'update_task' (which might also handle status changes). There's no mention of prerequisites, such as whether the task must be in an incomplete state, leaving usage context entirely implied.

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

• create_projectB
  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 creation operation but doesn't mention permissions required, whether projects are permanent or deletable, rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 efficiently structured with a clear purpose statement followed by a bulleted list of parameters. Every sentence earns its place, and there's no redundant or verbose language. It's appropriately sized for a tool with 4 parameters.

  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 (which handles return values), 0% schema description coverage, and no annotations, the description does an adequate job explaining parameters but falls short on behavioral context. For a creation tool in a Todoist system with sibling tools, it should provide more guidance on usage and implications.

  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 all 4 parameters beyond the schema, which has 0% description coverage. It explains that 'parent_id' is for nested projects and 'is_favorite' marks projects as favorites, providing semantic value that the schema titles alone don't convey. However, it doesn't specify format details like valid color values or parent_id constraints.

  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 ('Create a new project') and resource ('in Todoist'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'create_task' or explain why one would create a project versus a task, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'create_task' or 'update_task', nor does it mention prerequisites or context for project creation. It simply lists parameters without explaining the tool's role in the broader workflow.

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

• get_projectsB
  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 it 'gets' projects but doesn't specify whether this is a read-only operation, requires authentication, has rate limits, returns paginated results, or what format the output takes. While 'get' implies a safe read operation, the lack of explicit behavioral details leaves significant gaps for an agent.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately front-loaded with the essential information ('Get all projects from Todoist') and contains no extraneous details. This is an excellent example of conciseness for a simple retrieval tool.

  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 zero-parameter tool with an output schema (which handles return values), the description is minimally adequate. It states what the tool retrieves but lacks behavioral context (authentication, rate limits, etc.) and usage guidance relative to siblings. The presence of an output schema reduces the burden, but the description could still benefit from more operational context.

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

  Parameters4/5

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

  The tool has zero parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters since none exist. It appropriately focuses on what the tool does rather than parameter details, earning a high score for this dimension given the parameterless design.

  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 ('Get') and resource ('all projects from Todoist'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'get_project' (singular), but the 'all projects' phrasing provides some implicit distinction. The description avoids tautology by specifying what is being retrieved rather than just restating the tool name.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_project' (singular) or 'get_tasks'. There's no mention of prerequisites, context, or comparison with sibling tools. The agent must infer usage from the tool name and description alone without explicit direction.

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

• update_taskB
  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. While 'update' implies mutation, the description doesn't address important behavioral aspects: what permissions are required, whether updates are atomic or partial, what happens when only some fields are provided, whether there are rate limits, or what the response format looks like. The description merely lists parameters without explaining the tool's behavior.

  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 begins with a clear purpose statement, then provides a parameter-by-parameter breakdown with helpful explanations. While efficient, it could be slightly more concise by grouping related parameters (like the two due date formats) or using bullet points instead of the 'Args:' format.

  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 this is a mutation tool with 7 parameters, no annotations, but with an output schema present, the description is moderately complete. The parameter explanations are excellent, but the lack of behavioral context (permissions, atomicity, response format) is a significant gap. The presence of an output schema means the description doesn't need to explain return values, but it should address other behavioral aspects.

  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?

  The description provides excellent parameter semantics that go far beyond the input schema. With 0% schema description coverage, the schema only provides parameter names and types. The description adds crucial context: 'task_id' identifies which task to update, 'priority' ranges from 1 (normal) to 4 (urgent), 'due_string' is human readable while 'due_date' uses ISO 8601 format, and all other fields represent 'updated' versions of task attributes.

  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'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'complete_task' or 'reopen_task' which also modify tasks, nor does it explain how this differs from 'create_task' which might share similar parameters.

  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. With siblings like 'complete_task', 'reopen_task', and 'delete_task' that also modify task states, there's no indication of when partial updates via 'update_task' are appropriate versus using those other state-changing operations.

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

• create_taskA
  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 for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address authentication requirements, rate limits, error conditions, or what happens when creating duplicate tasks. It provides basic parameter explanations but lacks operational context.

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

  Conciseness4/5

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

  The description is efficiently structured with a clear purpose statement followed by a well-organized parameter list. Each parameter explanation is brief yet informative. While slightly longer due to 9 parameters, every sentence adds value and the structure helps with readability.

  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 mutation tool with 9 parameters and no annotations, the description provides good parameter semantics but lacks behavioral context. The existence of an output schema reduces the need to describe return values, but the description should still address authentication, error handling, and usage guidelines given the tool's complexity and mutation nature.

  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 and 9 parameters, the description provides comprehensive semantic explanations for all parameters. It clarifies ambiguous terms like 'content' vs 'description', explains numeric ranges for 'priority', provides format examples for 'due_string' and 'due_date', and clarifies relationships between parameters like 'project_id' and 'section_id'.

  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 ('Create a new task') and resource ('in Todoist'), distinguishing it from sibling tools like update_task, complete_task, or delete_task. It provides a verb+resource combination that leaves no ambiguity about the tool's function.

  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_task or create_project. It doesn't mention prerequisites (e.g., needing valid project_id for certain use cases) or contextual factors that would help an agent choose between this and sibling tools.

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

• get_projectA
  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 for behavioral disclosure. It states this is a retrieval operation but doesn't describe authentication requirements, rate limits, error behavior (e.g., what happens with invalid ID), or response format. The presence of an output schema helps but the description itself lacks 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.

  Conciseness5/5

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

  The description is perfectly concise with zero wasted words. It states the purpose in one clear sentence and documents the parameter in a clean, structured format. Every element earns its place and the information is front-loaded appropriately.

  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?

  For a simple read operation with one parameter and an output schema, the description provides adequate context. The output schema will handle return value documentation, so the description focuses correctly on purpose and parameter semantics. However, it could better address behavioral aspects 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?

  The description explicitly documents the single parameter ('project_id: The ID of the project to retrieve'), adding clear semantic meaning beyond the schema's minimal title ('Project Id'). With 0% schema description coverage, this parameter documentation is essential and well-handled for a single-parameter tool.

  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 ('Get') and resource ('a specific project by ID'), making the purpose unambiguous. It distinguishes from sibling 'get_projects' by specifying retrieval of a single project rather than a list. However, it doesn't fully differentiate from 'get_task' which retrieves a different resource type.

  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 to retrieve a single project by its ID, but doesn't explicitly state when to use this versus 'get_projects' (for listing) or other siblings. No guidance is provided about prerequisites, error conditions, or alternative tools for related operations.

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