Server Quality Checklist

Tool Scores

• weeek_list_tasksA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It reveals pagination behavior with allPages and mentions filtering, but does not disclose return format, authentication, or other behavioral details. The description adds some context but is minimal.

  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?

  Two sentences, front-loaded with the core purpose, followed by a specific usage note. No 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?

  With 9 parameters, no output schema, and no annotations, the description is too brief to cover the tool's complexity. It focuses on one scenario and omits other query capabilities and return value expectations.

  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 coverage is 0%, but the description adds meaning to the allPages/userId/startDate/endDate combination, which is the non-obvious part. However, limit, offset, sortBy, completed, and projectId remain unexplained, leaving a significant gap.

  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?

  States 'List WEEEK tasks' with a clear verb+resource. The phrase 'server-side filters' further clarifies behavior. Distinguishes from siblings like weeek_list_projects and task-specific actions.

  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?

  Provides a specific usage tip for allPages combined with userId and date range, but does not explicitly state when to use this tool vs alternatives or mention exclusions. The guidance is implied through the tool name and description.

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

• weeek_create_tasksA
  3.7/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It reveals important behavior: returns a per-item report and does not abort the entire batch on a single bad name (partial failure). This is valuable beyond the input schema. It does not detail other aspects like authentication or rate limits, but for a batch create operation, the partial-failure semantics are the most critical.

  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?

  Two sentences, front-loaded with purpose, followed by a critical behavioral note. Every word earns its place; no redundancy or filler.

  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?

  The tool has a nested array parameter and no output schema, but the description covers the essential context: batch operation, per-item return report, and partial-failure behavior. It does not describe the exact report structure or error formats, but for a create-only tool with a clear schema, the given information is largely sufficient.

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

  Parameters1/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 by explaining parameters. It mentions 'tasks' implicitly through the tool name and 'Create many WEEEK tasks,' but it provides no details about required fields, types, or semantics. The schema shows required 'title' and 'project' for each item, but the description adds no guidance on these or any other parameter, leaving the agent to infer everything from the schema alone.

  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: 'Create many WEEEK tasks in one call.' It uses a specific verb ('Create') and resource ('WEEEK tasks'), and distinguishes from siblings like weeek_create_task by emphasizing bulk operation ('many', 'in one call').

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

  Usage Guidelines3/5

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

  The description implies usage for bulk task creation ('Create many... in one call') but does not explicitly state when to use this tool versus the singular weeek_create_task, nor does it mention any exclusions or prerequisites. The context is clear but lacks explicit alternative guidance.

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

• weeek_move_taskA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that 'column' can be provided by name or id, and that the operation is 'scoped to the given board', which adds useful context. However, it does not mention potential side effects, error behavior, or whether the task must already exist on the board, leaving 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.

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the action, contains no filler, and conveys essential information about the column parameter and board scoping. Every word earns its place, making it highly concise and well-structured.

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

  Completeness3/5

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

  For a simple mutation tool with 3 required parameters and no output schema or annotations, the description is minimally adequate. It covers the core action and key parameter semantics, but lacks information on return values, error conditions, or prerequisites. Given the simplicity of the operation, the description is workable but not rich, warranting a mid-range score.

  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 coverage is 0%, so the description must compensate. It explains that 'column' can be a string (name) or number (id) and that 'board_id' determines the board scope. However, it does not explicitly describe the 'id' parameter as the task identifier, relying on inference from the verb 'Move a WEEEK task'. This partial compensation warrants a mid-range score.

  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 uses a specific verb 'Move' with a clear resource 'task' and destination 'column', and adds scoping with 'scoped to the given board'. This distinguishes it from sibling tools like update_task, complete_task, and delete_task, making the purpose unmistakable.

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

  Usage Guidelines3/5

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

  The description implies usage for moving tasks between columns on a board, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. It provides context about board scoping but lacks clear guidance on choosing this tool.

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

• weeek_complete_taskA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It accurately conveys the core behavior (completing or reopening) and adds the nuance that setting completed to false reopens the task. However, it does not disclose any potential side effects, permissions, or error handling, which leaves some ambiguity 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and key parameter usage. No redundant words or unnecessary 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?

  For a simple toggle tool, the description covers the essential behavior. However, with no annotations and no output schema, it does not mention what the tool returns (if anything) or any prerequisite conditions, which could leave the agent unaware of expected responses or failure modes.

  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 coverage is 0%, so the description must compensate. It explains the completed parameter's meaning via 'completed:false', but it does not explicitly clarify that 'id' refers to the task ID or that completed maps directly to the boolean field. The description adds minimal value beyond the schema's property names.

  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 function with a specific verb ('Mark') and resource ('WEEEK task complete'), and also mentions the ability to reopen (completed:false). This distinguishes it from sibling tools like update_task, which would be for changing other task fields.

  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: use this tool to set a task's completion status. It does not explicitly exclude alternatives or mention update_task, but the specificity of 'complete or reopen' makes the intended usage obvious.

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

