{
  "id": "p_h-oRV63CA0h-Znyn",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_h-oRV63CA0h-Znyn",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Say you are the person who has to decide which sales-intelligence provider your team's agents will talk to. You need company and contact search, enrichment, intent signals. You also need to know what you are signing up for before an agent starts writing records into your systems. So you open the APIs.io profile for ZoomInfo and read the number first.\n\nZoomInfo scores 86.6 on the Kin Score, in the exemplar band. That is down 1.2 from 87.8 at the last run. Its Agent Readiness is 65.8, which the catalog labels agent-ready. The rubric also records that it would have been agent-native if a gate had not held it back.\n\nFive of its six facets sit above 76. Operational transparency and access clarity both score 92.1. Developer ergonomics is 89.3, discoverability is 83.3, and contract quality is 76.4. You might stop there. The sixth facet is contract governance, and it scores 31.8.\n\nThe post calls that number the most honest thing in the record, and the reason is ZoomInfo's own description of its estate: it is mid-migration. The legacy Enterprise API on api.zoominfo.com is documented as deprecating. 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 the specifications are split into API pages. Both are correct. Together they describe a provider moving its contracts from one house to another, and a governance score that reflects the move in progress.\n\nWhat carries the score is access. 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 the catalog derived. There are four first-party auth SDKs on GitHub, in Python, Java, Node.js and C#.\n\nThe agent story is where you will spend most of your attention, and the post gives the credit to ZoomInfo. It operates a hosted, OAuth-gated MCP server at mcp.zoominfo.com covering 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 the 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.\n\nNow the part that matters if your agents will write, not just read. Idempotency, documented reversibility, a dry-run mode, a well-known catalog and an agent card are all dark. The catalog also shows an agentic access row of 199 operations, 83 acting and 5 human-in-the-loop. The post says plainly that this row is an artifact the catalog derived, so it does not count it in ZoomInfo's favor, and you should not lean on it either.\n\nThen comes the turn. The post does not only grade the vendor; it lists two defects on the catalog's own side. The provider record shows skills as an empty list 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 fully described and one named only \"MCP Server\" with an empty description. The post says that second entry looks like a duplicate to reconcile, not a second server. You now know to read the profile page with those two flaws in mind.\n\nThe takeaway is practical. Contract governance is what would move the number: version and deprecation markers on the legacy Enterprise API, a published sunset date, and one changelog spanning both hosts. After that, idempotency keys on write operations would turn agent-ready into agent-native.\n\nFor your decision, that means the hard part of agent access is already done and first-party, and the gaps are in migration bookkeeping and write safety. Until idempotency lands, you would keep your agents on reads or put your own guardrails around anything that writes.\n\nRead the original: https://apis.io/2026/10/21/zoominfo-scores-86-6-and-its-weakest-facet-is-the-migration-it-is-in-the-middle-of/",
  "title": "You are picking a sales-data vendor for your agents, and ZoomInfo's record says something honest about itself",
  "topics": [
    "zoominfo",
    "agent-readiness",
    "contract-governance",
    "mcp"
  ],
  "published_at": "2026-10-21T10:56:33.699Z",
  "expires_at": null,
  "policy_version": "2026.09.25-1"
}