Your agent needs ZoomInfo. It has to size a territory, surface accounts showing intent, map the buying committee, and enrich the three contacts worth emailing. ZoomInfo now ships a hosted MCP server at mcp.zoominfo.com/mcp alongside a rebuilt REST platform at docs.zoominfo.com, and both hit the same backend, the same entitlements, and the same credit pool. The difference is not data coverage. It is who picks the tool, whether the surface can write, and what your agent owes the credential layer afterward. Here is how to pick.
These are two front doors onto one backend. ZoomInfo says so directly: the MCP server, the CLI, and the REST API respect the same entitlements and draw on the same credits. What separates them is the calling convention and the write surface.
ZoomInfo runs a hosted, remote MCP server over Streamable HTTP at a single endpoint, https://mcp.zoominfo.com/mcp. Every client connects to the same URL. Authentication runs through ZoomInfo's MCP Gateway, which enforces entitlements per call and keeps the server stateless: each tool call is scoped to the authenticated user rather than to a session.
The tool catalog splits in two. Direct tools return structured records: lookup, company and contact search, enrichment, lookalikes, intent, scoops, news, audiences, and engagements. Context agents run a sub-agent layer that blends ZoomInfo's third-party data with your organization's first-party CRM and conversation history, then returns a synthesized briefing. Details live on the ZoomInfo MCP product page and the ZoomInfo MCP tool reference.
The REST platform at docs.zoominfo.com exposes search, enrich, lookup, usage, signals, GTM Studio audiences, marketing audiences, Agent Teams, GTM configuration objects, and webhooks and events. Applications come in two shapes registered in the ZoomInfo Developer Portal. Standard apps are for your own internal or single-tenant use and support both OAuth flows. Partner apps are built by approved partners for distribution across customer organizations and must use Authorization Code with PKCE.
Older Enterprise API integrations do not use OAuth at all. They exchange either a username and password, or a client ID and RSA private key, for a JWT that is valid for one hour, using ZoomInfo's published Python PKI auth client. There is no refresh token in that model, so long-running pipelines have to re-authenticate proactively. If your agent inherits one of these credentials, treat it as a migration item, not a design choice.
Four dimensions decide this for a production agent: what each surface can do, what auth it accepts, what identity it acts under, and what you own operationally once it ships.
The MCP surface is built for research. The API surface is built for research plus everything that happens after the research: writing lists, running jobs, and reacting to change.
ZoomInfo's own security documentation states that all MCP tools are currently read-only and that no data is written back through the MCP connection. The tool catalog is one step ahead of that statement: update_gtm_context writes GTM configuration, and ZoomInfo's first-session prompt tells users to call it. Treat the surface as read-oriented with a single configuration write.
That distinction matters for scoping. Every other mutation your agent might want — creating an audience from a search result, upserting 500 rows, kicking off an enrichment job, uploading a marketing audience — lives only on the API. If the agent's output is a list somebody else consumes, the API is not optional.
This is where ZoomInfo diverges from most vendor MCP servers. Its MCP server supports two OAuth flows, not one. User sign-in uses Authorization Code with PKCE, where each person authenticates with their own ZoomInfo login. Service accounts use Client Credentials, where the app authenticates once as itself and no individual signs in.
The REST platform accepts the same two flows through the Developer Portal. So the usual headless blocker does not apply here: a background agent can hold a ZoomInfo MCP credential without a browser in the loop. For a deeper look at tool calling auth production problems and patterns, the tradeoffs between these flows apply across most vendor connectors.
Auth method is settled. Provisioning is not, and it is where first connections fail.
Connecting an AI client to the hosted MCP works on any ZoomInfo subscription. Registering your own app for API or MCP use requires a DevPortal subscription assigned by a ZoomInfo admin. Per-user MCP connectivity is then governed by an API Access toggle under Admin Portal, Users, User Management, and there is no organization-wide kill switch; access is managed one user at a time. Admin-only seats have no data access by design and cannot connect through any path.
Auth choice is not only a security posture on this connector. It changes what answers exist.
ZoomInfo assembles per-user context on the server side from the signed-in user's models. "Research the accounts I'm meeting with this week" resolves against that rep's calendar. "Show me my renewals and what those accounts said on recent calls" resolves against their book of business and their call recordings. Under Client Credentials there is no signed-in user, so those requests either fail or degrade to a generic company-level answer. ZoomInfo recommends user sign-in wherever it is practical for exactly this reason.
The pattern here is the one Scalekit keeps running into across connectors: what the user can't do, the agent can't do, and what the user alone can see, a shared identity can't reach. This is the core challenge of moving tool calling auth from single-tenant to multi-tenant environments.
Every API request is evaluated against per-second, per-hour, and per-day windows simultaneously, and any exhausted window returns 429. Rejected requests do not consume quota, and X-RateLimit-Rejected-Bucket tells you which window to back off from.
An exhausted hourly bucket can return a Retry-After in the hundreds of seconds, so a fixed one-second retry loop will not recover.
This is the part agent builders underestimate. Search, lookup, and find-similar consume no credits. Enrichment draws bulk data credits, and the context agents draw AI action credits.
MCP specifically requires bulk data credits rather than recurring monthly credits, which is the most common cause of a failed first connection. Records Under Management keeps the math honest across surfaces: once a record is enriched anywhere in the platform, it stays under management for 12 months at the organization level and is not charged again in that window. Enrich an account through the API on Monday and read it in Claude on Friday, and you paid once.
On the MCP path, ZoomInfo owns hosting, gateway auth, entitlement enforcement, and tool schema updates. New tools appear automatically at the start of each session, with no redeploy on your side. You own per-user token storage, refresh, revocation, and the credit budget the model spends on your behalf.
On the API path you own all of that plus request construction, pagination, Retry-After handling per rejected bucket, and adapter code per surface. What you get back is determinism. ZoomInfo's own comparison is blunt about it: with MCP, output varies with how the model reasons; with REST, the schema is fixed. Understanding who holds the token across agent tool-calling patterns is essential before committing to either path.
For a nightly enrichment pipeline where an unexpected tool substitution is an incident, that difference decides the architecture on its own. There is a token cost attached to it as well.
ZoomInfo's GTM Bench v1 benchmark, run across ten B2B research tasks, put the MCP arm at 1.48M work tokens and $15.80, against 460K tokens and $10.12 for its own CLI arm on identical work. MCP finished fastest at 32 minutes and posted the highest verified-email coverage at 94 percent. It is vendor-published and measures coverage rather than correctness, so read it as a signal on efficiency and fill rate, not precision. For context, MCP can be up to 32× more expensive than CLI — a tradeoff worth understanding before you commit to the transport.
Use ZoomInfo MCP when:
Use the ZoomInfo API when:
The decision above changes what your agent can do. It does not change what you have to build underneath it. Scalekit's ZoomInfo connector sits on the OAuth path and gives both shapes the same credential layer.
Some vendors get two Scalekit connectors, one for the REST API and one wrapping the vendor's hosted MCP server. ZoomInfo currently gets one: the Scalekit ZoomInfo connector, authenticated with OAuth 2.0 against a ZoomInfo Developer Portal app, covering the full REST surface including the audience, Agent Team, and GTM configuration writes that the hosted MCP does not expose.
If you want that surface delivered as MCP rather than as native tool objects, you do not switch connectors. You compose a Virtual MCP server over it and get a per-user MCP endpoint carrying exactly the tools you allow. The capability set stays a superset of the hosted server's; the transport becomes your choice rather than the vendor's.
Create an app at developer.zoominfo.com, set the redirect URI to your Scalekit redirect URI, and copy the client ID and secret. In the Scalekit dashboard, go to AgentKit, then Connections, then Create Connection, search for ZoomInfo, and paste both values.
Note the connection name shown on that screen. It is the string you pass as connection_name in code, and a mismatch here is the single most common integration error.
Install the SDK and resolve the connected account. If the rep has not authorized yet, hand them a magic link.
Before any tool object reaches the model, understand what this call is doing. The agent is not loading the ZoomInfo connector catalog. It is loading the tools this rep's connected account is authorized to call, filtered further to the ones this agent role needs. That distinction is what separates a per-user agent from a shared-credential agent.
The filter matters more on ZoomInfo than on most connectors, because the tool surface is also a spend surface. zoominfo_search_companies and zoominfo_lookup_data are free. zoominfo_enrich_contacts bills per matched record. Handing the model both without constraint invites it to enrich when it should have searched.
If your stack is Node, listScopedTools returns schemas in Anthropic's native shape, so there is no conversion step between discovery and the tool-use loop.
For multi-tool and multi-tenant agents, the native tool objects above stop being the right delivery shape. You want one endpoint per agent role, carrying ZoomInfo alongside your CRM and your Slack connector, resolving to a different identity on every run.
Define the config once, then call ensure_instance per user. It is idempotent, so call it on every session.
Before the run, confirm the rep has authorized everything the config needs, and surface a fresh link for anything that has lapsed.
The two properties this buys you are the ones the hosted ZoomInfo server cannot give you. The agent sees only the tools you explicitly allow, not everything the connector exposes, so a research agent has no path to zoominfo_delete_audience no matter what the prompt says. And one server definition serves every tenant, with identity supplied at runtime rather than baked into a per-customer deployment.
The gap that shows up in enterprise procurement is not "did the call succeed." It is "which rep authorized this enrichment, under which grant, and was that grant still valid when it ran."
Every execute_tool call through Scalekit lands in one audit log keyed to the authorizing user, alongside the connection ID, scope grants, token lifecycle events, and revocation state for that OAuth grant. For a connector that bills per record and touches contact data subject to GDPR, that record is the difference between a three-week investigation and a query. This is exactly why audit trails for agent auth in B2B SaaS have moved from nice-to-have to procurement requirement. Standard application logs capture the API call at the end of the chain and nothing before it.
Pick MCP or pick REST. Either way, every rep using your agent has their own ZoomInfo credential.
Forty reps across eight customer orgs is forty OAuth grants to store encrypted, refresh before expiry, and revoke on offboarding. Neither ZoomInfo path gives you a vault, rotation logic, or a revocation flow; ZoomInfo enforces identity and entitlements, it does not manage the credential lifecycle for you. The failure mode is familiar: the Okta account gets disabled, and a ZoomInfo grant issued eight months ago keeps working. The agent does not decide to keep using it. It just does. Understanding how to handle token refresh for AI agents is the first operational problem every production agent team faces.
Scalekit's ZoomInfo connector handles the OAuth flow, per-tenant encrypted token storage, and automatic refresh for both paths, so the MCP vs API decision does not change your auth infrastructure. The credential is resolved server-side at request time and never enters your agent runtime, your logs, or the LLM context.
If a rep is present and the question contains the word "my," build on ZoomInfo MCP. The per-user context resolution and the context agents are the reason that surface exists, and neither has a clean REST equivalent.
If the agent writes a list, runs a job, subscribes to an event, or executes on a schedule at volume, build on the API. The read-oriented tool surface is not a temporary gap; it reflects what ZoomInfo designed the MCP server to do.
Most production GTM agents end up running both, and the credit pool does not care which one spends it. What both paths leave on your side of the line is the same: N credentials, N lifecycles, and an audit trail somebody in procurement will eventually ask to see.
Browse the Scalekit ZoomInfo connector or read the connector docs for the full tool list.
Building something on ZoomInfo and want a second opinion on the auth model? Join the Scalekit Slack community or talk to us for immediate help.
