Server Quality Checklist

Tool Scores

• search_clipboardC
  2.9/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 only restates the search action and result type; it does not mention read-only behavior, default limits, sorting, or empty-query behavior. The schema covers some parameter behavior, but the description itself adds little beyond the name.

  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 two short sentences with no filler and the core action is front-loaded. However, the second sentence largely restates the first, adding only the return type.

  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 no output schema, no annotations, and overlapping sibling tools, the description omits usage distinctions and behavioral details needed for confident tool selection. The parameter schema helps, but the description alone is not sufficient to know when this tool should be preferred over alternatives.

  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 100%, so the schema already documents all four parameters. The description only generically references 'the query' and adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

  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 identifies the verb (search), the resource (clipboard history), and the return type (list of paste items). It is distinguishable from siblings like get_paste_item and add_to_clipboard by implication, though it does not explicitly name alternatives.

  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?

  There is no guidance on when to use this tool versus get_paste_item, list_tags, or add_to_clipboard. It also does not mention that query is optional or that an empty query returns recent items; usage context is only implied by the tool name.

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

• get_paste_itemA
  3.8/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 burden. It communicates that the operation is a read ('Get') and that the result is the item's full content, but it does not disclose error behavior, permissions, or response formatting. This is minimal but non-zero 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 is a single front-loaded sentence that states the action, target, and selection criterion without wasted words. Every part contributes to understanding.

  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 tool, the description plus schema gives an agent enough to invoke it correctly with a valid ID. It would be more complete with explicit error/not-found behavior or a note on when to prefer search_clipboard, but those are not critical for basic invocation.

  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?

  The input schema already describes the single parameter ('The paste item ID') with 100% coverage. The description only restates that lookup is by ID and adds no additional type, format, or constraint details 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 ('Get') and resource ('full content of a specific clipboard item'), with a clear retrieval-by-ID scope. This distinguishes it from sibling tools like search_clipboard or get_clipboard_stats.

  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 the tool is for retrieving a known clipboard item by ID, but it does not explicitly state when to use it over search_clipboard or mention any exclusions. An agent can infer the use case but receives no direct routing guidance.

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

• get_clipboard_statsA
  3.9/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the transparency burden. The verb 'Get' implies a read-only operation, but side effects, permissions, and rate limits are not explicitly addressed. It is reasonably clear but not fully transparent.

  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, focused sentence. It is front-loaded with the action and resource, followed by the key output details, with no unnecessary words.

  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?

  There is no output schema, and the description gives a useful high-level summary of the return values: total count and size by type. However, it does not specify the exact output format, units for size, or the shape of the 'by type' grouping, so it is not fully complete.

  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 tool has zero parameters, so there is nothing to document. The schema coverage is vacuously complete, and no parameter explanations are needed.

  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: retrieving clipboard statistics. It specifies the resource (clipboard) and the exact scope (total count and size by type), which distinguishes it from siblings like search_clipboard, list_tags, and add_to_clipboard.

  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 does not explain when to use this tool versus alternatives. It does not mention that list_tags or search_clipboard should be used for different needs, or provide any decision guidance beyond the basic purpose.

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

• list_tagsA
  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 behavioral burden. 'List all' communicates that this is a read-only aggregation of tags, but it does not disclose return format, ordering, or behavior with untagged items. Some essential behavior is conveyed, but the description is thin.

  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?

  One concise sentence states the action, object, and purpose with no redundant wording. The key verb and resource appear immediately.

  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 parameterless list operation with no output schema, the description is largely sufficient: an agent can infer the call is safe and returns clipboard tags. It would benefit from specifying the return type (e.g., array of tag strings), but the low complexity keeps the gap minor.

  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?

  There are no parameters, so the input schema is complete by definition. The description adds no parameter details, but none are needed; the baseline for zero-parameter tools applies.

  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') with a clear resource ('all clipboard tags') and a purpose ('organizing paste items'). It is immediately distinguishable from siblings like get_paste_item, search_clipboard, and add_to_clipboard because it targets tags rather than items or stats.

  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 phrase 'for organizing paste items' gives context for why tags exist, but it does not explicitly state when to choose this tool over siblings or when not to use it. Usage is implied rather than stated.

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

• add_to_clipboardA
  4.2/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It discloses input format constraints well, including file paths and color representations. However, it does not explain what side effects adding to clipboard history has, such as whether it also changes the system clipboard or only appends to history.

  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-load the core action and resource, then efficiently provide type-specific usage details. No redundant or filler language is present.

  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 two-parameter tool with no output schema and no annotations, the description covers all necessary input semantics and format nuances. It is slightly incomplete in that it does not mention return values or post-conditions, but those are not essential for successful invocation.

  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?

  Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by detailing valid color formats (hex, rgb(), rgba(), hsl(), hsla(), CSS name) and emphasizing absolute file paths for file/image types, which are not fully enumerated in 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 clearly states the action ('Add content') and resource ('clipboard history'), and enumerates the supported content types. This distinguishes it from sibling tools like search_clipboard, get_paste_item, and get_clipboard_stats, which are read/search 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 provides clear context for what content types are supported and gives format requirements for file/image and color inputs. It does not explicitly contrast with sibling tools, but its write-oriented purpose is obvious alongside read/search siblings, so the intended usage is easy to infer.

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