Your agent needs to work with Gong. It needs to pull last night's calls, read what happened on a slipping deal, or answer "which accounts pushed back on pricing this quarter." Gong now gives you two paths to that data, and they are not the same thing. One is a hosted MCP server that returns synthesized answers; the other is a REST API that returns raw records and accepts writes. Picking the wrong one is not a style choice; for some agents it is a hard blocker. Here is how to choose.
These two surfaces share a brand and almost nothing else. One is an insight layer; the other is a data layer. Establish that distinction before comparing them.
Gong announced Model Context Protocol (MCP) support in October 2025. The MCP server itself entered preview in 2026 and, as of this writing, is gated behind Beta feature flags and rolling out to selected customers. It exposes exactly three read-only tools: ask_account, ask_deal, and generate_brief.
Each tool analyzes the calls and emails tied to a CRM entity within a time window and returns an AI-generated, natural-language answer. It does not return raw transcripts, message bodies, or activity lists, and it performs no writes. Private calls are excluded from every result. Because the responses are synthesized, they are probabilistic and are not meant for exact numerical reporting.
Authentication is Gong OAuth with the authorization code flow and PKCE, scoped per user as "Personal Access." Details are in Gong's official MCP server documentation, and Scalekit wraps this vendor server in its Gong MCP connector docs.
The Gong v2 REST API is the everything surface. It exposes raw call metadata and extensive call detail, speaker-attributed transcripts, AI content such as key points and highlights, interaction and activity stats, coaching, scorecards, trackers, users, generic CRM objects, Gong Engage flows and tasks, meeting scheduling, call upload, and audit logs.
Authentication is HTTP Basic Auth with an Access Key and Access Key Secret, or OAuth 2.0 for partner integrations. The base host is https://api.gong.io/v2, and for OAuth apps the customer base host varies per tenant. What each token can reach is governed by granular scopes such as api:calls:read:transcript and api:stats:interaction.
The surface is broad enough that Scalekit's API-based Gong connector ships 49 prebuilt tools over it. See Gong's official API documentation for the full object model, and the Scalekit Gong connector docs for the tool list.
This is where the two paths stop overlapping. MCP synthesizes; the API supplies. The table names the split precisely, then the prose explains where it hurts.
The MCP server is purpose-built for one job: answer a human-style question about an account or deal, grounded in Gong activity. For a deal review copilot or a QBR prep assistant, that is the fastest path you will find.
The moment your agent needs a number, a transcript, or an action, MCP stops. There is no ask_deal variant that returns the exact talk ratio, no tool that lists yesterday's calls, and nothing that writes a note or enrolls a prospect. Those live only on the API. Two more constraints matter in production: MCP requires an active CRM integration, since accounts and deals must be synced from your CRM for the tools to find activity, and it is still Beta-gated, so not every org can turn it on yet.
The reverse gap is real too. Getting a synthesized "what are the risks on this deal" answer from the raw API means fetching transcripts with gong_calls_transcript_get, then running your own summarization and prompt engineering.
Gong's MCP server does that synthesis for you, behind one tool call. If natural-language insight is the product, MCP saves you a retrieval-and-summarize pipeline you would otherwise own and maintain.
Auth is where Gong departs from the usual MCP vs API pattern. Read this section carefully, because the headless recommendation flips relative to tools like Salesforce.
The MCP server uses Gong OAuth with the authorization code flow and PKCE, and it is strictly per-user. Each person authorizes with their own Gong login, and the agent can only reach the data that user is already permitted to see. Private calls stay excluded.
There is no static credential and no API key option on this path. Dynamic Client Registration is not available either; a Gong Technical Administrator has to create the MCP integration first. Every user who connects goes through their own browser-based consent.
The direct API's native credential is an Access Key plus Secret, sent as HTTP Basic Auth. That credential is workspace-scoped, not user-scoped; treat it as a high-privilege secret. Gong also supports OAuth 2.0 for partner and Collective integrations, again at the workspace level rather than per individual.
This is the important asymmetry. The API path can authenticate with a single workspace credential and no interactive flow. The MCP path cannot; it always requires a per-user consent.
For most tools, MCP is the interactive path and the API carries the headless, background-job path. Gong keeps the interactive half of that, but flips the headless half.
If your agent runs on a schedule with no user present — a nightly pipeline scan, a bulk transcript export, a scorecard rollup — the workspace-scoped API credential is the clean fit. Gong MCP has no equivalent, because it is per-user by design. So the deterministic, background Gong agent belongs on the API, and it belongs there for the opposite reason it does with Salesforce.
Neither path is free of operational surface. What differs is who owns the schema, the lifecycle, and the failure modes. Here is the split.
Gong hosts and maintains the server, the three tool schemas, and the synthesis engine. You own the per-user OAuth tokens: storage, refresh, and revocation for every rep who connects.
You also own the preconditions. If the CRM sync lapses, tools return empty. If your org is not yet enrolled in the Beta, the MCP scope will not appear in the integration settings at all. Those are dependencies to plan around, not code you write.
You own more. Beyond token lifecycle, you own schema handling across dozens of endpoints, cursor pagination, error handling, and retry logic. Endpoint behavior is yours to track when Gong revises the v2 surface.
The upside is control. You pick exactly which calls, transcripts, or stats to fetch, and you decide how to shape them for the model, rather than accepting a synthesized answer as-is.
Gong enforces a hard limit of 3 API calls per second and 10,000 calls per day per company by default; exceeding either returns HTTP 429 with a Retry-After header. You can request higher limits from Gong, but assume the defaults.
Two more practical notes: list endpoints page with a cursor at a maximum of 100 records, and cursors are time-limited, so do not cache them across runs. The /v2/calls endpoint requires a fromDateTime and caps each request at a 90-day window. Agentic workflows issue many sequential calls per user action, so the daily quota arrives faster than a traditional integration. For patterns here, see API access patterns for AI agents.
The decision is genuinely use-case dependent. Match the path to what your agent produces, not to a general preference for one protocol.
Set capability aside for a moment. Both paths hand you an authentication problem that neither one finishes for you, and in a multi-tenant B2B agent it is the same problem on both sides.
Gong MCP gives you correct per-user identity: the agent inherits exactly what the authorizing rep can see. That is the right security posture, and it is what an enterprise auditor wants. But Gong enforces identity; it does not run the credential lifecycle for you.
In a multi-tenant agent serving 40 reps across 8 orgs, MCP's per-user model means 40 OAuth tokens to store encrypted, refresh proactively, and revoke on offboarding. The API path can collapse that to workspace credentials, but a shared workspace access key then flattens per-user attribution: every action logs as the same high-privilege identity. The token type differs across the two paths; the infrastructure you owe does not. For the wider pattern, see how tool calling auth changes from single-tenant to multi-tenant and access control for multi-tenant AI agents.
Scalekit's Gong connectors handle the OAuth flow, token storage, and refresh for both paths, so the MCP vs API decision does not change your auth infrastructure. On the API path, Scalekit authenticates through a Gong OAuth integration and layers per-user connected accounts on top; each rep's calls resolve to their own delegated authorization rather than a shared workspace key, which restores the attribution a raw access key loses. Token refresh across long-running runs is handled for you — a problem detailed in how to handle token refresh for AI agents.
The point of the connectors is that both paths use one tool-calling interface. You authorize a user once, discover the tools their connected account is allowed to call, then execute. The examples below use Python; the same shapes exist in the AgentKit Python SDK and the Node SDK.
Create two connections in the Scalekit dashboard, gong for the API path and gongmcp for the MCP path, then authorize a user. Scalekit stores and refreshes the tokens; no Gong credential ever enters your agent process.
Before your agent reasons over Gong tools, load only the ones this rep's connected account is authorized to call. The Scalekit LangChain adapter builds that list per identifier; under the hood it calls list_scoped_tools, so the agent never sees a flat catalog of everything the connector could theoretically do.
The returned tools are already bound to this rep's connected account. Change identifier and the same graph runs for the next rep, scoped to their access, with no other code change.
When you want to call a specific tool directly, execute_tool takes the tool name, the connection, and the user identifier. The API path returns raw data you shape yourself; the MCP path returns a synthesized answer.
For a full working build that reads Gong calls, scores deal risk, and posts a brief to Slack, follow the deal intelligence agent tutorial or the Claude SDK variant, the deal-risk intelligence agent.
Two Scalekit capabilities matter most for Gong agents specifically: attributable audit logs for every downstream tool call, and Virtual MCP for agents that span more than one tool or tenant.
A shared Gong credential looks fine in a demo. In production, every call read and every note write logs as one service account, and rep-level attribution collapses. Scalekit resolves the credential of the actual rep who triggered the agent, so each Gong action is tied to a real identity.
That attribution is what makes the run auditable after the fact. When a security reviewer asks under whose authority the agent read a given call, the answer is a person, not a bot. See agent tool observability and audit trails for agent auth for the full model.
Most Gong agents are not Gong-only. A deal desk agent also touches a CRM and Slack, and it serves many reps. Scalekit's Virtual MCP Servers give each agent a scoped, per-user MCP endpoint that declares exactly which tools it can see and whose credentials it acts with, with no MCP server to deploy or maintain.
One server definition serves all users; before each run, a short-lived session token is minted scoped to that user's connected accounts. The agent sees only the tools you explicitly allow, not everything each connector exposes.
For user-facing insight agents — the deal copilot, the account researcher, the QBR prep assistant — start on Gong MCP. Three tools give you synthesized answers with per-user permissions already enforced, and you skip building a retrieval pipeline.
For everything that needs raw data, exact numbers, writes, or headless execution, build on the v2 API. That is where transcripts, stats, coaching, Gong Engage, meetings, and audit logs live, and where a workspace-scoped credential lets a background job run without a user in the loop. Most production Gong agents will use both surfaces, and the credential management problem is identical either way. That part needs production-grade infrastructure regardless of which path you are on.
If your agent answers questions, use MCP. If your agent moves data or runs unattended, use the API. Solve credentials once, at the infrastructure layer, so the choice stays a capability decision and never becomes an auth rewrite. Compare with the sibling posts on Salesforce MCP vs Salesforce API, Salesloft MCP vs Salesloft API, and Attio MCP vs Attio API.
Browse the Scalekit Gong connector, read the Gong connector docs and Gong MCP connector docs, or scan the full connector library. Pricing for agent tool calling is on the AgentKit pricing page.
Building a Gong agent and want a second pair of eyes on the auth model? Join the Scalekit Slack community, or use the Talk to us page for immediate help.
