Both tools have minimal definitions. gmail_list_labels and mock_whoami lack parameter descriptions, input schemas are empty objects (no type information), and descriptions are generic. No output schemas documented. The server is experimental OAuth infrastructure, not a production tool suite. Tool definitions are inferred from code rather than explicitly registered with full schemas.

• Add explicit input schemas with type definitions. Even if a tool takes no parameters, declare Input: { type: 'object', properties: {}, required: [] } to signal intentional design.
• Expand descriptions to 100 - 200 characters. Example: 'List all labels in the authorized Gmail account. Returns label IDs, names, and types. Call start() first to authorize if state is authorization_required.'
• Document output schema for gmail_list_labels: { labels: [{ id: string, name: string, type?: string }] }. Include pagination guidance if results can exceed 50 items.
• Add parameter descriptions for any future parameters. Use enums for constrained values (e.g., label_type: 'system' | 'user'). Suffix ID params with _id (label_id, not label).
• Implement error classification: distinguish authorization_required (call start()), invalid_input (user-fixable), and service_error (retryable). Return actionable messages, not stack traces.