Skip to content
Truto
Truto Blog
Back
AI & Agents

Connect Google Contacts to ChatGPT: Search and Manage Contact Info

Learn how to connect Google Contacts to chatgpt using Truto. Step-by-step guide to tool calling, API quirks, and autonomous workflows.

Roopendra Talekar Roopendra Talekar · · 10 min read

If you need to connect Google Contacts to ChatGPT to automate directory cleanup, manage team address books, or orchestrate complex CRM syncs, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and the Google People API. You can either build and maintain this infrastructure yourself, dealing with Google's strict OAuth scopes and idiosyncratic payload structures, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

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

Giving a Large Language Model (LLM) read and write access to Google Contacts is a massive engineering challenge. You have to handle complex field masking, navigate the difference between domain directories and personal contacts, and deal with Google's strict mutation limits. Every time an agent attempts to pull an organizational directory, your custom server code must parse the correct resource names and inject the right query parameters.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Google Contacts, connect it natively to ChatGPT, and execute complex 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 Contacts API

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

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

The readMask and personFields Complexity

Unlike a typical REST API that returns a standard JSON object when you call a GET endpoint, the Google People API returns almost nothing by default. You are strictly required to supply a readMask (for searches) or personFields (for direct lookups) parameter. This is a comma-separated list specifying exactly which fields you want (e.g., names,emailAddresses,phoneNumbers,organizations).

If an LLM hallucinates this parameter or forgets to include a required field, the API simply returns an empty object or throws a bad request error. Building static MCP schemas for this means you must explicitly define these mask properties as required in your JSON Schema, along with detailed descriptions of the accepted enum values, so the LLM knows how to format the request.

Resource Names vs. Standard IDs

Google Contacts does not use simple integer or UUID identifiers. Instead, it relies on resourceName strings, formatted like people/c1234567890. When an LLM searches for a contact, it receives this full string. If the LLM tries to parse the ID out of the string and send just the numeric portion to a DELETE or UPDATE endpoint, the Google API will reject it. Your MCP tool schemas must include explicit prompt engineering in the parameter descriptions, explicitly instructing the LLM to pass the entire resourceName string unchanged.

Sequential Mutation Requirements

Google explicitly warns developers that mutate requests (creating, updating, or deleting contacts) must be sent sequentially to avoid latency and outright failures. If your AI agent framework fires parallel async calls to delete ten contacts at once, Google will aggressively reject the requests. Your agent orchestration layer must be configured for strictly sequential tool execution when dealing with write operations against this specific API.

Strict Rate Limiting and Backoff

Google Contacts enforces strict usage quotas per user and per project. When you hit these limits, Google returns an HTTP 429 response. It is a critical architectural point that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Google API returns HTTP 429, Truto passes that error directly to the caller.

Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your LLM agent framework) is entirely responsible for reading the ratelimit-reset header, pausing execution, and retrying. If you do not build backoff into your MCP client configuration, bulk contact operations will fail mid-flight.

How to Generate a Google Contacts MCP Server

Truto derives MCP tools dynamically from the integration's resource definitions and documentation records. You do not have to write tool definitions by hand. As long as the integration is connected, the MCP tools are available.

You can generate the MCP server scoped to a specific Google account using either the Truto UI or the Truto REST API.

Method 1: Via the Truto UI

This is the fastest path for ad-hoc agent testing or manual configuration.

  1. Log into your Truto dashboard and navigate to the integrated account page for your connected Google Contacts instance.
  2. Click the MCP Servers tab.
  3. Click Create MCP Server.
  4. Select your desired configuration. You can name the server, filter it to specific methods (e.g., read only), or restrict it by tags.
  5. Click Save. The UI will present a generated MCP server URL.

Copy this URL. It contains a cryptographic token that securely maps to this specific connected account.

Method 2: Via the Truto API

For production workflows, you should programmatically generate MCP servers. The API generates a secure token, stores it in a distributed key-value store, and returns a ready-to-use URL.

