Google People integration for AI agents.
Google People integration for AI agents with secure authentication and server-side credential injection. Open Connector runs the OAuth, seals the token in an encrypted vault, and serves Google People tools to your agent over MCP or a typed API — credentials injected server-side, every call audited, nothing leaving your infrastructure. Open source (AGPL-3.0) and self-hostable.
Real Google People actions, managed and audited.
Your user connects Google People once; your agent can then secure AI-agent actions — scoped to the OAuth permissions you grant and the tool allowlist you configure. Every action is least-privilege and written to a tamper-evident audit trail.
- 1
Your user grants Google People access once (OAuth) — the token lands in the vault.
- 2
Your agent calls a tool over MCP or the typed API; Open Connector injects the credential server-side.
- 3
Every routed call appends a hash-chained audit record — nothing leaves your infra.
Supported Google People tools.
23 tools are generated from the published Google People catalog. Descriptions are plain text; each action remains subject to its configured authentication and tool allowlist.
Showing 23 tools. All published catalog entries are included in this page's server-rendered HTML.
- People ContactGroups BatchGet
- Get a list of contact groups owned by the authenticated user by specifying a list of contact group resource names.
- contactgroups
- People ContactGroups Create
- Create a new contact group owned by the authenticated user. Created contact group names must be unique to the users contact groups. Attempting to create a group with a duplicate name will return a HTTP 409 error. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- contactgroups
- People ContactGroups Delete
- Delete an existing contact group owned by the authenticated user by specifying a contact group resource name. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- contactgroups
- People ContactGroups Get
- Get a specific contact group owned by the authenticated user by specifying a contact group resource name.
- contactgroups
- People ContactGroups List
- List all contact groups owned by the authenticated user. Members of the contact groups are not populated.
- contactgroups
- People ContactGroups Members Modify
- Modify the members of a contact group owned by the authenticated user. The only system contact groups that can have members added are `contactGroups/myContacts` and `contactGroups/starred`. Other system contact groups are deprecated and can only have contacts removed.
- contactgroups
- People ContactGroups Update
- Update the name of an existing contact group owned by the authenticated user. Updated contact group names must be unique to the users contact groups. Attempting to create a group with a duplicate name will return a HTTP 409 error. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- contactgroups
- People OtherContacts CopyOtherContactToMyContactsGroup
- Copies an "Other contact" to a new contact in the user's "myContacts" group Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- othercontacts
- People OtherContacts List
- List all "Other contacts", that is contacts that are not in a contact group. "Other contacts" are typically auto created contacts from interactions. Sync tokens expire 7 days after the full sync. A request with an expired sync token will get an error with an [google.rpc.ErrorInfo](https://cloud.google.com/apis/design/errors#error_info) with reason "EXPIRED_SYNC_TOKEN". In the case of such an error clients should make a full sync request without a `sync_token`. The first page of a full sync request has an additional quota. If the quota is exceeded, a 429 error will be returned. This quota is fixed and can not be increased. When the `sync_token` is specified, resources deleted since the last sync will be returned as a person with `PersonMetadata.deleted` set to true. When the `page_token` or `sync_token` is specified, all other request parameters must match the first call. Writes may have a propagation delay of several minutes for sync requests. Incremental syncs are not intended for read-after-write use cases. See example usage at [List the user's other contacts that have changed](/people/v1/other-contacts#list_the_users_other_contacts_that_have_changed).
- othercontacts
- People OtherContacts Search
- Provides a list of contacts in the authenticated user's other contacts that matches the search query. The query matches on a contact's `names`, `emailAddresses`, and `phoneNumbers` fields that are from the OTHER_CONTACT source. **IMPORTANT**: Before searching, clients should send a warmup request with an empty query to update the cache. See https://developers.google.com/people/v1/other-contacts#search_the_users_other_contacts
- othercontacts
- People People BatchCreateContacts
- Create a batch of new contacts and return the PersonResponses for the newly Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People BatchDeleteContacts
- Delete a batch of contacts. Any non-contact data will not be deleted. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People BatchUpdateContacts
- Update a batch of contacts and return a map of resource names to PersonResponses for the updated contacts. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People Connections List
- Provides a list of the authenticated user's contacts. Sync tokens expire 7 days after the full sync. A request with an expired sync token will get an error with an [google.rpc.ErrorInfo](https://cloud.google.com/apis/design/errors#error_info) with reason "EXPIRED_SYNC_TOKEN". In the case of such an error clients should make a full sync request without a `sync_token`. The first page of a full sync request has an additional quota. If the quota is exceeded, a 429 error will be returned. This quota is fixed and can not be increased. When the `sync_token` is specified, resources deleted since the last sync will be returned as a person with `PersonMetadata.deleted` set to true. When the `page_token` or `sync_token` is specified, all other request parameters must match the first call. Writes may have a propagation delay of several minutes for sync requests. Incremental syncs are not intended for read-after-write use cases. See example usage at [List the user's contacts that have changed](/people/v1/contacts#list_the_users_contacts_that_have_changed).
- people
- People People CreateContact
- Create a new contact and return the person resource for that contact. The request returns a 400 error if more than one field is specified on a field that is a singleton for contact sources: * biographies * birthdays * genders * names Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People DeleteContact
- Delete a contact person. Any non-contact data will not be deleted. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People DeleteContactPhoto
- Delete a contact's photo. Mutate requests for the same user should be done sequentially to avoid // lock contention.
- people
- People People GetBatchGet
- Provides information about a list of specific people by specifying a list of requested resource names. Use `people/me` to indicate the authenticated user. The request returns a 400 error if 'personFields' is not specified.
- people
- People People ListDirectoryPeople
- Provides a list of domain profiles and domain contacts in the authenticated user's domain directory. When the `sync_token` is specified, resources deleted since the last sync will be returned as a person with `PersonMetadata.deleted` set to true. When the `page_token` or `sync_token` is specified, all other request parameters must match the first call. Writes may have a propagation delay of several minutes for sync requests. Incremental syncs are not intended for read-after-write use cases. See example usage at [List the directory people that have changed](/people/v1/directory#list_the_directory_people_that_have_changed).
- people
- People People SearchContacts
- Provides a list of contacts in the authenticated user's grouped contacts that matches the search query. The query matches on a contact's `names`, `nickNames`, `emailAddresses`, `phoneNumbers`, and `organizations` fields that are from the CONTACT source. **IMPORTANT**: Before searching, clients should send a warmup request with an empty query to update the cache. See https://developers.google.com/people/v1/contacts#search_the_users_contacts
- people
- People People SearchDirectoryPeople
- Provides a list of domain profiles and domain contacts in the authenticated user's domain directory that match the search query.
- people
- People People UpdateContact
- Update contact data for an existing contact person. Any non-contact data will not be modified. Any non-contact data in the person to update will be ignored. All fields specified in the `update_mask` will be replaced. The server returns a 400 error if `person.metadata.sources` is not specified for the contact to be updated or if there is no contact source. The server returns a 400 error with reason `"failedPrecondition"` if `person.metadata.sources.etag` is different than the contact's etag, which indicates the contact has changed since its data was read. Clients should get the latest person and merge their updates into the latest person. If making sequential updates to the same person, the etag from the `updateContact` response should be used to avoid failures. The server returns a 400 error if `memberships` are being updated and there are no contact group memberships specified on the person. The server returns a 400 error if more than one field is specified on a field that is a singleton for contact sources: * biographies * birthdays * genders * names Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
- People People UpdateContactPhoto
- Update a contact's photo. Mutate requests for the same user should be sent sequentially to avoid increased latency and failures.
- people
Google People integration, answered
- How do AI agents use Google People through Open Connector?
- Your user connects Google People once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Google People tools to your agent over MCP or a typed API, with credentials injected server-side on each call.
- Is this a Google People MCP server?
- Yes. Open Connector can serve Google People as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Google People actions with credentials injected server-side.
- Where do Google People credentials live?
- In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.
Give your agents Google People — keep the keys.
Open source, self-hostable, with Google People credentials that never leave your infrastructure. Run it from source today.