Which B2B Data and GTM Vendors Actually Ship an MCP Server? A 59-Vendor Census

Last updated: September 1, 2026

On September 1, 2026 we sent a JSON-RPC initialize request to every MCP endpoint we could find for 59 B2B data, enrichment, sales engagement, CRM and GTM automation vendors, and recorded the literal response from each. 43 of the 59 vendors ship a product MCP server. 37 of those we confirmed on the wire, without an account. One further vendor ships a documentation-search server and nothing else, which takes the any-server count to 44. The category split is stark: every B2B data platform and every CRM we tested ships one, while only 1 of 6 email verification vendors does. The thing almost nobody publishes is what their server can actually do. Only 5 of the 44 disclose a tool count a stranger can verify without credentials.

The full dataset, one row per vendor with the literal probe response, is gtm-mcp-census-2026-09.csv, licensed CC BY 4.0.

What counts as shipping an MCP server in this census?

One rule, stated here so you can apply it to every number below. A vendor counts when it operates an MCP server itself and that server reaches the vendor's own product data. A documentation-search server, which only lets an agent read the vendor's API manual, does not clear that bar: it cannot read your records and it cannot spend a credit. Those are reported separately rather than folded into the product count. Community wrappers on GitHub, npm or Zapier are excluded, because they are third-party code holding your credentials. Servers a vendor documents but we could not reach are counted, and labelled with how they were established.

That gives two totals, and both are printed everywhere they differ: 43 product MCP servers, 44 servers of any kind, out of 59 vendors. One vendor in the census, Smartlead, is the entire difference between the two.

Which B2B data and GTM vendors actually ship an MCP server?

43 of the 59 vendors we tested on September 1, 2026 ship a product server. 37 of those were confirmed directly on the wire: Apollo, ZoomInfo, Clay, Cognism, Lusha, Seamless.AI, LeadIQ, RocketReach, Coresignal, Crustdata, Explorium, Cleanlist, Hunter, Dropcontact, Snov.io, Findymail, Anymail Finder, Icypeas, LeadMagic, FullEnrich, Bouncer, Outreach, Salesloft, Instantly, lemlist, Reply.io, Amplemarket, HubSpot, Attio, Close, Gong, Common Room, Unify, Warmly, Default, G2 and Vector. Six more ship a server we could not reach with a generic probe because the endpoint is tenant-scoped or unpublished: Pipedrive, Salesforce, Zoho CRM, Chili Piper, Hightouch and RB2B. Smartlead is the 38th wire confirmation and the 44th server, and it is a documentation-search server, so it sits outside the 43 under the rule above. 14 vendors had no server we could find, and 1 was inconsistent.

How do you prove an MCP server exists without an account?

You send it a real MCP handshake and read what comes back. We POSTed a JSON-RPC initialize request with Accept: application/json, text/event-stream and recorded the status, headers and body. A 401 carrying an auth challenge proves a live server, because something is there deciding you are not allowed in. A 404, a DNS failure or a connection refusal proves absence at that path. A 200 that returns HTML is a marketing page or a single-page-app catch-all, which we saw at Prospeo, Bettercontact, Clearout and Lusha's knowledge hub. A 200 carrying a valid initialize result is an open server, which is how we confirmed Coresignal and Smartlead.

Why is a 401 alone not enough proof?

Because plenty of API hosts return 401 to everything. This is the trap that makes casual MCP lists wrong. We ran a control probe against every suspicious host: the same initialize request sent to a nonsense path such as /zzcensuscontrol2026. On api.zoominfo.com, api.surfe.com, api.clearout.io, api.gong.io, api.pipedrive.com and api.outreach.io, the nonsense path returned the identical 401. That 401 is a blanket auth wall and proves nothing about MCP. Outreach passed the control anyway: api.outreach.io/mcp emits a WWW-Authenticate header naming an OAuth resource document, and the nonsense path emits no such header. The CSV records the control outcome in probe_evidence for every row where it decided the verdict, which is how Pipedrive, Clearout, Surfe and ZeroBounce ended up where they did.

What is the second layer of proof?

RFC 9728, OAuth 2.0 Protected Resource Metadata. When an MCP server challenges you, it points at a .well-known/oauth-protected-resource document, and that document names the exact resource URL it protects. We fetched those documents for every 401 we found. Apollo's names https://mcp.apollo.io/mcp. Clay's names https://api.clay.com/v3/mcp. Cognism's names https://api.cognism.com/api/connect/mcp, which is worth flagging because several secondary write-ups claim Cognism has no MCP server. The wire disagrees with them. This second layer is machine-checkable, it costs nothing, and it is why we consider these 38 wire results confirmations rather than sightings.

