Three well-named tools with comprehensive descriptions and detailed input schemas. secure_send has excellent documentation (400+ chars) explaining encryption, modes, and limits. All parameters are typed and described. However, output schemas are not explicitly documented in the visible code, responses are inferred from API behavior rather than formally declared. Error handling is present but generic (apiDetail helper). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, READ_ONLY, DESTRUCTIVE). Parameter validation is defensive (MIME inference, size checks) but error messages could be more actionable for LLM recovery.

• Add explicit output schema documentation for each tool. E.g., secure_send returns {sendId: string, link: string, key?: string, expiryTime: ISO8601}. Include this in the tool definition or a separate schema block.
• Declare tool annotations: secure_send with destructiveHint=false (it's WRITE but not destructive), secure_send_status with readOnlyHint=true, secure_send_revoke with destructiveHint=true. This enables LLMs to reason about safety and retry logic.
• Enhance error messages with recovery guidance. E.g., 'File too large (5MB > 3MB limit). Use fileBase64 with a smaller file, or split into multiple sends.' instead of raw API error text.
• Expand secure_send_status and secure_send_revoke descriptions to 150+ chars. Explain what event history contains (download timestamps, IP addresses?) and that revocation is permanent.
• Add a confirmation step for secure_send_revoke: return a confirmation token and require it in a separate revoke_confirm tool, or document that the agent should ask the user before calling revoke.