Connect Google Workspace to ChatGPT: Manage Directory and Groups via MCP

If you need to connect Google Workspace to ChatGPT to automate IT helpdesk workflows, orchestrate employee onboarding, or audit group access, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's JSON-RPC tool calls and the Google Workspace Admin SDK.

You can either spend weeks building, hosting, and maintaining this custom integration infrastructure yourself, or use a managed platform like Truto to dynamically generate a secure, authenticated MCP server URL based on real-time API schemas.

If your team uses Claude, check out our guide on connecting Google Workspace to Claude or explore our broader architectural overview on connecting Google Workspace to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise directory is a high-stakes engineering challenge. You have to handle complex nested payloads, map diverse directory endpoints to strict MCP tool definitions, and manage the constant churn of OAuth tokens. Every time Google updates a schema or you need to support a new entity type, custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Google Workspace, connect it natively to ChatGPT, and execute complex IT administration workflows using natural language.

Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::

The Engineering Reality of the Google Workspace API

A custom MCP server is essentially a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against Google's enterprise APIs is exceptionally painful.

If you decide to build a custom MCP server for Google Workspace, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with Google's Admin SDK:

Fragmented API Surfaces and Scopes

Google Workspace is not a single API. It is a sprawling collection of disparate services. Managing users requires the Directory API. Auditing logins requires the Reports API. Assigning product seats requires the Enterprise License Manager API. Each of these APIs requires highly specific, granular OAuth scopes (e.g., https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.group). If you build a custom MCP server, you must maintain a monolithic OAuth app that requests this massive list of scopes, which often triggers severe security review pushback from enterprise IT teams.

The userKey Ambiguity

Many Google Workspace endpoints accept a userKey parameter to identify a user. This can be the user's primary email address, an alias, or their immutable unique ID. If an LLM passes an email address and that user's primary email was recently changed by an administrator, the API call will fail with a 404. Your custom MCP server must include logic to consistently resolve string identifiers to immutable IDs before executing destructive actions, or you risk the LLM hallucinating operations on the wrong accounts.

Field Masks and Nested Arrays

Google's APIs default to returning massive payloads unless fields query parameters are strictly defined. Furthermore, basic concepts are heavily nested. A user's email is not a flat email: string field; it is nested inside an array of objects: emails: [{address: "user@domain.com", primary: true}]. Standard JSON-RPC tool definitions struggle to convey this nesting cleanly to an LLM, leading to malformed request bodies when the model attempts to create or update a user.

Generating a Google Workspace MCP Server

Truto solves these schema and routing problems dynamically. Instead of hand-coding tool definitions for Google Workspace, Truto derives them from the integration's defined resources and documentation schemas.

Each MCP server is scoped to a single integrated account - meaning a connected instance of Google Workspace for a specific tenant. The generated server URL contains a cryptographic token that encodes the account, the allowed tools, and the expiration time.

You can create this MCP server in two ways: via the Truto UI or programmatically via the API.

Method 1: Creating the MCP Server via the Truto UI

For internal IT teams or quick prototyping, the UI is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Click on your active Google Workspace connection.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration. You can restrict the server to specific tags (e.g., directory, groups) or specific methods (e.g., read only).
6. Click Save and copy the generated MCP server URL (it will look like https://api.truto.one/mcp/a1b2c3d...).

Method 2: Creating the MCP Server via the API

For production workflows where you are spinning up agents dynamically, use the API. This single POST call validates that the integration has tools available, generates a secure token, stores it at the edge, and returns a ready-to-use URL.

Endpoint: POST https://api.truto.one/integrated-account/:integrated_account_id/mcp

curl -X POST https://api.truto.one/integrated-account/$INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Google Workspace IT Agent",
    "config": {
      "methods": ["read", "write"],
      "tags": ["users", "groups"]
    }
  }'

Response:

