Server Quality Checklist

Tool Scores

• add_tasks_to_requestC
  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 mentions that 'A progress table will be displayed showing all tasks including the newly added ones,' which adds some context about the output behavior. However, it lacks critical details such as whether this operation requires specific permissions, if it's idempotent, what happens on errors, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.

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

  Conciseness4/5

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

  The description is concise with two sentences that directly address the tool's function and output behavior. It's front-loaded with the core purpose, and the second sentence adds useful context without redundancy. However, it could be slightly more structured by explicitly listing parameters or usage scenarios.

  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 of a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the basic purpose and hints at output behavior but misses details on parameter meanings, error handling, permissions, and how it integrates with sibling tools. This leaves significant gaps for an AI agent to use it correctly.

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

  Parameters3/5

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

  The schema description coverage is 0%, so the description must compensate for undocumented parameters. It implies the parameters are 'requestId' and 'tasks' (as it mentions adding tasks to an existing request), but doesn't explain their semantics, formats, or constraints beyond the basic idea. Since there are only 2 parameters, the baseline is higher, but the description adds minimal value over the schema, resulting in an adequate but not helpful 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 ('Add') and resource ('tasks to an existing request'), making the purpose understandable. It specifies this is for extending an existing request with additional tasks, which distinguishes it from creating a new request. However, it doesn't explicitly differentiate from sibling tools like 'update_task' or 'request_planning' beyond the 'add to existing' aspect.

  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 by mentioning it's for 'extending a request with additional tasks,' which implies usage when more tasks are needed for an existing request. However, it doesn't specify when to use this tool versus alternatives like 'update_task' (which might modify existing tasks) or 'request_planning' (which might create new requests), nor does it mention prerequisites or exclusions.

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

• open_task_detailsB
  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 for behavioral disclosure. It states this is for 'inspecting' information, which implies a read-only operation, but doesn't explicitly confirm this or address other behavioral aspects like authentication requirements, rate limits, error conditions, or what specific details are returned. The phrase 'at any point' suggests availability but doesn't clarify constraints.

  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 in two concise sentences. The first sentence directly states the action and required parameter, while the second provides usage context. Every word earns its place with no redundancy or fluff.

  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 has no annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. It adequately states the basic purpose but lacks crucial information about what details are returned, behavioral constraints, parameter semantics, and differentiation from sibling tools. For a read operation tool in a workflow system, more context is needed.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must fully compensate. It mentions the 'taskId' parameter and that details are retrieved by it, but provides no additional semantic context about what a taskId is, its format, where to obtain it, or validation rules. This leaves significant gaps in parameter understanding beyond the basic schema type.

  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 details') and resource ('specific task'), making the purpose evident. It specifies retrieving information by 'taskId' for inspection purposes. However, it doesn't explicitly differentiate from potential sibling tools like 'get_next_task' or 'list_requests' that might also provide task information.

  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 with 'for inspecting task information at any point', suggesting this tool is for detailed examination rather than listing or workflow progression. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_next_task' (which might return limited details) or 'list_requests' (which might provide summary information). No exclusions or clear alternatives are named.

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

• delete_taskB
  3.1/5.0
  Behavior3/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 describes key behavioral traits: the deletion action (implying mutation), the constraint that only uncompleted tasks can be deleted, and that a progress table will be displayed after deletion. However, it lacks details on permissions, error handling, or what happens if deletion fails, leaving gaps for a mutation tool.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences that cover key points: the action with constraints and the post-deletion behavior. It's front-loaded with the main purpose, and each sentence adds value without redundancy. However, the second sentence could be more integrated with the first for better flow.

  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 of a deletion tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It misses critical details: parameter meanings, error cases, permissions, and the format of the progress table. While it covers the basic action and constraint, it doesn't provide enough context for reliable agent use in this environment.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate for undocumented parameters. It mentions 'a specific task from a request,' which hints at the need for requestId and taskId, but doesn't explain their semantics, formats, or sources. For example, it doesn't clarify if these are IDs from 'list_requests' or 'get_next_task.' The description adds minimal value beyond the schema's structure.

  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 specific task from a request'), making the purpose understandable. It distinguishes from siblings like 'update_task' or 'mark_task_done' by specifying deletion, though it doesn't explicitly contrast with all alternatives. The description avoids tautology by adding operational details beyond just restating the name.

  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 usage context by stating 'Only uncompleted tasks can be deleted,' which implies when to use it (for uncompleted tasks) and when not to use it (for completed tasks). However, it doesn't explicitly name alternatives like 'update_task' for modifying tasks or clarify prerequisites such as needing valid request/task IDs. The guidance is implied rather than comprehensive.

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