• weeek_get_taskA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden for behavioral disclosure. It adds useful context that the response includes assignees, but it does not mention error behavior (e.g., what happens if id is missing), read-only nature explicitly, or any potential side effects. For a simple read operation, this is acceptable but not comprehensive, so a 3 is warranted.

  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 sentence of ten words, front-loaded with the action verb 'Get' and the resource. It conveys the necessary information without any filler or repetition, making it highly 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?

  For a simple one-parameter read operation with no output schema, the description covers the core function and adds the detail about assignees. It is nearly complete, though it could briefly address not-found behavior or explicitly state that it returns a single task object. Given the simplicity, a 4 is warranted.

  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 no descriptions (0% coverage), so the description needed to compensate. The phrase 'by id' merely restates the purpose of the 'id' parameter already evident from the name and schema, adding no additional meaning such as format, constraints, or how to obtain the id. This is minimal compensation for a single parameter, thus a 2.

  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 uses the specific verb 'Get' and identifies the resource as 'one WEEEK task' with a clear scope 'by id'. It also highlights that the response includes assignees, distinguishing it from task listing or update tools. The name and description align perfectly to convey the operation.

  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 clearly implies usage when a specific task ID is known and a single task is needed. However, it does not explicitly mention alternatives like list_tasks or when not to use this tool. The context is clear but lacks explicit exclusions or alternatives, so a 4 is appropriate.

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

• weeek_attach_fileA
  4.2/5.0
  Behavior4/5

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

  The description transparently discloses the tool's safety boundary (allowed directory and refusal for outside paths) and the configurable directory via WEEEK_ATTACH_DIR. This goes beyond the openWorldHint annotation, which only signals external interaction, providing concrete behavioral guidance for error prevention.

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

  Conciseness5/5

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

  The description is two sentences, front-loads the primary purpose, and immediately follows with a critical safety note. No redundant words or filler. Perfectly sized for quick parsing.

  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 2-parameter tool with openWorldHint and no output schema, the description provides sufficient context: purpose and the key security restriction. It omits return behavior or effects on existing attachments, but these are less critical for a straightforward attach operation.

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

  Parameters3/5

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

  With 0% schema coverage, the description adds meaning for 'path' by detailing the allowed directory constraint, but it does not explicitly clarify path format (absolute vs relative) or elaborate on task_id beyond the task context. Partial compensation for the schema gap.

  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 states a specific verb ('attach'), an object ('local file'), and a target ('WEEEK task'), clearly distinguishing it from all sibling tools. It is unambiguous and immediately understandable.

  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 gives clear context for when to use the tool (attaching a local file to a task) and adds a crucial constraint (only files within the allowed directory). It does not explicitly name alternatives, but no sibling tool serves this purpose, so clear context without exclusions is sufficient.

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

• weeek_list_projectsA
  4.3/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. The verb 'List' implies a read-only operation, and the return format is specified. However, it does not mention authentication requirements, pagination, or any potential side effects, though these are unlikely for a list operation.

  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 entire description is one short sentence with no filler words, perfectly concise.

  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?

  For a tool with no parameters and no output schema, the description sufficiently communicates the purpose and return values. No additional context is necessary for an agent to invoke this tool correctly.

  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 the schema is fully descriptive (empty). The baseline for 0 params is 4, and the description does not need to add parameter info.

  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 uses the specific verb 'List' with the resource 'WEEEK projects' and specifies the return fields (id + name), clearly distinguishing it from sibling tools like weeek_list_tasks and weeek_list_members.

  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?

  No explicit when-to-use or alternative comparisons are provided; the usage is implied by the resource name. Since there are no sibling tools that list projects, this is acceptable but still lacks explicit guidance.

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

• weeek_update_taskA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals a critical non-obvious API behavior: 'description is NOT updatable — WEEEK's API silently ignores it on update.' This is exactly the kind of context that helps an agent avoid costly mistakes. It does not mention return format or side effects, but the core hazard is well covered. No annotation contradiction 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 two sentences long, front-loading the main purpose and then adding a critical caveat. Every word earns its place; there is no fluff or repetition. This is an example of concise, well-structured documentation.

  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 3-parameter tool with no output schema, the description covers the essential aspects: operation, target fields, and a critical limitation. It does not discuss return values or error scenarios, and the 'due' date format is unspecified, but these are minor gaps given the tool's simplicity. The explicit alternative for description updates adds completeness to the overall workflow.

  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 does add some meaning by stating which fields are updatable ('title or due date'), and it warns against passing description (though description is not in the schema). However, it does not explain the expected format for 'due' (e.g., date string format) or clarify that 'id' is the task identifier. The schema property names are fairly self-explanatory, but the description leaves room for 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 function: 'Update an existing WEEEK task's title or due date.' It uses a specific verb ('Update'), names the resource ('existing WEEEK task'), and lists the updatable fields. It also distinguishes itself from siblings by explicitly noting that description is not updatable and pointing to weeek_create_task.

  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?

  Provides explicit usage guidance: use this tool to update title or due date, and do NOT use it for description updates. It names the alternative ('set the description at create time (weeek_create_task) or edit it in the UI'), covering both when to use and when not to use the tool.

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