{
  "id": "mcp_12345abcde",
  "name": "Google Workspace IT Agent",
  "config": {
    "methods": ["read", "write"],
    "tags": ["users", "groups"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

That url is the only thing your client needs to connect. Truto handles the OAuth token refresh and schema resolution in the background.

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP URL, you need to expose it to your LLM environment. You can do this visually in the ChatGPT interface or via a configuration file for programmatic agents.

Method A: Via the ChatGPT UI

If you are using ChatGPT Pro, Plus, Business, Enterprise, or Education, you can add the server directly.

1. In ChatGPT, go to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, click to add a new server.
4. Name: Google Workspace IT Admin
5. Server URL: Paste the https://api.truto.one/mcp/... URL you generated earlier.
6. Click Save.

ChatGPT will immediately ping the endpoint, execute an initialize handshake, and call tools/list to load the Google Workspace operations into its context.

Method B: Via Manual Config File

If you are running a custom agent framework, a local desktop client, or a custom ChatGPT integration wrapper, you will use an MCP configuration file. Because the Truto endpoint is a remote HTTP JSON-RPC 2.0 server, you typically use an SSE (Server-Sent Events) transport wrapper to proxy local standard I/O to the remote URL.

Create an mcp.json file:

{
  "mcpServers": {
    "google-workspace-admin": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}

When your agent boots, it will execute the wrapper command and establish a persistent connection to the Truto MCP router.

Hero Tools for Directory and Group Management

Truto automatically generates descriptive, snake_case tool names by reading the underlying integration documentation. Below are the highest-leverage tools for automating Google Workspace directory administration.

list_all_admin_users

Lists all Google Workspace users in the directory. Truto automatically injects limit and next_cursor properties into the query schema, explicitly instructing the LLM to pass cursor values back unchanged to handle Google's pagination tokens seamlessly.

"Pull the list of all active users in our Google Workspace directory. Give me the first 50, and if there are more, use the next_cursor to fetch the rest."

get_single_admin_user_by_id

Retrieves a single Google Workspace user by their unique id or userKey. This is the critical read step before an agent attempts to update an account, ensuring it has the full context of the nested email and organization arrays.

"Get the full user profile for jdoe@example.com so we can check their current organizational unit and secondary email addresses."

create_a_admin_user

Creates a new Google Workspace user in the directory. The LLM must supply the required primaryEmail, name (nested givenName and familyName), and password.

"Create a new user account for Sarah Jenkins. Her primary email should be sjenkins@example.com. Generate a secure temporary password and set the changePasswordAtNextLogin flag to true."

update_a_admin_user_by_id

Updates an existing user. This is heavily used for suspending accounts during offboarding or updating titles and department fields during internal transfers.

"Suspend the account for msmith@example.com immediately, and update their profile title to 'Offboarded'."

list_all_admin_groups

Lists the groups available in the Google Directory. This is vital for discovering the id of a group before attempting to manage its members.

"List all the Google groups in our organization. I need to find the exact group ID for the 'Engineering All-Hands' mailing list."

create_a_admin_group_member

Adds a user to a specific Google group. The LLM requires the group_id and the user's email or ID to execute the addition.

"Take Sarah Jenkins (sjenkins@example.com) and add her as a member to the Engineering All-Hands group. Assign her the standard 'MEMBER' role."

To see the complete tool inventory, including tools for querying usage reports, managing OAuth tokens, and assigning software licenses, view the full schema on the Google Workspace integration page.

Workflows in Action

When you give an LLM access to these tools, it acts as an autonomous IT administrator. Below are real-world orchestration sequences.

Scenario 1: Zero-Touch Employee Onboarding

Instead of an IT tech manually clicking through the Google Admin console, an HR trigger or manager request prompts the agent to handle the entire provisioning lifecycle.

"We have a new hire starting Monday: Alex Chen. Create a new Google Workspace user for him (achen@example.com). Generate a temporary password. Once created, find the 'Product Team' and 'All Company' groups and add him to both."

Agent Execution Sequence:

1. Calls create_a_admin_user passing the required name, email, and password payload.
2. Calls list_all_admin_groups to retrieve the directory and filter for the IDs matching "Product Team" and "All Company".
3. Calls create_a_admin_group_member using the Product Team group ID and Alex's new email.
4. Calls create_a_admin_group_member using the All Company group ID and Alex's new email.

The user receives a summary confirming the account was created, the temporary password, and a list of groups the user was successfully added to.

Scenario 2: Emergency Offboarding and Audit

When an employee departs, their access must be revoked instantly, and their footprint must be audited.

"We need to offboard David Lee (dlee@example.com) immediately. Suspend his user account, then list all groups he is currently a member of, and remove him from every single one."

sequenceDiagram
    participant User as IT Manager
    participant Agent as ChatGPT / Agent
    participant Truto as Truto MCP Server
    participant GW as Upstream API (Google)

    User->>Agent: "Offboard dlee@example.com..."
    Agent->>Truto: call get_single_admin_user_by_id<br>(id: dlee@example.com)
    Truto->>GW: GET /admin/directory/v1/users/dlee@example.com
    GW-->>Truto: Return User Object (ID: 12345)
    Truto-->>Agent: Return User Object
    
    Agent->>Truto: call update_a_admin_user_by_id<br>(id: 12345, suspended: true)
    Truto->>GW: PUT /admin/directory/v1/users/12345
    GW-->>Truto: 200 OK
    Truto-->>Agent: Success

    Agent->>Truto: call list_all_admin_groups
    Truto->>GW: GET /admin/directory/v1/groups
    GW-->>Truto: Return Group List
    Truto-->>Agent: Return Group List

    Note over Agent,GW: Agent iterates through groups<br>checking membership and removing user

Agent Execution Sequence:

1. Calls get_single_admin_user_by_id to verify the account exists and retrieve the exact immutable ID.
2. Calls update_a_admin_user_by_id passing suspended: true to lock the account.
3. Calls list_all_admin_groups to pull the directory map.
4. Iterates through the groups. For each group where David is found, it calls delete_a_admin_group_member_by_id.

The IT manager receives a complete audit log in the chat window, detailing the exact timestamp of suspension and the specific groups David was removed from.

Security and Access Control

Exposing an enterprise identity provider to an LLM requires strict guardrails. Truto's MCP servers provide four core security controls configured at the token level:

• Method filtering: Restrict the server to specific operation types. Setting methods: ["read"] ensures the LLM can only query users and groups, physically preventing it from creating, updating, or deleting records regardless of the prompt.
• Tag filtering: Group tools by functional area. By setting tags: ["directory"], you can expose user management tools while hiding potentially dangerous tools related to billing or domains.
• Require API token auth: By setting require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The connecting client must also supply a valid Truto API token in the headers, adding a second layer of authentication.
• Automatic expiration: You can attach an ISO datetime to expires_at. Once that time passes, the edge token is purged, immediately revoking the LLM's access. This is ideal for granting temporary provisioning rights to contractor agents.

Handling Rate Limits in Production

The Google Workspace API applies strict quotas, particularly on Directory operations (e.g., maximum queries per 100 seconds per user).

When connecting AI agents, it is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When Google returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the caller.

To help your agents handle this gracefully, Truto normalizes upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The MCP client or agent framework you use is responsible for reading these headers, pausing execution, and applying exponential backoff before retrying the tool call. Do not assume the integration layer will absorb these spikes for you.

Stop wrangling custom Google Workspace OAuth flows and writing translation layers for nested JSON arrays. Truto's dynamically generated MCP tools give your AI agents safe, structured access to your enterprise directory in minutes.