zoom-mcp

zoom-mcp

MCP server for Zoom's Users Admin REST API. Wraps the officialhttps://developers.zoom.us/docs/api/users/ spec — Users and Groups —driven by PRD-14714's "Account creation / validation" requirement(onboarding step: account creation and group-driven provisioning, plusvalidation). 15 tools, trimmed down from an original 71-toolfull-API build (2026-08-04), then trimmed again from 22 to 15(2026-08-07) — see Scope below.

MSPbots Connector gives your AI clients one MCP URL to reach your entire MSP stack (RMM, PSA, documentation, security, finance), and gives you control over who can call which tool and a record of everything that was called.

Hosted service: connect.mspbots.ai · Free to use.

Why Connector

Quick start

1. Sign up at connect.mspbots.ai.
2. Connect your vendors. Pick from 150+ connectors and authorize each one on the vendor's own page, or bring your own API keys. No extra vendor accounts needed.
3. Set access. Create roles and decide which tools each role may call. Nothing is allowed until you allow it.
4. Add your MCP URL to your AI client. Copy the URL from your Connector dashboard into Claude, ChatGPT, Cursor, VS Code, Gemini, Codex, or any MCP-capable client.
5. Ask your AI to do real work, and watch every call appear in the audit log.

Features

Unified gateway

• One MCP URL for all your AI clients
• 150+ connectors across the MSP stack
• Custom MCP servers supported, free
• Authorization happens on each vendor's own page; the AI never sees passwords or tokens
• Bring your own credentials: use the vendor API keys you already have
• Multiple accounts per app; connect once, reuse across AI clients
• Tool search: finds the right action for the task
• One sign-in; vendor credentials are injected behind the scenes and OAuth tokens refresh automatically

Visibility

• Audit log for every tool call (who, which vendor, when)
• Usage dashboard: call volume, top vendors, error rate, per-user activity
• Export audit logs to CSV, or stream to Loki, Graylog, or LogScale (SIEM)
• Optional recording of tool arguments and result summaries (off by default, enabled per organization)

Control

• Per-role, per-tool allowlist, deny by default
• owner / admin / member roles
• SCIM provisioning with Entra ID, Okta, JumpCloud, and Google Workspace

Security

• Credentials encrypted one record at a time (AES-256-GCM, per-record key)
• AI clients authenticate with OAuth 2.1 + PKCE
• Vendor responses are scanned for prompt-injection patterns and returned as structured data. This is one layer of defense, not a guarantee against every attack.
• Static egress IP for customer firewall and API allowlisting

Pricing

Free.

Links: connect.mspbots.ai · mspbots.ai

Tool Scope

Trimmed from 22 tools to 15 tools (2026-08-07). The kept surface isfocused on core user-lifecycle management (create / get / list / update /delete / status / permissions) plus group membership management —together the two building blocks needed for typical onboarding andoffboarding automation. Contact-group and division management (6 toolsacross contact_groups.py and divisions.py) were dropped as lower-valueniche capabilities for that use case, along with zoom_delete_a_group(group deletion is a rare, high-risk admin action outside the normalonboarding/offboarding flow). See the Scope section below for the fullbefore/after mapping.

Naming note: Zoom also publishes its own first-party MCP servers(developers.zoom.us/docs/mcp) — Zoom, Whiteboard, Chat, Docs, Tasks,Canvas, Revenue Accelerator, Meetings. Investigated and confirmed thoseare scoped entirely to meeting/chat/document/whiteboard contentaccess via per-user OAuth 2.1 (Claude/ChatGPT connector style) — noneof them expose user/account administration. This server instead wrapsZoom's standard Admin REST API (https://api.zoom.us/v2) directly,which is the only place account creation/validation actually lives.

Overview

