Your agent needs to schedule a meeting, pull the transcript afterward, and post the recap to Team Chat. Zoom now ships remote MCP servers alongside the REST API your backend has been calling for years. The obvious move is to reach for MCP and stop thinking about it. That instinct breaks on the first requirement: no Zoom MCP server exposes a tool that creates a meeting. Here is the decision framework, grounded in what Zoom actually publishes.
These are not two versions of the same thing. One is a set of hosted, LLM-shaped retrieval surfaces layered on top of Zoom Workplace. The other is the full platform control plane. Understanding which is which decides most of the architecture for you.
Zoom hosts its MCP servers over streamable HTTP and publishes them to the Model Context Protocol registry under the io.github.zoom namespace. There is no single "Zoom MCP server"; there are seven, split by product area, each with a distinct URL and a distinct scope set.
Connection requires a General app created on the Zoom App Marketplace, a user OAuth authorization code exchange, and a bearer token on every request. Full details live in Zoom's MCP documentation and the Zoom MCP Server reference.
The REST API exposes more than 600 endpoints at https://api.zoom.us/v2, covering meetings, webinars, users, cloud recordings, reports, Team Chat, Zoom Phone, Zoom Rooms, and Contact Center. Regional base URLs such as https://api-eu.zoom.us/v2 exist for data residency, and the api_url field in the OAuth token response tells you which region a user belongs to.
Auth supports user OAuth with authorization code, PKCE, device code, and Server-to-Server OAuth using the account_credentials grant. The Marketplace JWT app type is deprecated; this does not affect JWT signatures used by the Video SDK. The full surface is documented in the Zoom API Hub.
Most MCP comparison writing guesses at the tool list. That is the one thing you cannot guess, because the entire capability argument collapses if the inventory is wrong. Everything in this section is transcribed from Zoom's published registry metadata and its own tool documentation, verified against tools/list.
The operational consequence shows up immediately. A recap agent that reads meeting content, reads a Zoom Doc, and posts to a channel is not integrating with "Zoom MCP." It is integrating with three endpoints, each requiring its own scope grant.
The Workspace server is the broadest single surface, and it is the one most teams connect first. Nine tools, each mapped to a granular scope.
The dedicated Meetings server exposes exactly four tools: search_meetings, get_meeting_assets, recordings_list, and get_recording_resource. That is the complete surface.
Read that list again against the name of the server. There is no create_meeting, no update_meeting, and no delete_meeting on any Zoom MCP server, and Zoom's own guidance explicitly routes deterministic meeting CRUD to the REST API. For a product category where "put a meeting on the calendar" is the single most requested agent action, this is the fact that decides your architecture.
The gap is meeting lifecycle specifically, not writes generally, and it would be unfair to leave the impression that Zoom MCP is a read-only surface. Team Chat MCP reads, searches, writes, and updates messages, files, contacts, channels, and channel members. Tasks MCP creates, updates, and assigns. Docs MCP creates documents from Markdown, and Whiteboard MCP creates editable boards and diagrams from prompts.
What Zoom has built is a retrieval and artifact-creation layer. What it has not built is a lifecycle control plane.
Before the gaps, the thing MCP genuinely does better, because it is not a convenience argument. It is a capability argument, and it does not have a REST workaround.
search_meetings runs AI Companion retrieval rather than a plain metadata filter, so an agent can ask "where did we discuss the Q4 pricing change" and get back ranked meetings with summaries, linked documents, and recording references. search_zoom extends that across Team Chat messages, Zoom Docs, and My Notes in a single call. Neither has a REST equivalent. If you build on REST alone, you are rebuilding semantic retrieval over transcripts yourself.
Everything below is the honest inventory in both directions.
Realtime Media Streams is the clearest case, and it is worth being precise about why. RTMS delivers per-participant live audio, video, transcript, chat, and screen share over WebSockets, without a bot appearing in the participant list, driven by meeting.rtms_started and meeting.rtms_stopped webhooks and the meeting:read:meeting_transcripts scope.
MCP is a request and response protocol. RTMS is a media pipeline. No future tool release closes that gap, because it is not a missing feature; it is a different transport class.
Both paths are OAuth, which makes them look interchangeable at a glance. They are not. Three specific constraints on the MCP path change what your deployment story looks like.
MCP path — user-level OAuth is the recommended execution path:
Server-to-Server caveat: S2S can initialize and complete tools/list, but Zoom recommends user OAuth for actual tool execution.
REST path — choose your identity model per workload:
Manual registration is the constraint most teams underestimate. Without Dynamic Client Registration or Client ID Metadata Documents, every MCP client you ship is a hand-created Marketplace app, and every Zoom MCP endpoint you touch needs its scopes configured on it.
meeting:read:search is an MCP scope. meeting:read is a REST scope. They are not aliases. Zoom's own documentation is explicit that the MCP scope set differs from the older broad REST scopes.
The consequence is architectural, not cosmetic. A token minted for the MCP surface does not authorize REST calls, and a REST token does not authorize MCP tool calls. The moment your agent reads over MCP and writes over REST — which the meeting CRUD gap forces on most teams — you are managing two authorization surfaces per user, per tenant, with two consent moments and two revocation paths.
Zoom manages MCP hosting, tool schemas, and AI Companion retrieval quality. That is real operational relief, and it is the strongest practical argument for the MCP path.
What Zoom does not manage on either path is the credential lifecycle, the account feature prerequisites, or your quota budget. Those three break agents in production far more often than a missing endpoint does.
This one deserves its own warning because it fails silently. Semantic meeting search, meeting assets, and recording-content retrieval depend on account features such as Smart Recording and Meeting Summary being enabled. Correct scopes do not substitute for them.
An agent with perfect scopes on an account without those features does not get a 403. It gets a successful response with an empty result set, and the model cheerfully reports that it could not find anything. Verify account features during tenant onboarding, not at first agent run.
Zoom rate limits are per-account and shared across every app on the account, not per-app. One heavy internal integration can throttle your agent, and your agent can throttle it back.
Separately, meeting and webinar create and update operations are capped at 100 per day per user, resetting at 00:00 UTC. An agentic scheduling workflow that proposes, corrects, and reschedules consumes that budget several times faster than a deterministic integration issuing one call per action. Monitor X-RateLimit-Remaining from day one, and distribute bulk operations across host users.
Four gotchas account for most first-week failures on the REST path. The me keyword is mandatory for user-level OAuth apps and forbidden for Server-to-Server apps. Meeting UUIDs beginning with / or containing // must be double URL-encoded. Recording download_url values require bearer auth and may redirect, so follow redirects. Pagination uses next_page_token; page_number is legacy and being phased out.
Both paths hand you a token per user. Neither hands you a vault, rotation logic, or a revocation flow. The token type differs; the infrastructure required does not.
With Zoom specifically, the numbers make this sharper than usual.
Access tokens expire after one hour. Refresh tokens expire after 90 days. Critically, refresh tokens are single-use and rotate: every refresh returns a new access token and a new refresh token, the previous refresh token is invalidated, and Zoom's documentation states that the latest refresh token must always be used for the next refresh request.
That produces a precise, reproducible way to permanently break a user's connection.
Two agent threads refreshing concurrently produce the same outcome. Reactive refresh makes this more likely, not less. Waiting for a 401 means multiple agent threads discover expiry simultaneously and race each other into the rotation window. Refresh must be proactive, driven by expires_in, and serialized with a distributed lock.
For 40 users across 8 tenants, that is 40 credentials to encrypt at rest, 40 proactive refresh schedules, and 40 revocations to execute at offboarding. That is the baseline cost of either path.
Because the MCP and REST scope sets are distinct, a hybrid agent that reads over MCP and writes over REST can require two credentials per user rather than one. Eighty stored secrets, eighty rotation schedules, two consent moments per person during onboarding. That is not a Zoom design flaw; it is the consequence of two authorization surfaces on the same platform, and it is yours to operate.
For a deeper look at secure token management for AI agents at scale, including proactive refresh and distributed locking patterns, the linked post covers the full infrastructure model.
Scalekit's Zoom connector handles the per-user OAuth flow, vaulted token storage, and rotating-refresh handling for both paths, so the MCP versus API decision does not change your credential infrastructure.
The setup is a one-time configuration per environment. You need a Zoom General app with its client ID and secret, the Scalekit redirect URI pasted into both the Zoom OAuth redirect field and the OAuth allow list, and a connection created in the Scalekit dashboard.
One warning before any code: the connection_name string in your code must match the connection name configured in the Scalekit dashboard exactly. This is the single most common integration error. Full setup steps live in the Zoom connector documentation.
Before the code, the important distinction. The agent is not loading a flat catalog of every Zoom tool the connector supports. It is loading the tools that this specific user's connected account is authorized to call, resolved at request time against their Zoom grant.
That distinction is also a cost lever. The Zoom connector ships 28 tools. A scheduling agent needs five. At roughly 200 tokens per tool schema, filtering the surface removes about 4,600 tokens from every context window on every run, before the agent does any work.
Scalekit returns native LangChain StructuredTool objects, so there is no schema reshaping step between the connector and the model.
That agent just created a Zoom meeting, which is the operation no Zoom MCP server exposes. It works because the connector calls the REST API underneath while keeping per-user identity intact. This is the same pattern described in the LangChain tool calling deep dive.
Scalekit returns tool schemas with input_schema, the exact shape Anthropic's tool use API expects, so the mapping is a rename rather than a conversion. The toolNames filter is where you enforce least privilege.
Zoom's REST surface is 600+ endpoints and the connector ships 28 prebuilt tools, so there will be calls you need that no tool wraps. Webinars, reports, and Zoom Phone are the usual ones.
The proxy path calls any Zoom endpoint with the user's token injected server-side. Your agent never sees a credential, and you do not build a second auth integration to reach the long tail.
Come back to the seven-endpoint problem, because this is where it gets expensive. A recap agent that searches meetings, reads a Zoom Doc, and posts to a channel touches three Zoom MCP endpoints. Three registrations, three granular scope sets, three consent surfaces, with no DCR or CIMD to automate any of it. Multiply by every tenant you onboard.
Virtual MCP servers collapse that into one endpoint you define once.
You create the server once per agent role, not once per user, declaring which connections and which specific tools are exposed. The response gives you a config_id and a static mcp_server_url you reuse for every user and every session.
Before each run, confirm the user's connections are still active, then mint a short-lived token bound to that user. OAuth grants can be revoked at any moment, so checking first is what turns a mid-task failure into a clean re-auth prompt.
Zoom's Team Chat MCP server exposes write and update tools for messages, channels, and channel members. A recap agent needs to send one message. Point it at the full server and it also holds channel deletion and member removal it will never legitimately use.
The agent sees only the tools you explicitly allow, not everything the connector exposes. One server definition serves all users, and each run gets a short-lived session token scoped to that user's connected accounts. Setup happens once per agent role; runtime is a token mint.
The audit question a Zoom deployment eventually gets is not "did the agent work." It is "whose authorization was used to pull that recording, and who approved it." That question has a bad answer if your agent runs on a shared Server-to-Server credential.
Understanding agent tool observability is key to answering that question confidently in production.
A shared credential makes every recording fetch and every deleted meeting look identical, both in your logs and in Zoom's own account audit trail. Per-user connected accounts mean each call is attributed to the human whose grant permitted it, with 90 days of retained history you can export. This is the same principle behind audit trails for agent auth in B2B SaaS.
executeTool returns an executionId alongside the tool output. Carry it into your own structured logs, keyed to the agent run and the triggering user.
When a Zoom-side incident surfaces later — a recording accessed or a meeting deleted — that identifier is what connects the action to the authorization event that permitted it. Without it, you are reconstructing intent from timestamps.
If your Zoom agent retrieves and recaps, build on the MCP servers. search_meetings and search_zoom give you AI Companion semantics that REST cannot reproduce, and Docs, Whiteboard, and Tasks writes are already there.
If your agent schedules, provisions, reacts to events, or touches live media, build against the REST API. Meeting CRUD, webhooks, and RTMS have no MCP path, and none is coming, because the constraint is architectural rather than a missing tool.
Most production Zoom agents will use both, which means two scope universes and two token surfaces per user. The credential management problem is identical either way, and it is the part that needs production-grade infrastructure regardless of which path you are on. The broader patterns that apply here are covered in agent tool calling auth production problems, patterns, and anti-patterns.
Browse the Scalekit Zoom connector or read the Zoom connector docs.
Building a Zoom agent and want a second pair of eyes on the auth model? Join the Scalekit Slack community, or talk to us for immediate help.
