Your agent needs to act inside Google Workspace: triage a mailbox, book the meeting, provision the new hire, answer the auditor. As of May 2026, Google ships Google Workspace MCP servers alongside the Google Workspace APIs your team already knows. They are not interchangeable. They differ on what the agent can do, whose identity it acts as, and what breaks in production when a token or a grant goes stale. For multi-tenant B2B agents, the identity question dominates. Here is the decision framework.
Same vendor, same data, two different objects built for different callers.
Google offers remote MCP servers for Google Workspace, one per product: Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat, and People. They use Streamable HTTP and are in public developer preview. The rollout started May 1, 2026, and Google's setup guide still lists Developer Preview Program membership as a prerequisite.
You enable each product API plus its matching MCP service in a Google Cloud project, configure an OAuth consent screen, and create your own OAuth client. Google's remote MCP servers support neither Dynamic Client Registration (DCR) nor Client ID Metadata Documents (CIMD), so every MCP client needs that pre-registered client ID and secret.
The Google Workspace APIs are per-product REST APIs for Gmail, Drive, Calendar, Chat, Docs, Sheets, and more, plus the admin surface: Admin SDK Directory and Reports, Alert Center, Vault, and Groups Settings. The Workspace Events API adds push subscriptions for Chat, Drive, and Meet.
Auth has three options. OAuth 2.0 client IDs access user data with consent. Service accounts with domain-wide delegation (DWD) access user data without consent once a super admin authorizes them. API keys only reach public data. Schemas, pagination, retries, and quotas are yours to handle.
Four dimensions decide this: capability coverage, auth model, operational surface, and fit by agent type.
The MCP servers cover the user-present read-and-draft loop well. The APIs, and connectors built on them, cover everything that changes state at scale. The last column shows the Scalekit Google Workspace (DWD) connector, which is built on the APIs.
The Gmail MCP server creates drafts but cannot send them; delivering mail without a human clicking Send requires the API. The Drive MCP server reads a file's permissions but has no tool to share or change them. Nothing on the MCP side reaches the Admin SDK, Reports, Alert Center, Vault, Tasks, Keep, Forms, or Meet.
Event-driven agents also land on the API. There is no MCP equivalent of Gmail push notifications or Workspace Events API subscriptions, so an agent that reacts to a new email or a Drive change has to subscribe through the API. Treat these gaps as the current contract, not a roadmap.
The MCP path runs on per-user OAuth 2.0. Each user completes a browser consent flow against your OAuth client, and the agent acts with that user's permissions within the granted scopes. Google's Workspace MCP setup guide documents only this flow. It does not document service account or DWD authentication for these servers, so treat headless DWD over MCP as unsupported.
Google's OAuth documentation also warns against deploying user credentials for server-to-server jobs, because admin session policies can expire them with no way to reauthenticate. A scheduled agent with nobody present is exactly that case.
The APIs give you a choice. Per-user OAuth, the Authorization Code flow from RFC 6749, mirrors the MCP path and inherits Google's refresh token rules. Tokens stop working after six months unused, after a password change when Gmail scopes are granted, or when a user's 101st token for your client invalidates the oldest. External apps in Testing status get refresh tokens that expire in 7 days.
DWD is two-legged. Your service account signs a JWT whose sub claim names the user, exchanges it through the JWT bearer grant (RFC 7523), and receives an access token valid for 3,600 seconds. There is no refresh token and no consent screen; a super admin authorizes the service account's client ID and scopes once per domain.
DWD is the only path that runs headless across a customer's whole domain without asking every employee to consent. That is why admin, compliance, and provisioning agents use it. The tradeoff is blast radius. A DWD grant lets the service account impersonate any user in the authorizing domain within the granted scopes, and one service account can hold grants from many customer domains.
Neither path removes the structural problem: per-user credential isolation in a multi-tenant agent. OAuth gives you a token per user; DWD gives you a subject per user. Neither stores, rotates, or revokes anything for you. For a deeper look at how tool calling auth changes when you move from single-tenant to multi-tenant, the tradeoffs map directly to this choice.
Google hosts the servers, maintains the tool schemas, and updates them as the preview evolves. You own the OAuth client, the consent screen, per-user token storage and refresh, and revocation handling. Google's MCP security guide also states that you must screen prompts and responses for prompt injection, using Model Armor or a documented alternative of your own.
Preview status cuts both ways. Tool names and shapes can change without a versioned contract, which matters when a deterministic pipeline depends on them.
Everything: endpoint selection, request construction, pagination, retries, and error mapping across a dozen APIs with different conventions. With DWD you also own the service account key. Google Cloud organizations created on or after May 3, 2024 block service account key creation by default, so a key-based DWD setup needs an explicit org policy exception. DWD grants can take up to 24 hours to propagate, which surfaces as unauthorized_client errors during customer onboarding.
Google introduced a tiering model for Workspace agent tools that covers the APIs and MCP alike. Projects created from May 1, 2026 get new standard quotas for the Gmail, Calendar, and Drive APIs. Google has also said that later in 2026, with 90 days of notice, quota increases will require billing and usage above standard daily thresholds will be charged. High-volume agents should budget for this on either path.
Pick either path and you still end up with one Workspace credential per user, per tenant, that has to live somewhere safe.
Fifty customers with forty users each is 2,000 refresh tokens to encrypt, isolate by tenant, refresh, and revoke. Each one can die silently: a password change, six months of inactivity, or an admin restricting a scope and returning admin_policy_enforced. Your agent finds out on the next tool call unless something is watching token health. This is the credential ownership problem that scales badly across agent tool-calling patterns.
DWD collapses N tokens into one private key, which moves the risk rather than removing it. Whoever holds that JSON key can mint tokens for any user in every domain that authorized it. And because every call runs as the impersonated user, Google records the action against that user. Your system needs its own record of which agent run, for which tenant, triggered it.
Scalekit's Google Workspace connector holds the service account key in its vault, mints short-lived DWD tokens through the JWT bearer grant, and binds each connected account to exactly one Workspace subject, so the MCP vs API decision does not change your auth infrastructure.
The Google Workspace (DWD) connector exposes 100 tools across Gmail, Drive, Docs, Sheets, Slides, Forms, Calendar, Chat, Meet, Tasks, Keep, Contacts, Admin Directory, Reports, Alert Center, and Vault. The examples below use Python and LangChain, first with native tools and then over MCP. The snippets build on each other in one module.
In the Scalekit dashboard, go to AgentKit > Connections > Create Connection, choose Google Workspace (DWD), and add each Google scope your agent needs as a full scope URI. Create a service account in Google Cloud, download its JSON key, and paste it into the connection. A super admin of each customer domain then opens Admin console > Security > Access and data control > API controls > Manage Domain Wide Delegation and authorizes the service account's numeric Client ID with the same scopes. The two scope lists must match exactly.
Copy the connection name exactly as it appears in AgentKit > Connections. A mismatched connection_name is the most common integration error.
A connected account binds a user in your product to the Workspace user the agent impersonates. You pass the Workspace email as subject, and Scalekit resolves it on every call. DWD grants the service account the whole domain; the connected account narrows each run to one person. Use an admin account as subject only for agents that call Admin SDK tools.
Before the loop, load the tool surface for this connected account, not the connector catalog. At roughly 200 tokens per tool, all 100 tools cost about 20,000 tokens of context before the agent does any work, and selection accuracy drops with every irrelevant tool. get_tools accepts tool_names, so this assistant sees three.
Scalekit returns native LangChain StructuredTool objects, so there is no schema conversion and no token handling in agent code.
Not every Workspace job needs a model. For fixed-sequence work, call execute_tool and keep the execution_id; it joins your pipeline logs to Scalekit's tool call log. Catch the tool exception subclasses before the base class so a missing scope and a revoked grant get different handling.
For MCP-native agents, a Virtual MCP server gives one agent role a scoped endpoint with no MCP server to host. Create it once per role, not per user. This IT onboarding role combines four Workspace tools with one Slack tool, which is where Virtual MCP pays off: a multi-tool agent gets one endpoint and one allow-list.
Before each run, confirm every connection in the config is active for this user, then mint a short-lived session token. The DWD account needs no user action; the Slack account returns an authorization link if the user has not connected it. Session tokens default to about an hour and cannot be extended, so call create_session_token again to remint. The Virtual MCP setup guide covers config management.
Google's tooling stops at the protocol and the grant. Production Workspace agents need observability, scoping, and tenant isolation on top of it.
AgentKit records every tool call with timestamp, connection, tool name, user identifier, and latency. Each record expands to the connection ID, connected account ID, duration, source, and, for failures, the error code and message. Errors are split between connector errors, where Google rejected the call, and API errors, where Scalekit rejected it before it left. With DWD, Google attributes every action to the impersonated user, so this per-call identifier is what ties a sent email back to the agent run and tenant behind it. More in Agent Tool Observability.
The overview dashboard tracks total calls, success rate, and error counts per connector across windows from one hour to 30 days. A Workspace scope that an admin quietly removed shows up as a rising error rate on one connector, not as a support ticket a week later. Pair it with the connected_account.status_updated and connected_account.token_refresh_failed webhooks to pause an agent before its next call fails.
One Virtual MCP server definition serves every user of an agent role, and each run gets a session token bound to one user's connected accounts. On top of DWD, that gives you least privilege at two layers. The Admin console grant sets the ceiling of scopes; the Virtual MCP allow-list sets which of the 100 tools a role can see. A summarizer role never sees googledwd_make_admin_user, even though the same connection supports it. Read what a Virtual MCP server is for the full model.
The simplest setup is one DWD connection whose service account each customer's super admin authorizes; one Virtual MCP server per role then serves every tenant. If one key reaching many customer domains is more blast radius than your security review allows, create a separate DWD connection and service account per customer and route by connection_name. That costs one Virtual MCP config per role per tenant, but a leaked key stays contained to one customer. See single vs multi-tenant tool calling.
Some customers will not grant DWD, and some agents should only ever see what a user explicitly consented to. For those, Scalekit's per-product OAuth connectors for Gmail, Google Drive, Google Calendar, and Google Chat run the consent flow and store and refresh each user's tokens. Compare the tradeoffs in agent tool calling auth production problems, patterns, and anti-patterns.
The new hire provisioning agent runs its Workspace steps through the DWD connector. The email to calendar agent, meeting prep agent, and PTO leave request agent show mail and calendar patterns you can port. The free AgentKit tier includes 5,000 tool calls a month and unlimited connected accounts.
If your agent is interactive, the user is present, and the work is read, search, and draft, Google's Workspace MCP servers are the fastest start, with the caveat that you are building on a developer preview. If your agent runs headless, sends mail, shares files, touches the admin surface, or reacts to events, build on the APIs, and use DWD when a customer admin will authorize it.
Most production Workspace agents need both modes in the same product. The credential problem is identical across them, and that is the layer that needs production-grade infrastructure. For teams thinking through secure token management for AI agents at scale, the patterns apply directly here.
Building a Google Workspace agent? Join the Scalekit Slack community to compare notes with other agent builders, or talk to us for immediate help with DWD setup and multi-tenant design. Start with the Google Workspace (DWD) connector docs, browse the Scalekit Google Workspace connector, or explore all connectors.
