Before Google Workspace MCP locks the client type: an OAuth migration decision tree

Google has attached two dates to the OAuth client type used with its Workspace MCP servers. Beginning November 11, 2026, those servers will reject OAuth clients that are not marked for an AI-powered agent. After November 12, an existing non-agentic client cannot be converted for MCP use. Google also says mixed agent and non-agent applications should use separate OAuth clients. The servers remain in developer preview, so these statements describe Google’s announced compatibility boundary rather than verified production behavior. Google Workspace developer release notes

The narrow operating question is not whether an organization uses Google Workspace. It is whether a particular OAuth client sends traffic to a Workspace MCP server. A secondary report identifies REST-only integrations as exempt from this change and recommends inventorying clients used with Gmail, Drive, Calendar, and other Workspace MCP servers. Harel Asaf’s report

Start at the traffic path

Use the following decision tree as an SGL migration framework derived from the dated rules above:

1. Does the OAuth client call a Google Workspace MCP server?

   • No; it uses Workspace REST APIs only. Based on the supplied secondary report, this enforcement does not apply to that path. Record the exemption and leave the client outside this migration.
   • Yes. Continue to the client-purpose check.
   • Unknown. Trace the caller, endpoint, OAuth client ID, and environment before assigning a migration action.

2. Is the client marked for an AI-powered agent?

   • Yes. It appears to match the announced client-type condition. Continue to credential and cutover verification rather than assuming the label alone proves compatibility.
   • No. Plan a replacement or permitted reclassification before the dated boundary.

3. Does the same OAuth client serve both MCP agent traffic and conventional application traffic?

   • Yes. Split the traffic across separate OAuth clients. That branch follows Google’s explicit guidance for mixed applications.
   • No. Keep the replacement scoped to the MCP caller.

This first pass prevents two avoidable errors: migrating every Workspace integration because it uses OAuth, or overlooking a shared client because only part of its traffic reaches MCP.

Treat mixed use as an identity split

A mixed-use client is more than a mislabeled configuration entry. Splitting it changes which deployed component presents which client identity. The practical work may include creating the agent-designated client, assigning its redirect configuration, distributing new credentials, changing the MCP caller, and preserving the conventional application’s existing path.

Those steps are an implementation prescription, not behavior established by the release note. The exact rollout depends on how each organization stores credentials and maps OAuth clients to environments.

A useful inventory row contains:

• OAuth client ID and current client type
• owning service and team
• Workspace connection path: MCP, REST, or both
• environments using the client
• credential and redirect-URI locations
• replacement client ID, if one is created
• cutover owner and rollback condition

Keep one row per deployed client rather than one row per application name. A single application label can conceal separate development, staging, and production identities—or a shared identity that creates the mixed-use branch.

Choose the migration action before the lock

For an MCP caller using a non-agentic client, there are two conceptual routes: convert an eligible existing client before the classification lock, or provision a correctly classified replacement. The supplied evidence does not describe conversion mechanics or eligibility details, so teams should confirm those in the relevant Google configuration surface before choosing that route.

The calendar makes delay consequential. Rejection begins November 11, while the supplied release-note excerpt says an existing non-agentic client cannot be converted for MCP use after November 12. That wording does not establish a safe grace period between the dates. An operationally conservative interpretation is to complete the cutover before November 11 and treat November 12 as a separate lock on later conversion.

For mixed traffic, a replacement agent client is the clearer branch because Google explicitly directs mixed agent and non-agent applications to separate clients. The conventional application can retain its own client, while the MCP caller receives the agent-designated identity.

Roll credentials without confusing configuration with evidence

Creating or relabeling a client is a configuration event. It does not demonstrate that every deployed MCP caller is using it.

A bounded cutover can proceed in four stages:

• issue or select the correctly classified client for the MCP path;
• distribute its credentials through the organization’s normal secret-management path;
• move one environment or caller cohort at a time;
• verify which client ID appears on the actual authorization path, then retire the obsolete credential only after its expected users have moved.

This sequencing is SGL’s recommended architecture for limiting ambiguity during migration. It is not a procedure documented in the supplied sources, and it may need adjustment for the organization’s OAuth flow and deployment system.

Rollback also needs a date-aware definition. Before enforcement, rollback might restore the prior client. Once rejection applies, returning an MCP caller to a non-agentic client would not be a viable recovery path under Google’s announced rule. A safer rollback target would be the last known working deployment that still uses a correctly classified client.

Verify the route, not only the label

Post-cutover verification can answer three separate questions:

• Configuration: Is the intended OAuth client classified for an AI-powered agent?
• Deployment: Is the MCP caller actually configured with that client ID and its current credential?
• Traffic: Does an authorization attempt from each migrated environment travel through the intended client and reach the expected Workspace MCP server?

A successful configuration check answers only the first question. Because the servers are still in developer preview, a successful test also remains evidence about the tested configuration and time—not a guarantee of unchanged future behavior.

Retain the client ID, environment, connection path, test time, result, and observed failure response. If a caller cannot be exercised safely before cutover, record that gap rather than treating the client label as a completed verification.

The resulting migration record has a simple boundary: REST-only callers stay out of scope; MCP callers receive an agent-designated identity; mixed traffic is separated; and deployed credentials are verified before the announced rejection date. The broader lesson for building agent systems is concrete: bind each OAuth identity to its actual traffic path before the enforcement date turns a classification mistake into a failed connection.