Your agent needs to read and act on Google Meet. You went looking for a Meet MCP server the way you would for Slack or GitHub, and the picture is murkier than you expected. Google has shipped official remote MCP servers for a growing list of products, but Meet is not one of them yet. What exists instead is a set of community MCP servers, most of which quietly talk to the Calendar API rather than the Meet REST API. That distinction changes what your agent can actually do. Here is how to pick.
These two paths are not two views of the same surface. One is a community-maintained convenience layer aimed at scheduling; the other is Google's official data plane for meeting artifacts.
Google's official Model Context Protocol (MCP) program does cover Workspace, but selectively. As of the current supported-products list, the Google Workspace MCP servers in Developer Preview are Google Drive, Gmail, Google Calendar, Google Chat, and the People API. Google Meet is absent. There is no meetmcp.googleapis.com endpoint to point an agent at.
The Meet MCP servers you will find in public registries are third-party projects. Most of them interact with Meet through the Google Calendar API, exposing tools such as create-meeting, list-meetings, get-meeting-details, update-meeting, and delete-meeting. That is genuinely useful for scheduling, but it is Calendar functionality with a Meet link attached. These servers run locally, you supply your own OAuth credentials, and you own the deployment. We are not linking specific community servers here; treat them as unmaintained relative to your production timeline.
The official Google Meet REST API sits at https://meet.googleapis.com/v2 and is scoped to meetings, not identity or scheduling. Its resources are spaces, conferenceRecords, conferenceRecords.participants, conferenceRecords.recordings, conferenceRecords.transcripts, conferenceRecords.transcripts.entries, and conferenceRecords.smartNotes. Authentication is OAuth 2.0. Recordings export to the organizer's Google Drive and transcripts to a Google Doc, usually ready shortly after a conference ends. The API itself is request and response; event delivery runs through the separate Google Workspace Events API into Cloud Pub/Sub.
The two paths barely overlap. One creates scheduled meetings; the other reads what happened inside them. That is the whole comparison in a sentence, and it drives every decision below.
The capability split is unusually clean here, because the community MCP path and the REST API path are built on different Google APIs.
Post-meeting intelligence lives only in the REST API. If your agent summarizes calls, extracts action items from transcripts, audits attendance, or files recordings, the community MCP path cannot help; it never sees a conference record. Conversely, if all your agent does is put a meeting on someone's calendar, the REST API is the wrong tool, because it does not schedule dated calendar events with invitees. Most real agents need both surfaces, which is why a Meet agent is rarely a single-connector agent.
Both paths use OAuth 2.0, and both make the agent act as the user who granted consent. The Meet REST API returns records only for spaces the authenticated principal can access, so scope is a function of identity by default. For headless, domain-wide access, the REST API also supports a service account with domain-wide delegation, which the community Calendar-based servers do not meaningfully offer.
There is a production wrinkle on either path. Until Google verifies your external OAuth app, users see an unverified-app screen naming your intermediary domain rather than your brand. Switching to an organization-owned OAuth client does not bypass verification. This is Google's behavior, not something the MCP layer or a proxy removes, and it applies whether you build against a community server or the REST API directly.
With a community MCP server, you own the server: you host it, patch it, refresh its OAuth credentials, and inherit whatever the maintainer did or did not handle around token refresh and revocation. With the direct REST API, you own everything the API does not: request schemas, cursor-based pagination on conferenceRecords and participants, error handling, retries, the OAuth flow, and the token lifecycle for every user.
Whichever path you choose, you end up holding a Google credential per user. OAuth gives you a token per person; it does not give you a vault, a rotation policy, or a revocation flow. Those are yours to build.
In a multi-tenant B2B Meet agent, every user authorizes their own Google account. That is N tokens to encrypt, isolate per tenant, refresh before expiry, and revoke on offboarding. The failure mode is quiet: an employee is disabled in your IdP, but a Google refresh token issued nine months ago and stored on a box somewhere still works. The agent does not decide to keep using it. It just does. This is the same problem on both paths; only the token's origin differs. For a deeper look at how to handle token refresh for AI agents, the failure modes and best practices are covered in detail.
Scalekit's Google Meet connector wraps the official Meet REST API v2 as 16 LLM-ready tools with OAuth 2.0, and resolves the right user's token on every call so credentials never touch your agent runtime. The connector covers the full artifact surface: googlemeet_create_meet_space, googlemeet_list_conference_records, googlemeet_list_participants, googlemeet_get_recording, googlemeet_get_transcript, googlemeet_list_transcript_entries, and googlemeet_get_smart_note, among others. The path decision does not change what you need at the credential layer, and Scalekit handles that layer for you. For the deeper background on OAuth for AI agents and production architecture, see how Scalekit approaches the token lifecycle and per-user delegation.
The pattern below is per-user by construction. You never write a Meet tool schema, and no Google token enters your agent code. The full quickstart lives in the AgentKit quickstart.
In the Scalekit dashboard, create a Google Meet connection under AgentKit and Connections, supply your Google Cloud OAuth client, and enable the Google Meet API in your Google Cloud project. The connection name you choose, for example googlemeet, is what your code references on every call. Install the SDK with pip install anthropic scalekit-sdk-python protobuf.
The agent does not load a flat Meet catalog. It loads only the tools the current user's connected account is authorized to call, resolved from the identifier you pass. That identifier comes from your own authenticated session, never from the client. The call that retrieves this scoped surface is list_scoped_tools. Understanding secure token management for AI agents is essential before wiring this pattern into production.
With the scoped tools in Anthropic's native format, the loop is the standard Claude tool-use pattern. When Claude asks for a tool, you call execute_tool with the same identifier, and Scalekit makes the Meet REST API call as that user. The token is fetched from the vault and never returned to your code.
To reach that prompt, Claude will typically chain googlemeet_list_conference_records, then googlemeet_list_transcripts, then googlemeet_list_transcript_entries. You wrote none of those schemas, and Scalekit maintains them against the live Meet API, so a Google-side change does not become your code change. The same connected-account pattern works with other frameworks through the AgentKit code samples, including LangChain and Google ADK adapters. See how tool calling authentication for AI agents works across different frameworks.
A real Meet agent is usually a Meet plus Calendar plus Drive agent. That is exactly where a raw MCP catalog starts to hurt, and where Scalekit's Virtual MCP Servers change the model. The concept is covered in the Virtual MCP overview and in when to use a Virtual MCP server.
A standard MCP server exposes everything it has. A summarizer agent that only needs to read transcripts should not also hold the ability to end conferences or change space access. A Virtual MCP server enforces least privilege at the tool level: the agent sees only the tools you explicitly allow, not everything the connector exposes.
One server definition serves all your users. Before each run, a short-lived session token is minted scoped to that specific user's connected accounts, so there is no credential sharing between users and no per-user server to configure. The endpoint is static; the identity is not. There is no MCP server for you to deploy, host, or maintain, which is the maintenance burden the community Meet MCP path puts squarely on you.
When your agent ends a conference or exports a recording, someone will eventually ask who authorized it. On a self-hosted community server, that answer is whatever logging you happened to add. With Scalekit, every tool call is attributable.
Scalekit records which user initiated the action, which agent acted, and which resource was accessed, as queryable auth logs. That is the audit trail an enterprise security review asks for, and it is the same trail whether the underlying call hit googlemeet_get_transcript or any other tool. For the reasoning behind treating this as first-class, see agent tool observability and audit trails for agent auth.
If your agent's entire job is scheduling meetings and a human is present to consent, a community MCP server gets you moving quickly, with the understanding that you own its upkeep. If your agent reads what happened in meetings — transcripts, recordings, participants, or smart notes — build against the official Google Meet REST API, because that data does not exist on the community path. Most production Meet agents need both scheduling and artifacts, which means multiple connectors and, underneath them, per-user credential isolation. That last part is the same problem on every path, and it is the part that needs production-grade infrastructure rather than another server to babysit.
If you are also weighing the adjacent Google surfaces, the same framework applies in Google Calendar MCP vs API and Google Drive MCP vs API. To see a Meet-shaped agent end to end, the meeting prep agent template and the sales call prep agent template are good starting points, and pricing for building on the connector library is on the Scalekit pricing page.
Browse the Scalekit Google Meet connector or read the connector docs to wire it into your agent. If you want a hand, join the Scalekit Slack community or talk to us for help building Meet agents.