Which categories ship an MCP server and which do not?

The split is the most useful finding in the census. B2B data platforms: 7 of 7. CRM: 6 of 6. GTM signals: 5 of 5. Revenue intelligence: 1 of 1. Sales engagement: 6 of 7 on product servers, or 7 of 7 if you count Smartlead's documentation server. Then it falls off a cliff. Email verification: 1 of 6, with only Bouncer shipping one, and nothing found for ZeroBounce, Emailable, NeverBounce, MillionVerifier or Clearout. Enrichment: 4 of 10, with Cleanlist, Dropcontact, LeadMagic and FullEnrich shipping, nothing found for Clearbit, Datagma, Kaspr, Surfe or Bettercontact, and Ocean.io unclear. The remainder: email finding 5 of 6, data APIs 3 of 4, GTM automation 5 of 6, intent data 0 of 1. The eleven categories sum to 59. If your agent needs to verify an email address, there is a real chance you are writing a REST wrapper yourself.

Does Cleanlist's MCP server have any claim to being first or uncontested?

No, and this census is the proof. We got 38 wire confirmations that morning and ours was one of them, so 37 belong to other vendors, including every direct competitor we tested. Our server answered the same probe the same way, a 401 pointing at an OAuth resource document, which puts it in the same bucket as Apollo, Clay and ZoomInfo rather than ahead of them. We also lose on several access dimensions covered below. Anyone telling you a B2B data MCP server is novel in September 2026 is describing 2025. The interesting question stopped being who has one and became what it lets an agent do and who is allowed to use it.

Where does Cleanlist lose in this census?

On access, on transparency and on assurances, and it is worth being specific. Cleanlist's MCP server is in beta, it is restricted to self-serve accounts only, and AppSumo licences are excluded from the beta entirely. Hunter's, by contrast, is documented as "Included in all Hunter plans. No extra cost", and works on free accounts. Our connector exposed 14 tools in an authenticated session on September 1, 2026, while our own product page claims 30 or more across the full server, so the two numbers disagree and the smaller one is what an agent actually sees. That 14 came from credentials we already hold, so it is not comparable to the counts other vendors publish and it is excluded from the public-count figure below. There is no published npm package: registry.npmjs.org returns 404 for @cleanlist-ai/mcp. There are no v2 webhooks, no uptime SLA and no SOC 2 report.

Which vendor has the most open MCP access?

Hunter, on the evidence we could verify. Its documentation at hunter.io/mcp states the MCP server is included in all Hunter plans at no extra cost and works with free accounts, with existing request limits and credits applying. Apollo publishes a comparable line at apollo.io/product/mcp: "Any Apollo plan qualifies, including free." ZoomInfo includes it with every subscription with no separate SKU, and Pipedrive makes it available on all plans. The differentiator here is access rather than existence. On this specific measure Cleanlist ranks below Hunter, Apollo, ZoomInfo and Pipedrive, because our beta is gated to self-serve accounts and excludes AppSumo licences outright.

How many vendors tell you what their MCP server can do before you sign in?

Almost none. Only 5 of the 44 vendors have a tool count a stranger can verify without credentials: Reply.io at 70, Lusha at 22, Common Room at 6, Coresignal at 3 and Smartlead at 3. Smartlead's three are documentation-search tools, so on the 43 product servers the figure is 4. A sixth vendor, Zoho CRM, publishes a count of 4 pre-built CRM servers rather than a tool count, which answers a different question. Cleanlist's 14 is not in this list: it came from an authenticated session, and every other count here came from public documentation or an unauthenticated tools/list, so including ours would compare two different measurements. For the other 39 the tool list sits behind the auth wall and the marketing page describes capabilities in prose. Only 10 of the 44 publish a plan gate, so 34 vendors do not tell you in public whether their MCP server is on your plan. If you are running a procurement review, budget for the fact that most of this category will not answer "what can it do and can we use it" until after you have signed in.

What can these MCP servers actually do: read data or spend money?

This is the distinction that matters and almost nobody draws it. Apollo's OAuth resource document publishes 70 scopes, and the list includes emailer_messages_send_now, phone_call_write, email_account_purchase_create and domain_purchase_create. An authorised agent on that server can send email, log calls, and buy domains and email accounts. Our CSV truncates that scope list to its first three entries, so we publish no count of how many of the 70 can change or spend something. The document is public: follow the WWW-Authenticate header at https://mcp.apollo.io/mcp and count them yourself. Reply.io documents 70 tools and annotates them itself: 31 carry readOnlyHint and 39 carry destructiveHint. Coresignal, by contrast, exposes 3 tools that only read. These are radically different risk profiles wearing the same three-letter label, and a security review that treats "has an MCP server" as one category is going to approve the wrong thing.