• list_requestsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool lists requests with 'basic information and summary of tasks,' which implies a read-only operation, but it doesn't specify details like pagination, sorting, filtering, rate limits, or authentication requirements. For a 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.

  Conciseness4/5

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

  The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and utility. Every sentence earns its place by clarifying the action and scope. However, it could be slightly more structured by explicitly mentioning the lack of parameters or output details, but 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's complexity (simple list operation with 0 parameters), no annotations, and no output schema, the description is moderately complete. It explains what the tool does but lacks details on behavioral aspects like return format, error handling, or system constraints. For a tool with no structured data support, this is adequate but leaves room for improvement in providing more 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 input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't add parameter-specific information, which is appropriate here. Since the baseline for 0 parameters is 4, this score reflects that the description doesn't need to compensate for any schema gaps, and it aligns well with the lack of 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 tool's purpose: 'List all requests with their basic information and summary of tasks.' It uses specific verbs ('list') and resources ('requests'), and mentions the scope ('all requests in the system'). However, it doesn't explicitly differentiate from sibling tools like 'get_next_task' or 'request_planning', which also involve request-related operations, so it doesn't reach the highest 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 minimal guidance: it says this tool 'provides a quick overview of all requests,' implying it's for summary purposes. However, it doesn't specify when to use this tool versus alternatives (e.g., 'get_next_task' for a specific task or 'request_planning' for planning-related actions), nor does it mention any prerequisites or exclusions. This lack of explicit context limits its usefulness for an agent.

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

• update_taskB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that updates are limited to uncompleted tasks and mentions a 'progress table will be displayed' as output behavior. However, it doesn't cover important aspects like whether this requires specific permissions, if changes are reversible, error handling, or rate limits. The description adds some behavioral context but leaves significant gaps.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences. The first sentence clearly states the purpose and constraint, while the second describes output behavior. There's no unnecessary information, though it could be slightly more structured by separating constraints from output details.

  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 (mutation operation with 4 parameters), no annotations, and no output schema, the description is partially complete. It covers the update scope and a constraint but lacks details on parameter meanings, error conditions, permissions, and full output specification. The description provides a basic foundation but leaves important gaps for a mutation tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions that 'title and/or description' can be updated, which maps to two of the four parameters. However, it doesn't explain the purpose of 'requestId' and 'taskId' (the required parameters) or provide any format/validation details. The description adds minimal value beyond what's implied by parameter names.

  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: 'Update an existing task's title and/or description.' It specifies the verb (update) and resource (task) with the specific fields that can be modified. However, it doesn't explicitly differentiate from sibling tools like 'mark_task_done' or 'delete_task' beyond mentioning that only uncompleted tasks can be updated.

  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: 'Only uncompleted tasks can be updated.' This establishes a key precondition. However, it doesn't explicitly mention when NOT to use it (e.g., for completed tasks) or name alternatives like 'delete_task' for removal or 'mark_task_done' for completion.

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

• approve_request_completionA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool 'finalizes' and 'confirms' completion, implying a write/mutation operation, and mentions a 'progress table' will be displayed before approval. However, it lacks details on permissions, side effects (e.g., if it locks the request), or response format. The description adds some behavioral context but is incomplete for a mutation tool.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Each subsequent sentence adds value: the second explains a behavioral detail (progress table), and the third provides usage alternatives. There is no wasted text, and the structure flows logically from purpose to context.

  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 to finalize a request), no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the purpose, prerequisites, and some behavioral aspects but lacks details on permissions, side effects, return values, and explicit parameter guidance. It is adequate but has clear gaps for a tool of this nature.

  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 1 parameter with 0% description coverage, so the description must compensate. It does not explicitly mention the 'requestId' parameter, but contextually implies it by referring to 'the entire request' and 'request_planning'. The description adds meaning by explaining the tool's purpose and prerequisites, which helps infer parameter usage, though it does not detail the parameter's format or 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 tool's purpose: 'finalizes the entire request' after 'all tasks are done and approved', with the specific action being to 'confirm that the request is fully completed'. It uses a specific verb ('finalizes') and resource ('request'), but does not explicitly distinguish it from siblings like 'approve_task_completion' beyond implying it's for the entire request versus individual tasks.

  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 on when to use it: 'After all tasks are done and approved' and 'to confirm that the request is fully completed'. It also mentions an alternative action if not approved: 'add new tasks using request_planning'. However, it does not explicitly state when NOT to use it (e.g., before tasks are complete) or compare it to all relevant siblings like 'approve_task_completion'.

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

• approve_task_completionA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's role in a workflow (approval after marking done) and consequences (proceeding to 'get_next_task' only after approval). However, it lacks details on error handling, response format, or side effects like whether approval is reversible. The description adds meaningful context but doesn't fully cover behavioral traits.

  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. Each sentence adds value: the first explains the tool's role, the second mentions the progress table, and the third covers alternative actions. It could be slightly more concise by integrating the progress table mention into the workflow explanation, but 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.

  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 output schema, no annotations), the description provides good contextual completeness. It explains the tool's place in a workflow, prerequisites, and consequences. However, it doesn't detail what happens upon successful approval (e.g., state changes) or error cases, leaving some gaps for a tool with mutation 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 input schema has 0% description coverage, so the description must compensate. While it doesn't explicitly explain the 'requestId' and 'taskId' parameters, it implicitly clarifies their purpose by describing the approval process for a specific task within a request context. This adds semantic meaning beyond the bare schema, though it could be more explicit about parameter roles.

  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 tool's purpose: 'the user must call this tool to approve that the task is genuinely completed' after using 'mark_task_done'. It specifies the verb (approve) and resource (task completion), and distinguishes it from sibling tools like 'approve_request_completion' by focusing on task-level approval rather than request-level.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: 'Once the assistant has marked a task as done using 'mark_task_done', the user must call this tool to approve that the task is genuinely completed.' It also specifies alternatives and exclusions: 'If the user does not approve, do not call 'get_next_task'. Instead, the user may request changes, or even re-plan tasks by using 'request_planning' again.'

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

