ZoomInfo scores 86.6 on the Kin Score, exemplar band, down 1.2 from 87.8 at the last run. Its Agent Readiness is 65.8, agent-ready, and the rubric records that it would have been agent-native if a gate had not held it back. Five of its six facets sit above 76. The sixth, contract governance, is 31.8, and that number is the most honest thing in the record.
ZoomInfo describes its own API estate as mid-migration. The legacy Enterprise API on api.zoominfo.com is documented as deprecating, while the current GTM API on api.zoominfo.com/gtm ships six published OpenAPI specifications covering data, Copilot, GTM Studio, marketing, agents and platform. The catalog counts that surface two ways: 7 APIs on the published basis, and 42 contracts once those specifications are split into API pages. Both are correct. They are also the shape of a provider whose contracts are being moved from one house to another.
| Facet | Score |
|---|---|
| Operational transparency | 92.1 |
| Access clarity | 92.1 |
| Developer ergonomics | 89.3 |
| Discoverability | 83.3 |
| Contract quality | 76.4 |
| Contract governance | 31.8 |
What carries the score
Access is unusually clear for a data vendor that sells by contract: the record reads freemium with self-serve signup and a try-now path. All 42 contracts score as callable, and none of them is one we derived. There are four first-party auth SDKs on GitHub (Python, Java, Node.js and C#). Transparency is near the top of the scale.
The agent story is first-party
This is where ZoomInfo is ahead of most of the catalog, and where the credit is theirs. It operates a hosted, OAuth-gated MCP server at mcp.zoominfo.com that exposes company and contact search and enrichment, intent, scoops, news, audiences and agentic research. Its description says it publishes 35 agent skills and a first-party CLI that talks to that MCP server rather than to REST. The scoring provenance marks both MCP and skills as first-party. Protected resource metadata is verified, delegated identity is served, and dynamic client registration is lit.
The parts that are dark are the parts that matter when an agent is writing records rather than reading them: idempotency, documented reversibility, a dry-run mode, a well-known catalog and an agent card. The agentic access row (199 operations, 83 acting, 5 human-in-the-loop) is an artifact we derived, so I do not count it in ZoomInfo’s favor.
Two defects on our side
The provider record lists skills: [] even though the rubric’s agent_skills dimension is lit and the description names 35 skills. So the profile page undercounts something the score already credits. The record also carries two MCP server entries, one with a full description and one named only “MCP Server” with an empty description. That second entry looks like a duplicate we should reconcile, not a second server.
Takeaway
Contract governance is what would move the number. That means finishing the migration in the contracts themselves: version and deprecation markers on the legacy Enterprise API, a published sunset date, and one changelog that spans both hosts. After that, idempotency keys on the write operations would turn agent-ready into agent-native. ZoomInfo has already done the hard part on agent access. What is left is bookkeeping.
See the full profile at apis.io/providers/zoominfo/.