Which servers separate read permissions from write permissions?

24 of the live servers publish a non-empty OAuth scope list. Only 7 of those 24 separate read from write: Apollo, Crustdata, Gong, Amplemarket, Close, Vector and Hunter. Close goes furthest of anyone we saw, publishing three tiers, mcp.read, mcp.write_safe and mcp.write_destructive, so a client can request the ability to make safe changes without the ability to delete. Gong and Amplemarket use a clean mcp:read and mcp:write pair. The other 17 do not separate read from write, and they get there two ways. Ten publish a single all-or-nothing scope such as mcp, full_access, mcp.all or prospects.all. The remaining seven publish several scopes, but the extra entries are OpenID Connect identity scopes such as openid, profile, email and offline_access, or a second blanket scope. ZoomInfo publishes seven scopes and none of them narrows what an agent may change. Cleanlist publishes no scope list in its resource document at all, which is a gap on our side rather than a feature.

Does any vendor require a cost estimate before an agent spends money?

We looked hard and found no second example of a required, signed, per-call quote. Several vendors ship spend controls of a different shape. Clay lets workspace admins set default and per-user credit budgets from Settings, then monitor usage, which is an administrative cap rather than a per-call gate. Lusha exposes an account_usage tool so an agent can read its balance, and documents that failed lookups are not charged. ZoomInfo and Apollo both make search free and charge on results. Close separates destructive writes at the scope layer. Those are real controls. None of them is the same mechanism as a quote the server has to validate before it will run the job.

What does Cleanlist's estimate_cost actually do?

estimate_cost returns a signed quote before any paid operation: a quote_id, an expires_at, the estimated cost, the available credit balance, and a boolean for whether the balance is sufficient. The quote is HMAC-signed with a five-minute TTL and a small drift tolerance of 10 percent, and the server recomputes the real cost at execution and rejects the call if it exceeds what was quoted or if the quote has expired. It is required before bulk enrichment, smart agents, CRM and sequencer sync, and imports. Reads stay free: search is 0 credits, as are list reads, status polls, exports, whoami and balance. The publicly checkable parts are documented at docs.cleanlist.ai/mcp-api/credits.

Which email verification vendors ship an MCP server?

One, on our evidence. Bouncer answers at https://api.usebouncer.com/mcp with a 401 and an OAuth resource document naming that exact path and a bouncer scope. We found nothing for ZeroBounce (mcp.zerobounce.net returns a generic 403 "Access Restricted" page, and the identical page on a nonsense control path, so it is a block page and not an auth challenge), Emailable, NeverBounce, MillionVerifier or Clearout, each tested across six endpoint patterns. Hunter, which does verification alongside email finding, ships one and includes it on every plan. If your agent workflow ends in a verification step, that step is currently the most likely one to need a REST wrapper.

Do the waterfall enrichment providers ship MCP servers?

Mostly yes, and it happened fast. Cleanlist buys data from 11 of the vendors in this census, and 7 of the 11 ship a live server: Lusha (mcp.lusha.com/mcp), Crustdata (mcp.crustdata.com/mcp), Hunter (mcp.hunter.io/mcp), Findymail (mcp.findymail.com/mcp), Anymail Finder (api.anymailfinder.com/mcp), Icypeas (mcp.icypeas.com/mcp) and LeadMagic (mcp.leadmagic.io/mcp). We found nothing for Prospeo, Datagma, ZeroBounce or Emailable. Of the 7, 3 are OAuth-only (Crustdata, Findymail, LeadMagic) and 4 also accept an API key (Lusha, Hunter, Anymail Finder, Icypeas), which matters if you are wiring a headless agent rather than a chat client, because an OAuth-only server expects a browser somewhere in the loop. Our waterfall reaches 25+ providers in total, so this is a slice of it rather than the whole list, and every vendor here is measured on the same rule as every other row.

What is a documentation MCP server, and why does the distinction matter?

Because two vendors in this census ship one and it is easy to miscount as a product integration. Smartlead's server at api.smartlead.ai/mcp answered our initialize with no credentials at all, and tools/list returned exactly three tools: search_smart_lead_api, query_docs_filesystem_smart_lead_api and submit_feedback. Its own instructions describe it as providing "search and retrieval tools for the SmartLead API site". Hightouch documents a similar docs endpoint alongside its real product MCP, and its row records the product server, so Smartlead is the only vendor whose classification turns on this rule. These servers help an agent read the manual. They do not touch your data, they cannot spend a credit, and counting them as product MCP servers overstates the category by a meaningful margin.

