Google Workspace MCP OAuth deadline: what developers must check

Google Workspace MCP integrations face an OAuth client requirement from November 11, 2026. Developers should check the deployed client before the next day’s migration cutoff.

The October 12 announcement covers the Chat, Gmail, Calendar, Docs, Drive, Sheets and Slides Model Context Protocol servers. Google says ordinary non-agent applications using only Workspace REST APIs are unaffected.

Two dates with different consequences

• November 11: Google says Workspace MCP servers begin rejecting requests made with OAuth clients that are not designated for AI agents.
• November 12: Clients still not designated remain non-agentic. Continuing with MCP then requires creating a new agentic OAuth client and updating the application to use it.

Google supplies no exact enforcement time or time zone. These are published requirements, not a verified outage report. November 12 should not be assumed to provide an extra grace day.

First identify how the integration authenticates

The current Gmail MCP troubleshooting guide makes an important distinction that the short deadline notice does not spell out. The checkbox requirement applies to user-delegated OAuth clients. An existing dedicated agent client can be updated if the setting is available. If it also serves ordinary application features, Google directs developers to keep that client for those features and create a separate one for the agent.

Service accounts using domain-wide delegation follow a different path. They are not managed on the Auth Platform Clients screen, and Google says their MCP requests are not rejected for lacking this checkbox. Administrator-controlled delegation governs access instead. Sensitive tool calls still trigger human confirmation prompts when the service account impersonates a user.

For a team using a vendor-managed connector, the useful first question is who owns the OAuth client. A user reconnecting an account cannot substitute for a change that the integration provider must make. Ask the provider which authentication path its connector uses before treating every failed connection as the same issue.

The agent setting does not grant new permissions

Google places the option in Google Auth Platform > Clients, under Use this client for an AI-powered agent. Its OAuth client guidance describes this as a declaration that the client represents an agent acting for a user. The label does not add scopes or privileges. Consent and OAuth application verification requirements still apply.

Separating agent and standard clients also gives administrators a way to distinguish those workflows when applying access policies. A successful change to the label should therefore be treated as one prerequisite, not evidence that an agent has permission to read every file or perform every action.

Apps Script needs a closer look

A script can be attached to a standard Google Cloud project and still use the default OAuth client managed by Apps Script. The Docs MCP setup guide says that default client cannot be marked with the agent setting.

Google’s documented route is to create a separate OAuth client with the agent setting enabled, authorize users through the OAuth2 for Apps Script library, and send the access token returned by that library to the MCP server. The default token obtained from ScriptApp.getOAuthToken is not the token for that route. Apps Script projects that do not call Workspace MCP servers are unaffected.

That distinction matters when diagnosing a script that appears to have the right Cloud project but still fails. Record where its token actually comes from. Changing an unrelated consent screen or repeatedly signing in does not establish that the request is using the intended client.

A practical migration checklist

Start with an inventory of the deployed integration, rather than a list of clients that happen to exist in the console. For each affected workflow, record the owner, project, OAuth client ID, authentication method, MCP endpoint and the non-agent features that share that client. Keep secrets out of the inventory and support tickets.

• Match the deployed client. Compare the client ID in the application’s active configuration with the one being reviewed. Include scheduled jobs and separate development and production deployments.
• Choose the documented route. Update an eligible dedicated agent client, or plan a new one when the old client cannot be changed or is shared with ordinary features. Assign an owner for the application configuration change as well as the console work.
• Check the host configuration. Confirm the endpoint, redirect URI and authentication flow against the guide for the specific MCP host. Do not copy settings for a different host just because both use OAuth.
• Verify with a small read. After the authorized migration, reconnect as required by the host and try a harmless operation on a test resource the account already has permission to access. Check the actual tool result, not just a successful sign-in screen.
• Keep the ordinary workflow working. Where clients were separated, test the human-facing feature independently. Record the result and investigate failures before making further changes.

Google’s Workspace MCP configuration guide lists separate services and endpoints for individual products and still labels the offering Developer Preview. Its setup includes both the product API and the relevant MCP service. The consent scope list also varies by product: Gmail includes gmail.readonly and gmail.compose, while Docs lists Drive and document scopes. The agent declaration is a client property, not a new universal OAuth scope.

Use the current product guide to review only the access the integration actually needs. Adding broader permissions is a poor diagnostic shortcut for a client identity problem.

Keep security and product access separate

The Workspace MCP security guide separately requires screening prompts and responses for malicious content or prompt injection. It describes Google’s Model Armor or a documented alternative. It also warns that Model Armor payload logging can expose sensitive information and that routing behavior can matter for data residency. Enabling a client label does not settle those decisions.

An assistant’s broader access to Google files can involve several distinct products. ByteForward’s guide to Claude’s Google Workspace editing routes explains the difference between its in-document sidebar and separate connectors. Check the implementation in use before assuming that a Workspace MCP notice applies to every AI feature with a Google logo.

The immediate priority is to establish which client sends the MCP request and whether it has a viable migration path. That is more useful than a blanket reconnect instruction, especially when a shared client, Apps Script token or service account changes the answer.

Featured image: AI-generated editorial illustration, not a Google interface. Google, Google Workspace and the Google logo are trademarks of Google LLC. ByteForward is independent and is not endorsed by or affiliated with Google.