Your agent needs to read and write a user's Google Contacts. It has to resolve "email Sarah from security" to a real address, add a new lead to the right group, or clean up duplicates after an import. Google now gives you two ways in: a People API MCP server in Developer Preview, and the People API you may already know. They sound interchangeable. They are not. The tool coverage, the auth model, and what you carry in production all differ, and for contact writes specifically, one of those differences is a hard wall. Here is how to choose.
Google Contacts has no standalone API of its own anymore; it is served entirely by the People API. Both the MCP server and the direct integration read and write the same underlying data, so the real question is which interface your agent should hold.
Google's People API MCP server is a remote, Google-hosted endpoint at https://people.googleapis.com/mcp/v1, reachable over HTTP with OAuth 2.0. It ships through the Google Workspace Developer Preview Program, so treat it as pre-GA and subject to change. It exposes a single toolset of three tools, all read-only: search_contacts, search_directory_people, and get_user_profile. It inherits the same permissions and governance as the signing-in user, and Google explicitly recommends screening prompts for injection because the host can read account data. Setup and endpoint details are in Google's People API MCP server documentation.
The People API is the full REST surface for Google Contacts, and it replaced the legacy Contacts API when Google turned that down in January 2022. It covers the entire contact lifecycle: create, read, update, and delete contacts; batch operations; contact groups and membership; "Other Contacts" reads plus copy-to-My-Contacts; directory list and search; and photo management. It authenticates with OAuth 2.0 for per-user delegation and, on Google Workspace, with a service account using domain-wide delegation. The reference lives in Google's People API documentation.
The two paths overlap only on reads, and even there the API reaches further. For any agent that changes contact data, the comparison is short. For agents that only look people up, the MCP server is a genuinely convenient shortcut.
The MCP server handles three lookup jobs. The People API handles those plus everything operational.
The MCP server is built for the "resolve a person before acting" step: find Sarah's email before drafting a message, confirm a directory colleague before scheduling, read the current user's profile. That is a real and common agent sub-task, and three tools is enough for it.
Everything past lookup is absent: no create, no update, no delete, no groups, no batch, no photo, no incremental sync. This is not a roadmap gap to design around. The Developer Preview server is a read surface today, and any write path has to run through the People API.
Both paths run on OAuth 2.0 and both act as the authorizing user, so the agent can never exceed what that user can do. The difference shows up the moment there is no user sitting in front of the agent.
If your agent runs on a schedule — say a nightly dedupe pass, a CRM-to-Contacts sync, or a bulk import from an onboarding sheet — there is no human to complete a browser consent. The MCP server has no answer for that; it requires an interactive per-user OAuth flow.
The People API does have an answer. A Google Workspace service account with domain-wide delegation authenticates server-to-server, with no user interaction, and acts across the domain's users. That path is Workspace-only; consumer Gmail accounts still require per-user OAuth. For background contact automation in a B2B product, the service-account option is the difference between shipping and not.
On the MCP path, Google manages the endpoint, the tool schemas, and permission enforcement. You still own the OAuth client, per-user token storage, refresh, and revocation, plus injection screening on untrusted input. Because the server is Developer Preview, you also absorb whatever changes when it moves toward general availability.
On the People API path, you own more: OAuth or service-account setup, token lifecycle, retries and error handling, pagination and sync-token bookkeeping, and the tool schemas your model needs. The API is versioned and stable, which is what you want for a deterministic pipeline, but the surface area you maintain is entirely yours.
The choice tracks one axis: read-only lookup versus real contact management.
Use the People API MCP server when:
Use the Google People API when:
Both paths hand you a per-user credential and stop there. Neither gives you a vault, rotation logic, or a revocation flow, and that is the part that actually breaks in production.
A single OAuth token is fine in a demo. A multi-tenant B2B contacts agent is the opposite of a demo: every user authorizes their own Google account, so you hold one credential per user, times every tenant. That is N tokens to encrypt, refresh before expiry, and revoke the moment someone offboards. Miss the revocation and a token minted months ago still reads a user's contacts long after their account was disabled. The problem is identical whether you chose the MCP server or the API; only the token's shape differs. This is the core challenge covered in secure token management for AI agents at scale.
Scalekit's Google Contacts connector handles the per-user OAuth flow, encrypted token storage, and automatic refresh, so the MCP-versus-API decision never touches your auth infrastructure. Credentials stay in the vault and never enter your agent runtime. What the user can't do, the agent can't do, because every call resolves to that user's own connected account. The full setup lives in the Google Contacts connector documentation.
Scalekit wraps the People API as 24 LLM-ready tools, so you skip schema writing, OAuth plumbing, and token handling. The example below uses the Anthropic SDK; the identical connected-account pattern works with LangChain, CrewAI, Google ADK, and Mastra.
Install the SDKs, then set your Scalekit credentials from the dashboard under Developers, then API Credentials.
The sequence is discovery, then scope, then execution. list_scoped_tools returns only the tools the current user's connected account is authorized to call, filtered to the googlecontacts connection. execute_tool then runs the tool the model picks, as that user, using the vaulted token. The connection name in the filter must match the connection you created in the Scalekit dashboard, character for character.
Swap the connection name and the prompt, and the same code drives any connector. The AgentKit framework examples cover LangChain, CrewAI, Google ADK, Mastra, and Vercel AI, each on the same connected-account model, so the auth and tool-calling shape does not change when you switch runtimes.
Going through Scalekit is not just convenience; it changes what your agent can do and how safely it does it.
Google's official MCP server gives you three read-only tools in Developer Preview. Scalekit's connector gives you the full People API surface as per-user scoped tools you can call today: create, update, delete, groups, batch, other-contacts, and directory. You are not choosing between reads and writes; you get the whole surface, scoped to each user.
Every tool call runs as the authorizing user and lands in an audit log with full attribution: who authorized it, which agent ran it, which tool executed, and the result. That log is queryable and exportable to your SIEM, which is what turns "the agent updated a contact" into an accountable action rather than a shared service-account entry. Understanding audit trails for agent auth in B2B SaaS is key to what downstream observability captures.
Most real contacts agents are not contacts-only; they read a calendar, check Gmail, and update a CRM in the same run. A standard MCP server exposes every tool it has, which bloats context and widens blast radius. Scalekit Virtual MCP Servers invert that: you declare which connections and which tools a role may see, and you get one static endpoint. Per-user isolation comes from a short-lived session token minted before each run and scoped to that user's connected accounts. One server definition serves everyone; the endpoint is static, the identity is not. That is the model for multi-tool, multi-tenant agents without standing up a server per user.
If your agent only resolves and looks people up, and you are comfortable on a Developer Preview surface, the People API MCP server is a fast read-only shortcut. If your agent creates, updates, groups, or syncs contacts, or runs headless, build against the People API; the MCP server has no write path at all. Most production contacts agents need writes, which makes the API the default and the MCP server a narrow read helper on top of it. Either way, the credential management is the same problem, and that is the part worth solving with infrastructure rather than rebuilding per connector. Understanding credential ownership across agent tool-calling patterns can help you make the right architectural call. Browse the Scalekit Google Contacts connector or compare plans on the pricing page.
If you are wiring a Google Contacts agent and want a second pair of eyes on the auth model, join the Scalekit Slack community or talk to an engineer for direct help. For patterns to start from, see the CRM agent, meeting prep agent, and sales call prep agent templates. For a deeper look at how token refresh works for AI agents in production, the linked guide covers the full lifecycle.
