When a Workspace agent stops connecting, check which OAuth client it uses before changing the integration’s scopes.
Google began rejecting calls to its Workspace Model Context Protocol servers from OAuth clients without the AI-agent designation on November 11. The Workspace developer release notes announced the requirement on October 12 and give November 12 as the cutoff for marking existing clients. Google says an app that missed the cutoff must create a new client designated for an AI-powered agent to call those servers.
The notes list Chat, Gmail, Calendar, Docs, Drive, Sheets, and Slides MCP servers under the Developer Preview Program. Google says an integration that uses only Workspace REST APIs is outside this change. For an application that combines agent features and conventional REST functions, Google recommends a separate OAuth client for the agent.
Verify which client the agent actually uses
Find the OAuth client ID your MCP integration sends when it starts the authorization flow. Compare that value with the client record in Google Auth Platform. A mixed application may have different client IDs for its web app and agent, so reading the configuration of only one component can miss the affected credential.
Test the designated agent client in a development project. Complete its consent flow and run a read operation on a test document that the account can already access. Then run a representative REST operation with the existing client. Record each result before rolling the change out. For a different use of MCP in the Google ecosystem, see our coverage of Workspace connectors in Gemini.
Abdessalam Alaoui
I'm Abdessalam Alaoui, founder of Musthave.AI. I write practical guides to AI models, tools, generative media.