• Stateless HTTP service. No credentials are ever persisted — eachrequest supplies its own Server-to-Server OAuth app credentials viaheaders, used only for the lifetime of that single request.
• Supports concurrent requests; per-request credential isolation is donevia Python contextvars, not a global/shared client instance.
• Entry points: POST /mcp (MCP protocol) and GET /health (healthcheck).
• Default port: 8080 (configurable via MCP_HTTP_PORT).
• All tools were generated mechanically from Zoom's own publishedOpenAPI 3.0 spec (https://developers.zoom.us/api-hub/users/methods/endpoints.json,the machine-readable source behind the public docs page) — path/queryparameters and request-body fields are flattened into named functionarguments; nested object/array-of-object fields (e.g. user_info,members, feature) are passed through as a raw dict/list[dict]matching the vendor's own schema shape.

Scope

15 tools, trimmed down from an original 71-tool full-API build(2026-08-04), by way of an intermediate 22-tool build. MSPbots has noexisting "Zoom" integration configured (confirmed viaweb/int/sys/integration/list), so — matching the approach used forduo-mcp elsewhere in this program — "actual usage" was taken from theoriginal PRD-14714 task's own stated requirement instead: accountcreation and group-driven provisioning, plus validation. That maps to:

• users (8 of 35 original): zoom_create_users,zoom_check_a_user_email (email-availability validation),zoom_get_a_user, zoom_list_users, zoom_update_a_user,zoom_delete_a_user, zoom_update_user_status (activate/deactivate —part of provisioning/validation), zoom_get_user_permissions
• groups (7 of 21 original): zoom_list_groups,zoom_create_a_group, zoom_get_a_group, zoom_update_a_group,plus membership management (the "group-driven" half of provisioning) —zoom_list_group_members, zoom_add_group_members,zoom_delete_a_group_member

Everything else (assistants, collaboration devices, meeting summarytemplates, password/profile-picture/presence/scheduler/settings/virtual-background management on users; admins/channels/locked-settings/webinar-registration/virtual-background/zoom_delete_a_group on groups; all ofcontact_groups and divisions — ~56 tools) was removed as unrelated toaccount creation/provisioning/validation, or (in the case ofzoom_delete_a_group, contact groups, and divisions) as lower-value/nichefor typical onboarding-offboarding automation use cases. If a removedoperation is needed later, the vendor's OpenAPI spec (linked above) stilldocuments it and it can be re-added the same way the kept tools weregenerated.

Authentication

Zoom's Users Admin API uses Server-to-Server OAuth (theaccount_credentials grant — a fully backend two-legged OAuth flow,no user redirect):

POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id=<accountId>
Authorization: Basic base64(clientId:clientSecret)
-> {"access_token": "...", "expires_in": 3599, "token_type": "bearer"}

The access token is valid for only 1 hour and Zoom issues no refreshtoken, so this server performs a fresh token exchange on every singletool call rather than caching anything across MCP requests — the same"re-authenticate every call" approach used by several other vendor-mcpservices in this fleet (webroot-mcp, tsheets-mcp, oitvoip-mcp,covedataprotection-mcp) whose upstream tokens are similarly short-livedor non-refreshable.

HEADER Authorization Parameters

Missing any header returns 401:

{
  "error": "Missing credentials",
  "message": "This server requires the X-Zoom-Account-Id, X-Zoom-Client-Id, X-Zoom-Client-Secret headers",
  "required_headers": ["X-Zoom-Account-Id", "X-Zoom-Client-Id", "X-Zoom-Client-Secret"],
  "optional_headers": []
}

Invalid app credentials surface as a structured tool-level error envelopefrom the token exchange itself, e.g.:

{"error": {"code": "invalid_argument", "message": "Invalid client_id or client_secret", "retryable": false}}