Which vendors ship no MCP server at all?

14 of the 59, after six endpoint patterns each plus a documentation search: People Data Labs, Clearbit, Bombora, ZeroBounce, Emailable, NeverBounce, MillionVerifier, Clearout, Kaspr, Surfe, Prospeo, Datagma, Bettercontact and Census (Fivetran). Two deserve context. Clearbit's absence is structural: standalone Clearbit was retired into HubSpot Breeze Intelligence after the acquisition, and HubSpot's own server is live. People Data Labs has several community-built wrappers on GitHub and npm, but no vendor-operated server, which is the line this census draws. A community wrapper is somebody else's code holding your API key.

Why did conventional endpoint patterns miss real servers?

They missed several, and this is the single most reproducible mistake in this kind of research. Every example below is checkable in the endpoint_probed column. Reply.io serves its MCP server at the bare root, https://mcp.reply.io/, so our /mcp path returned 404 while the root returned a proper 401. Cleanlist's own server lives at /v1/mcp, and mcp.cleanlist.ai/mcp returns "Cannot POST /mcp". Warmly is at opps-api.getwarmly.com/api/mcp, on a hostname no pattern would guess. Common Room is on a .io domain when our vendor list had .com. Cognism is at /api/connect/mcp, Clay at /v3/mcp and HubSpot at mcp.hubspot.com/anthropic. A negative result from four guessed paths is weak evidence, which is exactly why every negative here also got a documentation check.

What are the limitations of this census?

Several, and they are real. This is one snapshot on one morning, September 1, 2026, from a single machine on a North American network. MCP endpoints change, and Ocean.io demonstrated it inside our own run: one probe of api.ocean.io/mcp returned a valid JSON-RPC error over text/event-stream, and four subsequent probes returned "404 page not found", so we classify it unclear rather than guess. Absence of evidence is not proof of absence: we tried six endpoint patterns per vendor plus a docs search, and a vendor could publish an endpoint we did not think of. Most tool counts and every plan gate come from vendor documentation rather than from inspection, because only 2 of the 44 servers, Coresignal and Smartlead, answered tools/list without credentials. The Cleanlist count of 14 came from an authenticated session we already had, which is an advantage we have over our own subjects, so it is reported on its own and kept out of the public-count figure. The docs-only rule moves numbers, and reasonable people would draw it elsewhere: fold Smartlead back in and the totals read 44 of 59 and 75 percent instead of 43 of 59 and 73 percent. We hold no paid account with any other vendor here. And Cleanlist is a vendor in its own census, which is a conflict readers should weigh: the raw responses are in the CSV so you can check ours as easily as anyone's.

How can you reproduce this census yourself?

Every confirmation in it is a single request. Send this to any endpoint in the CSV and read the reply:

curl -sD- -X POST https://mcp.hunter.io/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
       "protocolVersion":"2025-06-18","capabilities":{},
       "clientInfo":{"name":"census","version":"1.0"}}}'

Then send the same request to a nonsense path on the same host. If both return the identical 401, you have found an auth wall and not a server. If only the real path emits a WWW-Authenticate header, follow it to the .well-known/oauth-protected-resource document and check that the resource field names the endpoint you probed. That is the whole method.

Three things to do with this census

Three things. First, stop asking vendors whether they have an MCP server, because 73 percent of this category ships one. Ask which tools it exposes and what each one can spend, and treat a refusal to answer in public as data. Second, check the plan gate before you build a workflow on it, since 34 of the 44 vendors with a server do not publish theirs and a beta or an enterprise tier can vanish under you. Cleanlist's is beta and self-serve only, so plan accordingly. Third, before you let an agent loose on a server with domain_purchase_create in its scope list, decide who approves spend and how that approval is enforced.

What this census got wrong before we published it

An internal fact-check recomputed every figure here from the dataset before this page went live, and it found five problems. All five are fixed above. The record of what changed:

