MCP server for managing printer clients via WebSocket and sending images to connected printers
Server has 5 tools with basic schemas and descriptions, but significant quality gaps. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization). Input schemas are present but minimal: most parameters lack detailed descriptions beyond a single phrase. HelloParams has no description at all. PrintImageParams has optional fields but no guidance on mutual exclusivity. Error handling is present but returns unstructured JSON strings instead of structured error objects. No tool annotations (readOnlyHint/destructiveHint). Output schemas are not formally documented, responses are hand-built JSON strings. Parameter validation is basic (checks for empty strings) but lacks actionable error messages. No pagination, no batch operations. Tool composition is reasonable (separate concerns) but parameter naming could be clearer (e.g., 'nonce' is opaque; should accept printer names too).
Disconnect a printer client by nonce
Say hello to someone
List all connected printer clients
Send an image to a connected printer client for printing
Get the connection status of a specific printer client
Tool descriptions are too short (10-50 chars vs. baseline 50-200 chars). LLMs cannot determine when/why to select tools. E.g., 'Say hello to someone' lacks context; 'Send an image to a connected printer client for printing' is better but still minimal.
Parameter descriptions are missing or trivial. HelloParams.name has no description. PrintImageParams fields lack guidance on mutual exclusivity (imageB64 vs imagePath). LLMs cannot infer parameter meaning from names alone.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot determine which tools are safe to retry. print_image and disconnect_client modify state but lack destructiveHint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Output schemas are not formally documented. Responses are hand-built JSON strings (e.g., toolResultFromPrintImage). LLMs cannot parse expected fields reliably. Should return structured CallToolResult with typed Content.
Error messages are unstructured and lack recovery guidance. E.g., 'failed to send image: %v' tells the agent nothing actionable. Should follow pattern:recovery-guide with specific next steps.