Required scopes on the S2S OAuth app (set on the app's Scopes pagein the Zoom App Marketplace) — grant the full set to use every toolbelow: user:read:admin, user:write:admin, group:read:admin,group:write:admin.

Environment Variables

MCP Endpoint

• POST /mcp — MCP protocol (streamable HTTP transport)
• GET /health — health check, returns {"status": "ok"} (pure local probe, does not call Zoom)

Tool List

Tool names are derived from each operation's own summary in Zoom'sOpenAPI spec (e.g. "Check a user email" → zoom_check_a_user_email).The one naming collision — "Upload/Delete Virtual Background files"exists once for Groups and once for Users — is disambiguated with agroup_/user_ prefix. dict/list[dict] parameters accept thevendor's own nested object shape as-is; see the API Reference linkbelow for the exact sub-field names of each.

page_size maximums above are Zoom's own documented per-endpoint ceilings(from https://developers.zoom.us/api-hub/users/methods/endpoints.json),clamped server-side rather than left unbounded — they differ per endpoint(300 for /groups, 2000 for /users and /groups/{groupId}/members), soeach tool clamps against its own real vendor maximum instead of a singleshared constant.

Errors are returned as a structured JSON envelope (not raised asexceptions), e.g. {"error": {"code": "not_found", "message": "...", "retryable": false}}. code is one of: not_configured, unauthorized,not_found, invalid_argument, rate_limited, upstream_error.

Test Example

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-Zoom-Account-Id: <your-account-id>" \
  -H "X-Zoom-Client-Id: <your-client-id>" \
  -H "X-Zoom-Client-Secret: <your-client-secret>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "zoom_check_a_user_email",
      "arguments": {"email": "[email protected]"}
    }
  }'

Structurally verified (2026-08-03): MCP handshake (initialize/initialized), tools/list (71 tools, 0 schema errors, 0 namecollisions), GET /health, and 401 credential-gating on /mcp allconfirmed working against a locally running instance. A tool call madewith a syntactically valid but fake Account ID/Client ID/Client Secretcorrectly reached Zoom's real OAuth endpoint and returned Zoom's owndocumented error shape(HTTP 400 {"reason":"Invalid client_id or client_secret","error":"invalid_client"}),confirming the request construction (Basic-auth-encoded clientcredentials, account_credentials grant, account_id param) iscorrect per Zoom's own documentation.

Re-verified after the 22→15 trim (2026-08-07): MCP handshake,tools/list (15 tools, 0 duplicate names), and GET /health confirmedworking against a locally running instance.

API Reference

• Public, no login required: https://developers.zoom.us/docs/api/users/(Users Admin API — human-readable docs for all 71 operations coveredhere)
• Public, no login required: https://developers.zoom.us/api-hub/users/methods/endpoints.json(the machine-readable OpenAPI 3.0 spec this server's tools weregenerated from — the authoritative source for exact nested-objectfield names inside any dict/list[dict] parameter)
• Public, no login required: https://developers.zoom.us/docs/internal-apps/s2s-oauth/(Server-to-Server OAuth — how to create the app and generate accesstokens)

Known Gaps

• Trimmed from 71 to 22 tools on 2026-08-04, then from 22 to 15 toolson 2026-08-07. The original build covered the full Users Admin APIsurface per an earlier scope decision (justified at the time by therebeing no MSPbots-existing integration to anchor a narrower scopeagainst). A later scope decision cut this back to the originalPRD-14714 task's actual stated capabilities (account creation,group-driven provisioning, validation) plus minimal supporting CRUD,landing at 22 tools. The 2026-08-07 pass narrowed this further to coreuser lifecycle (create/get/list/update/delete/status/permissions) andgroup membership management, dropping contact-group management,division management, and zoom_delete_a_group as lower-value/niche fortypical onboarding-offboarding automation use cases — see the Scopesection above for the exact mapping and the removed operations. If aremoved operation is needed later, the vendor's OpenAPI spec (linkedbelow) still documents it and it can be re-added the same way the kepttools were generated.
• No test S2S OAuth app credentials available yet — this build hasnot been end-to-end verified against a real Zoom account. Structuralverification (handshake/tools-list/401 gating/real-OAuth-endpointreachability) is complete; functional verification with real data ispending a test Account ID/Client ID/Client Secret with the requiredscopes.
• MSPbots has no existing "Zoom" integration configured (confirmedvia web/int/sys/integration/list — no ZOOM/zoom entry exists),so there was no prior MSPbots interface/param shape to align thisserver's scope against; see Scope above for how the trim target wasdetermined instead.
• Nested object/array-of-object body fields are passed through as araw dict/list[dict] rather than flattened into individual namedarguments (e.g. zoom_create_users' user_info, zoom_add_group_members'members) — this matches the flattening convention used across thisfleet's other large, mechanically-generated vendor-mcps(connectsecure-mcp, covedataprotection-mcp, duo-mcp) for complexnested structures. Consult the OpenAPI spec link above for eachdict's exact sub-field names.
• Some top-level fields Zoom's own spec does not literally markrequired are nonetheless practically required for the call tosucceed — e.g. zoom_create_users' user_info is optional perthe spec's top-level required list (only action is markedrequired there), even though omitting it makes user creationmeaningless. Required/optional markings here follow Zoom's specliterally rather than inferring intent, per this fleet's establishedpractice of not second-guessing a vendor's documented contract.
• zoom_create_users' action="custCreate" requires a separateZoom ISV sales agreement per Zoom's own docs — this server does notvalidate that prerequisite, Zoom's API will reject the call if it'snot met.

