Tupper MCP provides 6 tools with clear verb-noun naming (create_sandbox, list_sandboxes, run_command, read_file, write_file, kill_sandbox). All tools have descriptions (10-60 chars) and input schemas with typed parameters. However, descriptions are minimal (below the 194-char baseline for production tools), parameter descriptions lack detail about constraints and formats, and output schemas are not documented. No error handling guidance, no idempotent hints, and no recovery paths for destructive operations. Tool composition is sound (each does one thing), but descriptions do not explain WHEN to use each tool or what to expect in responses.

• Expand all tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this after create_sandbox to verify the sandbox is running'), WHAT it returns (e.g., 'Returns sandbox ID, status, and creation timestamp'), and any prerequisites (e.g., 'Requires a valid sandbox ID from create_sandbox').
• Document output schemas for all tools. For create_sandbox, specify: {id: string, status: 'running'|'pending', created_at: ISO8601, image: string, backend: string}. For list_sandboxes, specify: {sandboxes: [{id, status, created_at, image}], total: number}.
• Add constraint details to parameter descriptions. E.g., 'image: OCI image reference (e.g., ubuntu:22.04, format: registry/repo:tag, max 256 chars)'. For command: 'shell command to run (bash syntax, max 10000 chars, timeout 30s)'.
• Add tool annotations: mark read_file and list_sandboxes with readOnlyHint=true; mark write_file, run_command, create_sandbox, kill_sandbox with destructiveHint=true (or idempotentHint=true if applicable). This guides agent retry logic.
• Add error handling guidance. E.g., for kill_sandbox: 'If sandbox not found, returns error 404 with message "Sandbox {id} not found. Call list_sandboxes to verify the ID." This is not retryable, check the ID and try again.'