• get_next_taskA
  4.4/5.0
  Behavior4/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 discloses key behaviors: returns next pending task, indicates when all tasks are done, shows a progress table, and has strict sequencing rules (must not proceed without user approval). However, it doesn't mention error handling, rate limits, or authentication needs, leaving some gaps.

  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 front-loaded with the core purpose but becomes verbose with detailed sequencing rules and repetitions (e.g., 'Do not skip the user's approval step' and 'In other words:'). Some sentences could be condensed without losing clarity, making it slightly less 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 no annotations and no output schema, the description does well by explaining return behavior (pending task, all_tasks_done, progress table) and sequencing constraints. However, it doesn't describe the output format (e.g., structure of returned task) or error cases, which could be important for a tool with complex workflow dependencies.

  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 explains that requestId is used to identify which request's tasks to query, adding meaning beyond the bare schema. However, it doesn't specify the format or source of requestId (e.g., from list_requests), leaving some ambiguity.

  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 tool's purpose: 'return the next pending task (not done yet)' given a requestId. It distinguishes from siblings by specifying it returns pending tasks only, not all tasks or completed ones, and mentions specific sibling tools (approve_task_completion, approve_request_completion) for context.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided on when to use this tool vs alternatives: use after requestId is available, not after mark_task_done until approve_task_completion is called, and not after all_tasks_done until approve_request_completion. It names specific sibling tools (approve_task_completion, approve_request_completion, request_planning) as alternatives in different scenarios.

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

• request_planningA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's role in initiating a workflow, the required user approvals after each task, and the overall process until request completion. However, it lacks details on error handling, performance characteristics, or specific constraints like rate limits.

  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 front-loaded with the core purpose, but the detailed workflow explanation is lengthy and somewhat repetitive (e.g., emphasizing approval steps multiple times). While informative, it could be more streamlined without losing critical guidance.

  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 complexity of a 3-parameter tool with no annotations or output schema, the description does a good job of explaining the tool's role in a broader workflow and interaction with siblings. It covers the essential context for correct usage, though it omits details on return values or error cases.

  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 for 3 parameters, the description compensates by explaining the purpose of 'originalRequest' and 'tasks' as required inputs and 'splitDetails' as optional. It clarifies that tasks must include 'title' and 'description', adding meaning beyond the bare schema, though it could provide more context 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 tool's purpose: 'Register a new user request and plan its associated tasks.' It specifies the verb ('register' and 'plan') and resource ('user request' and 'tasks'), and distinguishes it from siblings like 'add_tasks_to_request' by indicating this is for initial registration rather than modification.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool versus alternatives, detailing a step-by-step workflow that includes this tool as the first step and references sibling tools like 'get_next_task', 'approve_task_completion', and 'approve_request_completion' for subsequent actions. It explicitly states not to proceed automatically without user approval.

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

• mark_task_doneA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it triggers a progress table display, updates task status, and imposes a workflow constraint (waiting for approval). However, it lacks details on error handling, permissions, or side effects beyond the progress display, leaving some gaps in transparency.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, with the core purpose stated first. Each sentence adds value: the first explains the action and parameters, the second describes the immediate outcome, and the third provides critical workflow guidance. There is minimal redundancy, though the structure could be slightly more streamlined.

  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 complexity (a mutation tool with workflow dependencies), no annotations, and no output schema, the description does well by covering purpose, usage, and behavioral outcomes like the progress table and approval requirement. However, it misses details on error cases, return values, or what happens if parameters are invalid, 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.

  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: 'requestId' and 'taskId' are required to identify the task, and 'completedDetails' is optional for providing additional information. This clarifies parameter roles beyond the basic schema, though it doesn't specify formats or constraints (e.g., what 'completedDetails' should contain).

  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 ('Mark a given task as done'), identifies the resource ('task'), and distinguishes it from siblings like 'update_task' or 'delete_task' by focusing on completion status. It explicitly mentions providing parameters like 'requestId' and 'taskId', which reinforces the purpose.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('after you've completed it') and when not to proceed ('DO NOT proceed to 'get_next_task' again until the user has explicitly approved this completed task using 'approve_task_completion''). It names alternatives ('get_next_task', 'approve_task_completion') and sets clear prerequisites for workflow sequencing.

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