Server has 5 tools with complete input schemas and basic descriptions. All tools follow verb_noun naming (create_, move_, rename_, get_, list_). However, descriptions are generic and lack LLM-optimization guidance. Parameter descriptions are minimal (e.g., 'ID of the file or folder' repeated across tools). No output schemas documented. Error handling returns raw HttpError strings without recovery guidance. Missing tool annotations (destructiveHint for WRITE operations). No pagination guidance for list_drive_folder_contents despite accepting page_size. Schemas are present but descriptions average ~60 chars, below the 50-200 char LLM-optimized baseline.

• Add explicit output schemas to all tools. Document the response structure: { success: boolean, folder_id?: string, error?: string, ... }. This enables LLMs to extract IDs for chaining calls.
• Add destructiveHint: true to create_drive_folder, move_drive_file, rename_drive_file. Add readOnlyHint: true to get_drive_file_info and list_drive_folder_contents. Annotate idempotentHint: true if applicable (e.g., rename to same name is idempotent).
• Enhance error responses with recovery guidance. E.g., 'File not found (404). Verify file_id with list_drive_folder_contents() or get_drive_file_info().' Categorize errors: retryable (network timeout), user-fixable (invalid ID), fatal (permission denied).
• Expand parameter descriptions to 50-150 chars each. For file_id, add: 'Google Drive file or folder ID (alphanumeric string). Obtain via list_drive_folder_contents() or get_drive_file_info().' For folder_id, clarify: 'Folder ID or 'root' for the root directory.'
• Implement pagination for list_drive_folder_contents. Add nextPageToken to response and accept pageToken parameter. Document: 'Returns up to page_size items. Use nextPageToken to fetch additional results.' Cap default page_size at 100 and enforce max 1000.