• The tool-count sentence contradicted the limitations section. The draft said 6 of 45 vendors publish a tool count "a stranger can verify" and listed Cleanlist's 14 among them, while the limitations section said that 14 came from an authenticated session. Every other count in the list came from public documentation or an unauthenticated tools/list. The corrected figure is 5 of 44, and Cleanlist's 14 is reported on its own. This does not change the point the section makes, which is that almost nobody publishes one.
• The headline counted a documentation server the page argued against counting. Smartlead's server searches SmartLead's API manual. It holds no customer data and cannot spend a credit, and the draft said so, then counted it in the 45, in the 39 wire confirmations, in "sales engagement 7 of 7", in the 6 published tool counts and in "75 percent of this category". The product-server figures are 43 of 59, 37 wire-confirmed, sales engagement 6 of 7, 73 percent. Both bases are now printed and the inclusion rule is stated at the top instead of buried two thirds of the way down.
• "A single all-or-nothing scope" was wrong for 7 of the 17. ZoomInfo publishes 7 scopes, Common Room 4, Dropcontact 3, Attio 3, LeadIQ 2, G2 2 and Reply.io 2. None of them separates read from write, which is the real finding, so the claim is now about the read/write split rather than about list length.
• Four figures were not recomputable from the published dataset. "291 candidate endpoints", "354 probe requests to 310 distinct URLs", "19 control probes" and "34 of Apollo's 70 scopes are action-shaped" all came from a probe log we did not publish, and "action-shaped" was never defined. They are removed rather than asserted. The scope point stands on the four named write scopes, which anyone can check in Apollo's public resource document.
• The CSV had an undocumented comment preamble. Four # lines and a blank line sit above the header, which breaks a naive read_csv. The layout is now documented in the methodology and in the file itself.

Two counts also moved for a reason unrelated to those five. The census as probed covered 60 vendors and the published dataset carries 59, for the reason under Exclusions below. Every "N of M" on this page was recomputed against the 59 rows in the file rather than adjusted by hand.

Methodology

• What we tested: 59 vendors across B2B data platforms, data APIs, enrichment, email finding, email verification, sales engagement, CRM, revenue intelligence, GTM signals, GTM automation and intent data.
• When: September 1, 2026, all probes issued within a single session.
• Where: one machine on a North American residential network, no VPN, no vendor credentials of any kind. The single exception is the Cleanlist tool count, which came from our own authenticated session, is not comparable to the counts other vendors publish, and is reported on its own rather than inside any census figure.
• The probe: HTTP POST of a JSON-RPC 2.0 initialize request, protocolVersion 2025-06-18, with headers Content-Type: application/json, Accept: application/json, text/event-stream and MCP-Protocol-Version: 2025-06-18. 15 second timeout, redirects followed.
• Endpoint patterns tried per vendor: https://mcp.<domain>/mcp, https://<domain>/mcp, https://api.<domain>/mcp, https://<domain>/api/mcp, plus https://mcp.<domain>/sse and https://<domain>/api/mcp/v1 for every vendor with no hit, plus any endpoint named in that vendor's own documentation.
• Volume: several candidate endpoints and one control path per vendor. We did not publish the raw probe log, so no total request count is recomputable from the dataset and this page quotes none. The CSV publishes the one endpoint each verdict rests on, plus the control outcome wherever a control decided the verdict.
• What counts as a server: the inclusion rule at the top of this page. Vendor-operated only, product data only, documentation-search servers reported separately, community wrappers excluded.
• Exclusions: Cleanlist buys data from several vendors in this census and they are measured on exactly the same rule as every other row. Where a supply agreement makes publishing a measurement of a vendor inappropriate, that vendor is left out of the dataset entirely rather than partially reported, so the published census is 59 vendors. No figure on this page counts a vendor that is not in the CSV.
• Decision rule for "live": (a) a 401 or 403 at the endpoint carrying MCP-specific evidence, meaning a WWW-Authenticate header resolving to an RFC 9728 document whose resource field names that endpoint, or a body naming MCP or the vendor's MCP auth, and a materially different response from the same host on a nonsense control path; or (b) a 200 carrying a valid JSON-RPC initialize result. Vendors whose own documentation describes a server we could not reach are marked "yes (vendor docs)" and counted separately.
• Decision rule for "no": 404, DNS failure or connection refusal on all six patterns, or a 200 returning HTML, and no first-party documentation of a server.
• Scope: vendor-operated servers only. Community wrappers on GitHub, npm, Zapier and similar platforms are excluded, because they are third-party code holding your credentials.
• Not measured: server uptime, latency, tool quality, data accuracy, and the contents of any auth-gated tool list.
• Dataset: gtm-mcp-census-2026-09.csv, 59 data rows, 15 columns, CC BY 4.0. Column dictionary below.
• File layout: the file opens with four comment lines beginning with #, then one blank line, then the header row, then the 59 data rows. A default pandas.read_csv or R read.csv will misparse it, so read it with the comment character set: pandas.read_csv(path, comment="#") or read.csv(path, comment.char="#"). Every figure on this page is recomputable from those 59 rows except the ones named in the corrections section above, which this version no longer publishes.

Column dictionary