Business Automation | 2026-11-04 | 6 min read
Google Workspace MCP: Check Your OAuth Client
Google Workspace MCP servers require agentic OAuth clients from November 11. Learn what is affected, how to check, and how to test a replacement.
Direct answer: If your integration calls Google-hosted Workspace MCP servers with an OAuth client, check whether that client is marked for an AI-powered agent. Google says unmarked clients will be rejected starting November 11, 2026. REST-only integrations are not affected by this specific change. Check your connection and the current Google documentation before changing anything.
Written by: Esmail Hanif, AI Visibility Strategist & Founder, Martecks
Who needs to check?
Google Workspace MCP servers let an AI application request actions or information from supported Workspace products through a shared protocol. The OAuth client identifies the application during authorization. These are not the same thing as WebMCP, which exposes website actions to agents inside a browser.
Google says its Workspace MCP servers will reject requests from unmarked OAuth clients starting November 11, 2026. Its release notes say clients still unmarked on November 12 remain non-agentic; after that, an affected integration needs a new agentic client. This article was checked on November 4, 2026.
A connected Gmail or Drive button alone does not establish that the connection uses Google-hosted Workspace MCP or an OAuth client you manage. Ask the application owner or administrator to confirm the actual connection before changing settings.
Which connections are affected?
| Connection | What to do | Why |
|---|---|---|
| Google-hosted Workspace MCP with a managed OAuth client | Check the AI-powered agent setting in Google Auth Platform | Google says unmarked OAuth clients are rejected from November 11 |
| Workspace REST API only | Keep existing non-agent use separate | Google says integrations that only call REST APIs are not affected by this MCP-specific change |
| Third-party or self-hosted MCP server | Ask its operator which backend and OAuth client it uses | Do not assume it is the Google-hosted MCP server or that the same enforcement applies |
| Service account with domain-wide delegation | Review administrator delegation settings | Google says these requests are not rejected for this OAuth-client flag |
| Apps Script calling Workspace MCP | Review Google's Apps Script instructions | The script-managed default client cannot be marked with this setting |
Check your client without exposing credentials
In Google Cloud, an authorized administrator can inspect Google Auth Platform, then Clients, and identify the OAuth client used by the integration. Check whether “Use this client for an AI-powered agent” is selected. Do not paste client secrets, access tokens, or private customer data into a ticket or chat.
If an existing client is used for both agent and non-agent features, Google advises creating a separate agentic client for the agent and keeping the existing one for non-agent features. If the existing setting cannot be changed, create a new client marked for an AI-powered agent and update the integration to use it. Preserve the application's required redirect settings and review permissions with the owner.
Creating a new client can require a new authorization flow and application configuration. Plan the change with the person who manages the connection rather than assuming a checkbox alone updates every connected app.
A small-business example
Imagine a service company has an assistant that reads a shared calendar to prepare appointment summaries. The team discovers the assistant calls Google's Workspace MCP server using an OAuth client it manages. An administrator checks the client and finds that the agent setting is not enabled.
Before changing production, the team documents which application uses the client, its approved access, and who can authorize it. They configure an eligible client in a test environment, reconnect with an authorized test account, and check that the assistant reads only the intended calendar. They keep a rollback plan and review the result before switching the live workflow.
This is a hypothetical example. A different connector may use a REST API or a vendor-managed client, so its owner may need to make the change instead.
Test the connection after the change
Start with a read-only action using a non-sensitive test file or calendar. Confirm the intended user and resource, check the response, and verify that an unrelated resource remains inaccessible. Then test a draft or write action only if the workflow actually needs it and the owner has authorized the test.
If requests are rejected, Google recommends checking the agentic client setting. Its configuration guide also distinguishes Apps Script and service-account cases. A successful sign-in is not proof that every action has the right scope or that a write succeeded.
Permissions matter beyond this deadline. Give the agent only the access its task requires and keep human approval for consequential actions. The agent-harness guide explains where tool access and approval fit into a wider workflow.
Common questions
Does this affect every Google Workspace integration? No. Google specifically exempts applications that only call Workspace REST APIs from this MCP requirement. For a vendor-managed connector, confirm the architecture with that vendor.
Will this change improve AI search visibility? It is an authorization change for Google-hosted Workspace MCP connections, not a Google Search ranking feature.
Does marking a client agentic approve every action? No. OAuth authorization, scopes, application permissions, and the controls around each action still matter.