Strong naming conventions (verb_noun pattern across all 8 tools). Descriptions are present and substantive (100-200 chars typical), clearly stating what each tool does and safety implications. Input schemas are complete with proper JSON Schema types and enums. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is implicit (confirm:true gates) but lacks explicit recovery guidance. Tool composition is sound: read-only tools (get, list, download, events) are ungated; destructive tools (send, submit, delete) require confirm:true; cancel is safe and ungated. No tool annotations (readOnlyHint, destructiveHint) present in code.

• Document output schemas for all 8 tools. Specify what fields are returned (e.g., letter_id, status, created_at, recipient_address) and their types. This enables LLMs to chain tools and extract the right data.
• Add tool annotations to the tool registration: readOnlyHint=true for get_letter, list_letters, download_letter, get_letter_events; destructiveHint=true for send_letter, submit_letter, delete_letter; idempotentHint=true for cancel_letter (safe to retry).
• Expand pingen_list_letters description to document pagination: 'Returns up to [N] letters. Use limit and status parameters to filter. Returns total_count and next_cursor for pagination.' Add limit and status parameter descriptions.
• Add explicit error recovery guidance to destructive tool descriptions. E.g., 'If submission fails with a 400 error, the draft remains in the account, call pingen_cancel_letter to discard it, or pingen_submit_letter to retry.'
• Enhance read-only tool descriptions (get_letter, download_letter, get_letter_events) to clarify when to use each. E.g., 'Use get_letter for metadata and status; use download_letter to retrieve the PDF; use get_letter_events to track delivery progress.'