This server has solid naming conventions and reasonable descriptions, but suffers from incomplete schema definitions and missing output schema documentation. All 6 tools follow clear verb_noun naming (search_, get_, list_). Descriptions are present and contextual (avg ~150 chars), falling within the production baseline of 194 chars. However, input schemas use Zod validation internally but are not fully exposed in the MCP registration call, only type hints and descriptions are visible in the code. No explicit output schemas are documented for any tool, violating the critical pattern requirement that LLMs understand what fields to expect. Error handling is minimal; tools return generic text responses without guidance on recovery actions. The server reads from a Supabase backend (stateless, read-only operations), which is good for idempotency, but there is no parameter validation guidance in descriptions (e.g., UUID format for IDs, enum constraints for categories).

• Add explicit JSON Schema definitions to all tool registrations. Instead of relying on Zod validators (which are not visible to the MCP client), pass a structured inputSchema object with type, description, required array, and properties. Example: { type: 'object', properties: { id: { type: 'string', description: 'The rejection reason UUID (v4 format)' } }, required: ['id'] }.
• Document output schemas for each tool. Create a TypeScript interface or JSON Schema for each tool's return structure and add it to the tool registration. E.g., for get_rejection_reason: { type: 'object', properties: { id: string, title: string, apple_message: string, affected_categories: string[], guideline_number: string, tags: string[] } }.
• Add formal enum constraints for parameters with known valid values. Replace app_category free-form string with an enum: ['Games', 'Health', 'Finance', 'Productivity', ...]. This can be enforced via JSON Schema enum field.
• Add parameter validation guidance in descriptions. Example: 'The rejection reason UUID (must be a valid v4 UUID format, e.g. 550e8400-e29b-41d4-a716-446655440000)'. Include examples of VALID formats, not just case names.
• Implement actionable error messages. When a Supabase query returns 0 results, return: { content: [{ type: 'text', text: 'No rejection reasons match "[query]". Try: (1) Search with a shorter query, (2) Use search_rejections to find known rejection types, or (3) Call list_common_rejections to see the most frequent issues.' }] }.
• Add error classification to tool implementations. Catch and classify errors as retryable (network timeout, rate limit) vs user-fixable (invalid UUID, no results) vs fatal (auth failure). Return error type in response so LLM knows whether to retry, ask user, or escalate.