This Go MCP server exposes 9 well-defined clipboard management tools with consistent naming, explicit input schemas, and clear descriptions. All tools follow verb_noun naming conventions (search_clipboard, get_recent_items, copy_to_clipboard, etc.) and are registered with JSON Schema definitions visible in server.go. Descriptions are present for all tools and parameters, ranging from 40-80 characters. Input schemas include proper type definitions (string, number, boolean) with validation rules (regex patterns, enums, defaults). However, output schemas are NOT documented in the source code, handlers return mcp.CallToolResult but the structure is not specified. Error handling is minimal: handlers return basic errors without recovery guidance. The server uses STDIO transport, which is a hard architectural constraint preventing it from being accessed by hosted MCP clients. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible despite clear risk classifications (WRITE vs READ_ONLY). Security is reasonable (no secrets as parameters, input validation via regex), but audit logging and permission gates are absent.
Copy a specific history item back to current clipboard
Export clipboard history to a local file
Get clipboard usage statistics
Get the full content of a specific clipboard item
Get clipboard items from specific application
Get recent clipboard items with optional filters
Pin a clipboard item for persistence
Output schemas not documented. Handlers return mcp.CallToolResult but the response structure (fields, types, nested objects) is not specified in code or comments. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect.
No tool annotations (toolAnnotations feature false). WRITE operations (copy_to_clipboard, pin_item, unpin_item, export_history) lack readOnlyHint:false / destructiveHint markers. Agents cannot determine if a tool has irreversible consequences or is safe to retry.
Error handling lacks recovery guidance. handlers.go shows basic error returns (e.g. 'invalid since date: %w') but does not provide actionable guidance: what should the LLM do next? Can it retry? Should it ask the user? See handleSearchClipboard and other handlers.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Search clipboard history by text pattern or regex
Unpin a clipboard item
STDIO transport only. The server calls server.ServeStdio(s) in Run(). STDIO is not remotely accessible and cannot be used by hosted MCP clients or via HTTP bridging. Hard cap on Protocol Readiness applies.
Pagination not implemented. List-like tools (get_recent_items, get_items_by_app, search_clipboard) accept a 'limit' parameter but do not document pagination mechanism (offset/cursor, total count, next marker). Large result sets could exhaust context window.
get_clipboard_stats description is vague ('Get clipboard usage statistics'). What statistics? Count of items? Storage used? Frequency by application? This ambiguity invites LLM misuse.
parameter descriptions lack format and constraint details. 'since' and 'until' accept 'ISO date string' but handler validates with time.RFC3339, this format should be explicit in description. 'file_path' has a regex pattern but no guidance on absolute vs relative paths.