Make an authenticated POST request to the /integrated-account/:id/mcp endpoint:

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": "ChatGPT Directory Manager",
    "config": {
      "methods": ["read", "write"],
      "tags": ["directory", "search"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response will contain the secure URL:

{
  "id": "mcp_abc123",
  "name": "ChatGPT Directory Manager",
  "config": { "methods": ["read", "write"] },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Treat this URL like a secret credential. It carries both routing logic and authentication.

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP Server URL, you must register it with your ChatGPT environment. You can do this via the ChatGPT user interface or via a manual configuration file for local bridging.

Method 1: Via the ChatGPT UI

If you are on a ChatGPT Pro, Plus, Business, Enterprise, or Education tier, you can configure custom connectors directly in the interface.

  1. Open ChatGPT and go to Settings -> Apps -> Advanced settings.
  2. Enable the Developer mode toggle (MCP support requires this flag to be active).
  3. Under the MCP servers / Custom connectors section, click to add a new server.
  4. Provide a recognizable name, such as "Google Contacts (Truto)".
  5. In the Server URL field, paste the https://api.truto.one/mcp/<token> URL you generated earlier.
  6. Save the configuration.

ChatGPT will immediately ping the endpoint, execute the initialization handshake, and pull down the full schema of available Google Contacts tools.

Method 2: Via Manual Config File (SSE Bridge)

If you are running an environment that requires a standard mcp.json config file (or using an agent framework that connects via standard I/O pipes), you can use the official @modelcontextprotocol/server-sse proxy command to bridge the remote Truto SSE endpoint.

Define your MCP server block like this:

{
  "mcpServers": {
    "google_contacts": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/<YOUR_TRUTO_TOKEN>"
      ]
    }
  }
}

When your agent framework starts, it will execute the npx command, establish a Server-Sent Events connection to Truto, and negotiate the JSON-RPC 2.0 tool definitions natively over standard input and output.

Hero Tools for Google Contacts

When you connect the MCP server, Truto dynamically exposes your Google Contacts resources as executable tools. Here are the highest-leverage tools available for AI agents.

list_all_people_search_contacts

This tool executes a search against the user's contacts. It is the primary entry point for finding existing records before updating or deleting them. It explicitly requires the query parameter and the readMask parameter.

Contextual usage notes: The LLM must supply a valid readMask string, such as names,emailAddresses,phoneNumbers. If omitted, the tool will fail. The returned data corresponds strictly to the fields requested in the mask.

"Search my Google Contacts for anyone named 'Acme Corp' and return their names, email addresses, and phone numbers."

get_single_people_search_contact_by_id

This tool retrieves the full information profile for a specific contact using their exact resource ID. Like the search tool, it requires explicit field mapping.

Contextual usage notes: The personFields parameter is mandatory. The LLM must pass the exact resourceName (e.g., people/c1234567) returned by a previous search operation.

"Get the detailed profile for the contact with ID 'people/c987654321'. Make sure to include their organizations, names, and phoneNumbers in the personFields."

delete_a_people_search_contact_by_id

This tool deletes a specific contact from the user's Google Calendar and Contacts directory. It is a destructive write operation.

Contextual usage notes: The API returns an empty response upon success. The LLM must ensure it has the correct resource ID before calling this. If deleting multiple contacts, the LLM must call this tool sequentially to avoid Google's strict latency limits.

"Delete the contact with ID 'people/c11223344'. Please confirm once the deletion is successful."

list_all_people_other_contacts

Google categorizes contacts into primary contacts and "Other Contacts" (often people you have emailed but haven't explicitly saved to your address book). This tool searches that secondary directory.

Contextual usage notes: This is highly useful for data enrichment workflows where an agent is trying to find historical email addresses that aren't strictly saved in the primary CRM or address book. It also requires the readMask parameter.

"Search my 'Other Contacts' for the email address 'jane.doe@example.com' and return any associated metadata or names."

list_all_people

This tool lists people from the authenticated Google workspace directory via the People API.

Contextual usage notes: This tool is used for querying the broader domain directory rather than personal contacts. It is essential for internal HR workflows or cross-referencing internal employee lists. It returns a collection of people objects belonging to the caller's domain.

"List all people in my workspace directory so I can cross-reference the engineering team's current phone numbers."

To view the complete inventory of available Google Contacts endpoints, parameter schemas, and custom resources, visit the Google Contacts integration page.

Workflows in Action

Connecting an LLM to Google Contacts via MCP allows you to string multiple tools together into autonomous workflows. Here are two real-world examples of how ChatGPT orchestrates these tools.

Scenario 1: Contact Deduplication and Cleanup

When a sales representative changes territories, they often have outdated contacts cluttering their address book. You can ask ChatGPT to find and remove specific organizational contacts.

"Search my contacts for anyone associated with 'OldCo'. If you find any, retrieve their full details to confirm they belong to that organization, and then delete them."

How the agent executes this:

  1. Call list_all_people_search_contacts: The agent sets query to "OldCo" and readMask to "names,organizations".
  2. Evaluate Results: The agent receives a list of resource names (e.g., people/c111, people/c222).
  3. Call get_single_people_search_contact_by_id: The agent iterates through the IDs, setting personFields to "names,organizations,emailAddresses" to ensure the contact actually belongs to OldCo and isn't a false positive.
  4. Call delete_a_people_search_contact_by_id: The agent sequentially deletes the confirmed contacts, waiting for a 200 OK after each call.
sequenceDiagram
  participant User as User
  participant ChatGPT as ChatGPT
  participant MCP as MCP Server
  participant Google as Google Contacts API
  
  User->>ChatGPT: Search for OldCo contacts and delete them.
  ChatGPT->>MCP: Call list_all_people_search_contacts
  MCP->>Google: GET /v1/people:searchContacts?query=OldCo
  Google-->>MCP: Returns people/c111
  MCP-->>ChatGPT: Tool result (Contact ID)
  ChatGPT->>MCP: Call get_single_people_search_contact_by_id
  MCP->>Google: GET /v1/people/c111
  Google-->>MCP: Returns full profile
  MCP-->>ChatGPT: Tool result (Profile data)
  ChatGPT->>MCP: Call delete_a_people_search_contact_by_id
  MCP->>Google: DELETE /v1/people/c111
  Google-->>MCP: 200 OK
  MCP-->>ChatGPT: Tool result (Success)
  ChatGPT-->>User: OldCo contacts have been removed.

Scenario 2: Recovering Lost Contact Data

A user needs to find a phone number for someone they emailed months ago but never formally saved.

"I need the phone number for John Smith. He might not be in my main contacts, so please check my 'Other Contacts' as well."

How the agent executes this:

  1. Call list_all_people_search_contacts: The agent searches the primary directory first. If it finds John Smith but the phoneNumbers array is empty, it proceeds to step two.
  2. Call list_all_people_other_contacts: The agent searches the secondary directory, setting query to "John Smith" and readMask to "names,emailAddresses,phoneNumbers".
  3. Parse and Return: The agent finds the historical record, extracts the phone number, and presents it to the user in natural language.

Security and Access Control

Exposing an enterprise Google directory to an LLM requires strict governance. Truto MCP servers provide several mechanisms to constrain what the AI can do:

  • Method Filtering: You can restrict a server to safe operations. By passing methods: ["read"] during server creation, Truto will strip all create, update, and delete tools from the MCP schema. The LLM simply won't know those endpoints exist.
  • Tag Filtering: Limit the server to specific resource subsets. Passing tags: ["search"] ensures the agent can only execute search queries, preventing it from touching broad directory listing endpoints.
  • Expiration (TTL): Use the expires_at property to create short-lived servers. Once the ISO datetime is reached, automated cleanup mechanisms instantly revoke the token and drop the server connection.
  • API Token Authentication: By default, the cryptographically secure URL acts as a bearer token. For zero-trust environments, you can enable require_api_token_auth: true, forcing the MCP client to also pass a valid Truto API token in the Authorization header to execute a tool.

The Shift from Code to Configuration

Integrating Google Contacts into an AI workflow used to mean writing complex OAuth flows, handling pagination loops, manually parsing readMask properties, and fighting rate limit backoffs. Every new capability required a new deployment.

By leveraging an MCP server backed by Truto's dynamic tool generation, you shift the integration burden from code to configuration. The LLM dynamically reads the schemas, understands the required fields, and executes the operations. Your engineering team can stop maintaining custom integration code and focus entirely on orchestrating the intelligence of your AI agents.

More from our Blog