Server Quality Checklist

Tool Scores

• list_reminder_listsA
  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 full burden of behavioral disclosure. It states that the tool lists all reminder lists, which implies a read-only operation, but it does not disclose any additional behavioral traits such as whether hidden lists are included, if any permissions are needed, or how results are ordered. This is adequate for a simple zero-parameter tool but lacks depth.

  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, complete sentence that is front-loaded with the action and object. It contains no fluff or redundant information, 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.

  Completeness5/5

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

  Given the tool's simplicity (zero parameters, clear purpose), the description fully covers what the tool does. An output schema exists to describe return values, so the description does not need to explain those. It is contextually complete for its scope.

  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 input schema adds no information. The baseline for 0 params is 4, and the description does not need to add parameter-level semantics. It correctly focuses on the tool's action rather than parameter details.

  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 a specific verb ('List'), resource ('reminder lists'), and context ('macOS Reminders app'), and it distinguishes itself from sibling tools that operate on individual reminders (e.g., list_reminders, create_reminder). It is unambiguous and informative.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not explicitly state that this is for obtaining list metadata or IDs before working with reminders, nor does it contrast with list_reminders. The usage is only implied by the tool's name and purpose, offering no exclusion criteria.

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

• complete_reminderA
  4.2/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 of explaining behavior. It does disclose the return value (True if found and completed, False otherwise) and the effect of the optional list_name. However, it does not address edge cases like duplicate names, idempotency (already completed), or permissions, leaving gaps in full 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 concise and well-structured: a one-line purpose, an Args section with per-parameter explanations, and a Returns section. No redundant or extraneous content earns a top score.

  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 tool with 2 parameters and a boolean return, the description covers the essential aspects: purpose, parameters, and return value. It does not cover edge-case behavior, but given the simple scope and the presence of an output schema, this is largely sufficient.

  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 schema has 0% description coverage, so the description must compensate. It explains both parameters: 'name' must be the exact name, and 'list_name' is optional and 'narrow[s] the search'. This adds meaningful context beyond the schema, though it could be more detailed about formatting or uniqueness.

  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 action with the specific verb 'Mark' and the resource 'reminder', along with the action 'completed'. This distinguishes it from sibling tools like create_reminder, update_reminder, and delete_reminder by focusing specifically on the completion status.

  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 that this tool is for completing a reminder, and the optional list_name parameter narrows the search. However, it does not explicitly mention when to choose this over update_reminder or list any exclusions, so it falls short of a perfect score.

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

• list_remindersA
  4.2/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 the default behavior for include_completed (False) and the filtering semantics for list_name, but does not explicitly state the operation is read-only, nor disclose return format, pagination, or sorting. It provides a basic but not comprehensive behavioral profile.

  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?

  Very concise: a one-sentence summary followed by a compact Args block. No redundant text, information is front-loaded, and every sentence adds value.

  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 tool with two parameters and an output schema (which covers return format), the description covers the essential behaviors. It could be slightly improved by mentioning that the operation is read-only, but it is complete enough to use correctly. It does not discuss alternatives, but that is not required for 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?

  The schema provides types and defaults but no property descriptions (0% coverage). The description explains each parameter meaningfully: list_name filters by a specific list and handles empty input, while include_completed controls inclusion of completed items with its default. This adds significant semantic value beyond the 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 uses a specific verb ('List') and resource ('reminders from the macOS Reminders app'), clearly distinguishing it from sibling tools like list_reminder_lists (which lists lists) and mutation tools. The purpose is unambiguous and front-loaded.

  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?

  Provides clear context on the tool's function and filtering options (list_name, include_completed). However, it does not explicitly mention when to use this over sibling tools (e.g., list_reminder_lists) or any exclusions, so it stops short of full guidance.

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

• create_reminderA
  4.3/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. It clearly states the action (create), the default list behavior, optional parameters, and return value. It does not mention permissions or side effects, but for a simple create operation, it provides sufficient 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 well-structured with a clear opening sentence, an Args block, and a Returns line. Every sentence adds value, including the date format example. No fluff or 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?

  The description covers all parameters and return value, making it complete for a simple CRUD creation tool. It lacks details on potential errors or prerequisites, but these are not critical for such a straightforward operation.

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

  Parameters5/5

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

  The description adds full meaning to all four parameters, compensating for the 0% schema description coverage. It explains name, list_name (including default behavior), due_date (with example format), and notes. This goes far beyond the schema titles and defaults.

  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 new reminder in the macOS Reminders app.' This clearly distinguishes the tool from siblings like list_reminders (read), update_reminder, complete_reminder, and delete_reminder.

  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?

  Usage context is implied by the verb 'create' and the description of adding to a list, but there is no explicit guidance on when to prefer this tool over alternatives like update_reminder or complete_reminder. Exclusions and alternatives are not mentioned.

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

• update_reminderA
  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 clearly states the return value: 'True if the reminder was found and updated, False otherwise.' It also discloses that leaving optional fields empty means 'keep unchanged,' which is key for an update 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 efficiently structured with an Args section and a Returns section. It covers all necessary details without redundancy. Every sentence adds value, and the content is well organized for quick parsing.

  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 CRUD tool with five parameters and one required, the description is comprehensive. It documents all parameters, explains the search-narrowing behavior, and specifies the boolean return value. The output schema likely defines the return type, but the description adds explicit semantics that are valuable.

  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 schema's parameter descriptions are entirely absent (0% coverage), so the description must compensate. It provides thorough explanations for all five parameters, including a concrete example for due_date ('February 28, 2026 at 9:00 AM') and the exact semantics of name and list_name.

  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 properties of an existing reminder.' This specifies a verb and resource, and distinguishes it from siblings like create_reminder, complete_reminder, and delete_reminder.

  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 by explaining that 'name' is required and 'list_name' narrows the search, but it does not explicitly state when to use this tool versus alternatives. There is no mention of 'use create_reminder for new reminders' or similar, leaving the guidance to inference.

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

• delete_reminderA
  4.6/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 states that deletion is permanent, requires the exact name, and returns True/False based on whether the reminder was found and deleted. This covers key behavior, though it does not mention idempotency, errors, or side effects beyond deletion.

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

  Conciseness5/5

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

  The description is highly concise: one primary action sentence, followed by a structured Args/Returns section. Every sentence provides value, with no redundant or vague phrasing. It is front-loaded with the essential purpose.

  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 two-parameter deletion tool, the description covers the action, parameters, and return behavior. It also notes the permanence of the delete operation. The presence of an output schema does not reduce the need here, as the description already explains return values. There are no gaps in understanding how to invoke this tool.

  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?

  Since schema description coverage is 0%, the description must fully explain the parameters. It does: 'name' is described as the exact name of the reminder, and 'list_name' is described as an optional narrow search. This adds significant meaning beyond the schema's simple field 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 opens with 'Delete a reminder permanently,' which clearly states the action and target resource. This distinguishes the tool from siblings like create_reminder, update_reminder, and complete_reminder by using the specific verb 'delete' and noting permanence.

  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: when you want to permanently remove a reminder. It also explains the optional 'list_name' parameter as a way to narrow the search, guiding usage. However, it does not explicitly contrast with alternatives like 'complete_reminder,' so it misses a full when-not-to-use explanation.

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