The server defines 5 tools with complete input schemas and descriptions visible in src/index.ts. However, there are several quality issues that prevent a higher score: (1) Output schemas are completely undocumented, no tool declares what it returns, forcing LLMs to infer structure from tool execution. (2) Parameter descriptions contain anti-patterns like example values ('2024-03-20T10:00:00+08:00') that LLMs tend to reuse literally. (3) Two tools (list_events, create_event) have timezone-specific requirements buried in descriptions rather than enforced via constraints. (4) The search_user_in_supabase tool has a vague description ('Search for a user') that doesn't explain what fields are searchable or what the response contains. (5) No error handling guidance, tools describe success paths but not failure recovery. (6) The add_attendees tool has complex conditional parameter logic (type enum determines which ID field applies) that is documented but not enforced by schema. Average tool quality is fair but not production-ready.

• Document return types for all tools. For list_events, specify: 'Returns object with fields: events (array of {id, summary, start_time, end_time, attendees}), total_count (number).' For create_event: 'Returns {event_id, created_at}.' For search_user_in_supabase: 'Returns array of {user_id, user_name, calendar_id, email}.' This enables LLMs to chain tools correctly.
• Remove example datetime values from descriptions. Instead, add a format constraint to the schema: '"format": "date-time"' and update the description to: 'Event start time in ISO 8601 format with UTC+8 timezone offset (e.g., +08:00). Example: 2024-03-20T10:00:00+08:00', but move the example to a separate 'example' field in the schema, not the description prose.
• Add error recovery guidance to each tool description. Examples: send_message_to_user: 'If the message fails, check that the user_id is valid. Call search_user_in_supabase if you only have the user name.' list_events: 'If no events are returned, the calendar_id may be invalid, try the user primary calendar.'
• Enforce conditional parameter logic in add_attendees schema using oneOf or discriminator patterns. For each attendee object, define: 'if type is "user", user_id is required; if type is "chat", chat_id is required; if type is "resource", resource_id is required; if type is "third_party", third_party_email is required.' This prevents invalid combinations at schema validation time.
• Enhance search_user_in_supabase description: 'Search the Supabase user database by partial name (case-insensitive match against user_name field). Returns matching users with their user_id and calendar_id for use with list_events or add_attendees. Call this when you have a user name but need their system ID or calendar ID.'