• weeek_versionA
  4.5/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 the full burden. It explicitly states the tool returns the server name and version, which implies a read-only operation with no side effects. For a simple version query, this is sufficient behavioral disclosure.

  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, front-loaded sentence that states the action and purpose without any filler. Every word earns its place, and there is no redundant information.

  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 trivial nature (no parameters, no output schema, no annotations), the description is complete. It specifies both the return value (server name and version) and the reason (to check the build), leaving no gaps for an agent to correctly invoke it.

  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 the schema shows an empty properties object. The description does not need to explain parameters. With 0 params, the baseline for parameter semantics is 4, and the description adds no unnecessary detail.

  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 returns the MCP server's name and version, which precisely identifies its function. It distinguishes itself from sibling tools that operate on projects, tasks, or members, as no other tool provides version information.

  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 gives clear context: the tool is for checking which build is running. It does not explicitly mention when not to use it or alternatives, but given its unique purpose, no exclusion is necessary. This aligns with 'clear context, no exclusions'.

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

• weeek_delete_taskA
  4.6/5.0
  Behavior5/5

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

  Even though annotations already mark destructiveHint=true and idempotentHint=false, the description adds important context: it emphasizes irreversibility, clarifies that the task is removed rather than completed, and mandates confirm:true. This goes beyond the annotations to explain the operational consequences.

  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?

  Two concise sentences, front-loaded with the action ('Permanently delete'), and every clause adds value: irreversibility, the confirm requirement, and the alternative tool. No 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?

  The description covers the essential aspects for a simple destructive delete operation: what it does, irreversibility, the required confirmation, and an alternative. It does not mention return values, but there is no output schema, and the operation's outcome is clear. Slight lack of mention of permissions or side effects is acceptable given the annotations and simplicity.

  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 50%: the confirm parameter has a description in the schema, while id has none. The description only says 'by id' without adding details about the id parameter's format or source. This is adequate but not compensatory; the confirmation requirement is restated in both places.

  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 starts with a specific verb 'Permanently delete' and clearly states the resource 'WEEEK task by id'. It also distinguishes itself from completing a task by explicitly saying 'not just completed', which differentiates it from sibling weeek_complete_task.

  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 gives explicit guidance: it requires confirm:true and directly names an alternative for a less destructive action ('use weeek_complete_task instead'). This clearly tells the agent when to use this tool versus the sibling completion tool.

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

• weeek_list_membersA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It states the output format (id + display name) and implies a read-only operation ('List'). While it doesn't mention permissions or pagination, the simplicity of the tool and its clear read-only nature provide sufficient transparency for a 0-param list operation.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the purpose and immediately followed by actionable usage guidance. Every word earns its place; no filler or redundant content.

  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?

  For a simple, parameterless list tool with no output schema, the description is fully complete. It explains what is returned and why the agent would need it, making the tool self-contained within the given 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, so the schema already provides complete coverage. The description adds no parameter details because none exist, which is appropriate. Baseline for 0 parameters is 4.

  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 function: 'List WEEEK workspace members (id + display name).' It identifies the specific resource (workspace members) and the verb (list), distinguishing it from sibling tools that handle projects/tasks.

  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 usage guidance is provided: 'Use to find the id for assigning a task to someone; pass that id as `assignee` to weeek_create_task.' This tells the agent exactly when to use this tool and how to integrate it with a related tool.

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

• weeek_create_taskA
  5/5.0
  Behavior5/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 discloses that `due` accepts natural language, that assignee omission results in self-assignment to the token owner, and that reassignment of existing tasks is not supported by the WEEEK API. This goes beyond a simple 'creates a task' and provides meaningful constraints for the 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 four sentences, each serving a distinct purpose: core action, parameter flexibility, efficiency, assignee behavior, and API limitation. It is front-loaded with the action, and no sentence is redundant or verbose. It packs significant guidance into a compact form.

  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?

  Despite having no output schema, the description is remarkably complete for a create tool. It covers required vs optional behavior, parameter formats, self-assignment logic, and an API limitation. The only minor omission is the return value, but that is often obvious for a create operation and is not essential given the clarity of the description.

  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?

  Schema description coverage is 0%, so the description is the only source of parameter semantics. It clearly explains that project/column/assignee accept either name or id, that `due` is a natural-language date, and that assignee has special omission behavior. This adds substantial meaning beyond the bare schema types and refs.

  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 opens with a specific verb+resource: "Create a WEEEK task." This clearly distinguishes it from sibling tools like weeek_update_task, weeek_delete_task, and weeek_list_tasks. It further clarifies scope with "One call — no need to look up ids first," adding a unique value proposition.

  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 usage guidance: it states that project/column/assignee can be passed by name or id, eliminating the need for prior lookups. It also gives conditional instructions for assignee (omit for self-assign, pass name/id for someone else) and explicitly warns that reassigning an existing task is unsupported, steering users toward creation-time assignment rather than attempting updates.

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