Loading ToolBench
Single tool with clear naming (getClipboardContents) and a strong, descriptive description (145 chars, within the 10-1024 baseline). However, critical gaps in schema documentation, parameter descriptions, and error handling. The input schema is correctly defined as an empty object {}, but there is no documented output schema, which violates pattern:tool. The tool executes successfully but provides no guidance to LLMs on what fields to expect in the response or how to handle different content types (text vs image vs binary). Error handling uses UserError but does not provide recovery guidance or categorization. The description itself is good (tells WHAT the tool does, WHEN to use it, and emphasizes non-caching), but the lack of output documentation and error recovery patterns prevents a higher score.
Fetch the contents of the clipboard (text, images, or binary data). Used to see what is on the clipboard. IMPORTANT: This tool should be called every time clipboard contents are needed as clipboard data can change; results should not be cached.
No documented output schema. The tool returns ContentResult with varied content types (text, PNG image, binary data) but LLMs cannot see the expected structure of the response. This violates pattern:tool and pattern:response-shaper.
Input schema is empty object {} with no parameters. While correct, there is no explicit documentation of what the tool accepts or any constraints. For an input-less tool, this is acceptable, but the schema could be more explicit in code comments or README.
Error handling does not provide recovery guidance. When clipboard retrieval fails, the error message states 'Error retrieving content from the clipboard' but does not guide the LLM on what to try next (e.g. 'Check macOS permissions' or 'Retry after a moment'). Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
No return value documentation visible in the tool definition itself. The code handles three content types (text, PNG image, binary) but there is no comment or docstring explaining the ContentResult structure or the three possible paths an LLM might encounter. This forces LLMs to infer the response shape.