Gmail tools have well-structured schemas with proper Zod validation and type definitions. Descriptions are present and moderately detailed (avg ~120 chars). However, several parameter descriptions lack actionable constraints, and output schemas are not formally documented. Tool naming follows verb_noun convention (gmail_*). Error handling exists but lacks recovery guidance. The 'gmail_send_and_watch' tool violates single-responsibility principle by combining send + watch creation, though this is intentional for race-safety. No secrets exposed in parameters (good). Annotations present for read-only and idempotent hints.

• Document output schemas for all tools. E.g., gmail_send returns {id, threadId, ...}; gmail_list_watches returns {watches: [{id, objective, ...}], total}. Include this in tool descriptions or a separate schema reference.
• Add actionable constraints to parameter descriptions. E.g., 'objective: A brief description of the watch purpose (1-200 chars, e.g., "Monitor responses from finance team")'. 'permissions: Array of permission strings (e.g., ["read", "write"]).'
• Enhance error messages with recovery guidance. E.g., throw new Error('gmailThreadId is required for matchMode=thread. Use gmail_list_watches to find thread IDs, or switch to matchMode=correspondent with email addresses.').
• Split gmail_send_and_watch into separate tools (gmail_send + gmail_watch) for composability, or document the race-safety guarantee and when this combined tool is necessary vs. calling separately.
• Clarify _hermesOrigin: if it is server-injected, remove it from the schema and inject it in the handler. If agents can optionally provide it, document its structure and use case explicitly.