Vendor MCP SOP (0818) Compliance Pass — 2026-08-19

Refactored to the stricter vendor-mcp-development-sop-0818.md:

• Errors are now a structured JSON envelope ({"error": {"code", "message", "retryable"}}) instead of ad-hoc f"Error: {e}" strings — code is oneof the SOP's fixed vocabulary, mapped from the Zoom API's HTTP status.
• Responses are serialized with dump_json_capped() (compact, ensure_ascii=False,auto-truncates the largest list field past 20,000 chars) instead ofjson.dumps(..., indent=2).
• Tools are annotated with readOnlyHint / destructiveHint / idempotentHint(mcp.types.ToolAnnotations) per their actual read/write/reversibilitysemantics.
• Docstrings were rewritten to a short summary only; all per-parameterdocumentation (including the previously-embedded API: GET /xxx lines)moved into Annotated[T, Field(description=...)] on each parameter, and aservice-level instructions string was added to FastMCP(...).
• page_size is now clamped server-side against Zoom's own documentedper-endpoint maximum (300 for /groups, 2000 for /users and/groups/{groupId}/members — confirmed against Zoom's published OpenAPIspec, not assumed from the SOP's generic ≤200 fallback) rather than leftunbounded.
• GET /health now returns exactly {"status": "ok"} (previously includedextra service/transport fields not called for by the contract).
• api_client.py was rewritten around a shared module-level httpx.AsyncClientwith SOP-compliant timeouts (connect=5.0, read=30.0, write=10.0, pool=5.0)and bounded retry/backoff on 429/5xx (respecting Retry-After, capped at20s, max 3 retries) — previously each call opened its own short-livedclient with a single flat 30s/60s timeout and no retry logic. In theprocess, ~50 methods for endpoints no tool ever called (divisions, contactgroups, and various group/user sub-resources such as virtual-backgroundupload, presence status, schedulers, and the profile-picture upload) wereremoved as dead code — they were left over from the original 71-toolgeneration pass and had no caller after the 71→22→15 trims described above.
• tools/resources.py, a same-purpose duplicate of the tool-registrationwiring that only re-exported groups/users, was removed; server.py nowregisters both tool modules directly.
• Checked for the "tool registered under an always-false condition" dead-codepattern seen in an earlier repo (cisco-umbrella-mcp) — not present here;registration in server.py is unconditional.
• Confirmed no environment-variable credential fallback exists anywhere inthis codebase (config.py holds no credential fields; the gatewaymiddleware 401s outright if any of the three required headers is missing) —this was already compliant with SOP §3.1 before this pass, no changeneeded.
• Added tests/test_tools.py (tools/list snapshot incl. annotations anddescription-length assertions, plus error-code-mapping tests) andtests/test_middleware.py (401-on-missing/partial-header tests plus acontextvar-isolation test), per SOP §10's minimal test set. Addedpytest/pytest-asyncio as dev dependencies.