Server Quality Checklist

Tool Scores

• get_active_tasksA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list of active tasks, implying a read-only operation, but does not disclose other behavioral traits such as authentication requirements, rate limits, error conditions, or the format of the returned list. For a tool with zero annotation coverage, this is a significant gap.

  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 concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidelines. Every sentence adds value, and there is no wasted text, making it front-loaded and efficient.

  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 low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete for its purpose. However, it lacks details on behavioral aspects like authentication or output format, which could be important for an AI agent to use it correctly, especially without 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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description does not add parameter semantics, which is appropriate here, but it could have mentioned if any implicit parameters (e.g., user context) are involved. Baseline is 4 for zero 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: 'get a list of all active (uncompleted) tasks from the user's OmniFocus.' It specifies the verb ('get'), resource ('active tasks'), and scope ('from the user's OmniFocus'), but does not explicitly differentiate it from sibling tools like 'get_all_tasks' beyond the 'active' qualifier.

  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 usage context: 'Use it when the user asks for their 'active tasks', 'current tasks', or 'open tasks'.' This gives explicit guidance on when to invoke the tool, but does not mention when not to use it or name alternatives among the sibling tools.

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

• get_active_projectsA
  4.4/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 the full burden. It describes the tool's behavior as retrieving a list of active projects, which is adequate but lacks details like response format, pagination, or error handling. It doesn't contradict any annotations.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose in the first sentence, followed by usage guidance in the second. Both sentences earn their place with no wasted words, making it highly efficient and well-structured.

  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 tool with 0 parameters, no annotations, and no output schema, the description is complete enough by clearly stating what it does and when to use it. It could slightly improve by hinting at the return format, but it's largely sufficient given the low complexity.

  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, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining focus on the tool's purpose and usage.

  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 verb ('get a list') and resource ('all active projects from OmniFocus'), explicitly distinguishing it from siblings by specifying 'active (not completed or dropped)' projects rather than all projects or 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?

  It provides explicit guidance on when to use this tool ('when the user asks for their "active projects" or "current projects"'), with clear context that distinguishes it from sibling tools like 'get_all_projects' or 'get_active_tasks'.

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

• get_all_projectsA
  4.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 of behavioral disclosure. It clearly indicates this is a read operation ('get a list'), but doesn't mention potential limitations like rate limits, authentication requirements, or response format details. The description adds basic context about what data is included but lacks richer behavioral information.

  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 consists of two focused sentences with zero wasted words. The first sentence establishes purpose and scope, the second provides clear usage guidance. Every element serves a specific function, making it efficiently structured and appropriately sized for its complexity level.

  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 zero parameters and no output schema, the description provides adequate context: purpose, scope, and usage guidance. However, without annotations or output schema, it could benefit from mentioning what the return format looks like (e.g., list structure, fields included) to be fully complete for agent consumption.

  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 appropriately doesn't discuss parameters since none exist, which is correct for a parameterless tool. No additional parameter semantics are needed or provided.

  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 ('get a list of all projects') and resource ('from OmniFocus'), with explicit scope differentiation ('including completed and dropped ones'). It directly distinguishes this tool from its sibling 'get_active_projects' by specifying it returns all projects rather than just active ones.

  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: 'Use it when the user explicitly asks for 'all projects''. This creates a clear boundary for when to select this tool versus its siblings (like 'get_active_projects'), effectively telling the agent when this specific tool is appropriate.

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

• get_all_tasksA
  4.4/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 the full burden of behavioral disclosure. It states the tool retrieves a list of all tasks, implying a read-only operation, but lacks details on potential limitations like rate limits, authentication needs, or how the data is structured in the response. It adds basic context but misses richer 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.

  Conciseness5/5

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

  The description is front-loaded and concise, consisting of two sentences that directly address purpose and usage without any wasted words. Every sentence adds clear value, making it efficient and well-structured for quick comprehension by an AI agent.

  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 simplicity (0 parameters, no annotations, no output schema), the description is largely complete. It covers the core purpose and usage guidelines effectively. However, it could be more complete by briefly mentioning the response format or any implicit constraints, though this is a minor gap for such a straightforward tool.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. A baseline of 4 is applied as it correctly omits unnecessary parameter details, though it could slightly enhance value by noting the lack of filters (e.g., no date ranges).

  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 with a specific verb ('get') and resource ('list of all tasks from OmniFocus'), including the scope ('including completed ones'). It distinguishes this tool from siblings like 'get_active_tasks' by explicitly mentioning completed 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?

  The description provides explicit guidance on when to use this tool: 'when the user explicitly asks for 'all tasks' or 'completed tasks'.' This directly addresses usage scenarios and implicitly suggests alternatives (e.g., 'get_active_tasks' for non-completed tasks), making it highly actionable for an AI agent.

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