Server Quality Checklist

Tool Scores

• file_listC
  2.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 disclosure burden but reveals nothing about behavioral traits: output format (array of strings vs objects?), error conditions (permission denied, path not found), or whether the operation is read-only.

  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?

  Extremely brief (3 words) and front-loaded with the verb. However, brevity crosses into under-specification—lacking the substance needed to distinguish from siblings or explain behavior, which costs points in a completeness context.

  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?

  For a 1-parameter tool with no output schema and zero annotations, the description is insufficient. It omits critical context like return value structure, pagination for large directories, or symlink handling that an agent needs to invoke and process results 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?

  Schema coverage is 100% ('path' is well-described as 'Directory path'), establishing a baseline of 3. The description adds no additional parameter context (e.g., whether absolute or relative paths are preferred), but is not required to given complete schema coverage.

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

  Purpose2/5

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

  The description 'List directory contents' is minimal and approaches tautology, restating the tool name 'file_list' with slight expansion. It fails to specify scope (e.g., recursive vs. shallow, hidden files) or clearly differentiate from sibling 'file_read' (which reads file contents vs. listing them).

  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?

  No guidance provided on when to use this tool versus alternatives like 'file_read'. Does not mention prerequisites like path existence or permissions needed to list the directory.

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

• file_writeC
  2.5/5.0
  Behavior2/5

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

  No annotations provided, so description carries full disclosure burden. 'Write' implies mutation but fails to specify destructive traits: overwrite behavior, directory auto-creation, encoding, or atomicity. Critical gaps for a file 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.

  Conciseness3/5

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

  Single sentence of four words is front-loaded and efficient, but borders on under-specification given the tool's destructive potential and lack of annotations. Appropriately concise structure, yet insufficiently sized for the complexity.

  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?

  Mutation tool with no annotations, no output schema, and undocumented behavioral edge cases (existing files, permissions). Description inadequate for safe agent operation; missing safety-critical context.

  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 clear descriptions ('Absolute path', 'File content'). Description adds no semantic detail beyond schema baseline, but schema adequately covers both required parameters.

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

  Purpose3/5

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

  States the verb (write) and resource (file) but provides minimal elaboration beyond the tool name 'file_write'. Does not differentiate from sibling 'file_read' or clarify write semantics (create vs overwrite).

  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?

  Contains no guidance on when to use this tool versus siblings like 'file_read', or prerequisites like directory existence. No mention of overwrite behavior or error conditions.

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

• notification_sendC
  2.7/5.0
  Behavior2/5

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

  No annotationsprovided, so description carries full burden. Fails to disclose whether this blocks execution, requires specific OS permissions, handles display duration, or returns success/failure indicators.

  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?

  Extremely efficient at four words with no redundancy. Front-loaded with the action verb. However, excessive brevity given the lack of schema documentation and annotations leaves it underspecified.

  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?

  Inadequate for a tool with zero schema descriptions and no annotations. Missing critical context: error conditions, display behavior, permission requirements, and parameter details needed for correct invocation.

  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 has 0% description coverage, requiring the description to compensate. Description omits semantics for 'title' and 'body' parameters (length limits, formatting support, required vs optional nature) despite being able to infer basic purpose from the tool name.

  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?

  Clear verb+resource ('Send a desktop notification') that distinguishes from file and clipboard siblings. However, lacks specificity about the notification mechanism (OS native vs in-app) or target user.

  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?

  No guidance on when to use versus alternatives (e.g., when to send a notification vs writing to a log file), prerequisites, or conditions where notifications might fail (permissions disabled, DND mode).

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

• app_launchC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. States only the action intent without disclosing execution semantics (async vs sync, error behavior, window management, or privilege requirements).

  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?

  Extremely terse at 6 words. Front-loaded with action verb. Efficient but arguably too lean given the lack of annotations and behavioral disclosure.

  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?

  Minimal viable documentation for a single-parameter tool. Lacks coverage of execution side effects and error states that would be expected given zero annotation coverage and no output schema.

  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 the parameter fully described via examples. Description adds no additional parameter context beyond what the schema provides, which warrants the baseline 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?

  Clear specific verb ('Launch') and resource ('desktop application'), with mechanism clarification ('by name'). Distinguishes implicitly from sibling file/clipboard/notification tools, though lacks explicit differentiation.

  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?

  No guidance on when to use versus alternatives, error handling, or prerequisites. Fails to mention that the application must be installed/available or what happens if the name is invalid.

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

• file_readB
  3.1/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. 'Read contents' implies a safe read operation but discloses nothing about encoding handling, binary vs. text modes, size limits, file locking, or error behaviors (404, permission denied).

  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?

  Extremely concise at 4 words. Front-loaded with action first. No filler or redundant text. Every word earns its place despite minimal information content.

  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 single parameter with 100% schema coverage, description is minimally adequate for invocation. However, lacks critical context due to missing output schema: does not indicate return format (string, bytes, object) or content size limitations, which are essential for a read operation tool.

  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 has 100% description coverage ('Absolute path to file'), so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

  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?

  States specific verb 'Read' and resource 'contents of a file', making the basic purpose clear. However, it does not differentiate from sibling clipboard_read (both read) or file_list (both file operations), though the distinction is inferable from the tool names.

  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?

  Provides no guidance on when to use this vs. file_list (directory listing vs. content reading), vs. clipboard_read, or error conditions (permissions, missing files). No prerequisites or alternatives mentioned.

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

• clipboard_readB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden but fails to disclose return format (text/binary/object), error conditions (empty clipboard), or permission requirements.

  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?

  Single sentence with no extraneous text. Appropriate length for a simple parameterless tool—every word earns its place.

  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?

  Adequate for basic identification but incomplete regarding output format. Without an output schema, the description should indicate what data structure or type is returned (string, object, etc.).

  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?

  Zero-parameter tool with 100% schema coverage (empty object). Baseline score applies as the description correctly implies no arguments are needed.

  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 (read) and resource (clipboard contents), distinguishing it from sibling file_read and app_launch tools. However, 'contents' is vague regarding data type/format returned.

  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?

  No guidance provided on when to use this versus alternatives (e.g., when clipboard contains a file path vs using file_read directly) or prerequisites like clipboard permissions.

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