Server Quality Checklist

Tool Scores

• omnifocus_analyzeA
  3.9/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent), the description adds detailed performance warnings (e.g., pattern_analysis on 1000+ items takes 5-10 seconds) and caching behavior, which is excellent for agent decision-making.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (ANALYSIS TYPES, PERFORMANCE WARNINGS, SCOPE FILTERING) and front-loads the purpose. It is reasonably concise with no redundancy.

  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 (multiple analysis types, nested params) and no output schema, the description covers scope, performance, and some param details. Missing explicit output format, but still fairly 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?

  Schema coverage is 0% and the description partially compensates by detailing params for manage_reviews and mentioning scope filtering. However, not all analysis types' params are described, leaving gaps.

  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 analyzes OmniFocus data for insights and lists specific analysis types. It is distinct from sibling tools (read/write) but does not explicitly differentiate them.

  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 context for when to use each analysis type and performance warnings, but it does not offer explicit guidance on when to avoid this tool or compare it with siblings like omnifocus_read.

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

• systemA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context by specifying the nature of each operation (e.g., 'test OmniFocus connection', 'get cache statistics'), which aligns with the annotations. It does not introduce any contradictions.

  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 concise sentences. The first lists capabilities, and the second provides explicit usage mappings. Every sentence adds value, and the structure is front-loaded with the purpose.

  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 is a system utility with no output schema and fully described parameters, the description covers all key operations and their usage. It could explicitly mention that the tool is read-only (though annotations already do), but overall it is complete for its purpose.

  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 100%, with all parameters having descriptions. The description adds minor value by explaining the operation parameter's mapping in detail, but does not provide additional meaning for other parameters beyond what the schema already offers. Baseline of 3 is appropriate.

  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 it is for 'System utilities for OmniFocus MCP' and enumerates specific operations: version, diagnostics, metrics, cache. This provides a clear verb+resource combination and distinguishes from sibling tools (analyze, read, write) which handle data operations.

  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 explicitly maps operation values to their actions, e.g., 'Use operation="version" for version info'. This provides clear guidance on when to use each operation. However, it does not explicitly say when to use this tool versus the sibling tools, though the context is implied.

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

• omnifocus_writeA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds detailed behavioral context: 'Delete is permanent', batch execution order, date defaults (due=5pm, defer=8am), move-to-inbox via project: null, and support for nested paths. It does not contradict annotations.

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

  Conciseness4/5

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

  The description is lengthy but well-organized with section headers (OPERATIONS, FOLDER CREATION, BATCH, etc.) and front-loaded with a summary. Every section is informative and necessary given the tool's complexity. It could be slightly more concise (e.g., repeating examples), but overall it is efficient for the domain.

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

  Completeness4/5

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

  Given the tool's complexity (multiple operations, nested parameters) and lack of output schema, the description covers inputs thoroughly, including date formats, tag management, and batch behavior. It does not describe return values, which is acceptable for a mutation tool. The description is sufficiently complete for an AI agent to invoke correctly.

  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 input schema has 0% description coverage (only target_id and completionDate have descriptions). The description fully compensates by explaining the mutation object structure, each operation's required/optional fields, aliases (target_id for id), and examples (batch, tag_manage). It adds semantics not present in schema, like 'data accepted as alias for changes' and 'target defaults to task'.

  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, update, complete, or delete OmniFocus tasks and projects.' It lists all operations and distinguishes itself from sibling tools (omnifocus_analyze, omnifocus_read) which are read-only. The verb 'manage' in the title also reinforces 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 each operation, including batch usage, folder creation, and tag management. It includes safety warnings ('Delete is permanent - confirm with user first'), execution order in batches, and data formats. It clearly differentiates from alternatives by stating it is for mutations, while siblings are for reading/analysis.

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

• omnifocus_readA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: default fields, ID lookup returns full details, performance notes, and export behavior. No contradiction.

  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 long but well-structured with sections and examples. It is front-loaded with a clear summary. A minor reduction for length, but each section earns its place given complexity.

  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?

  Highly complete: covers all aspects of usage including response control, pagination, performance, export details, and field lists. No output schema, but description sufficiently describes return behavior.

  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 has 0% description coverage, but the description explains every parameter in detail: types, modes, filters, fields, sort, limit, countOnly, etc. It adds immense value beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states it queries OmniFocus data with flexible filtering, lists supported types (tasks, projects, tags, etc.), and distinguishes itself from sibling tools (omnifocus_write, omnifocus_analyze) by being read-only.

  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 extensive, explicit guidance: common queries, modes (with constraints like 'tasks queries ONLY'), filter operators, response control, performance tips, and caveats (e.g., includeCompleted only for export). Clearly differentiates when to use modes vs filters.

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