I probed 1400 MCP servers – here’s what I learned

Last Updated: February 25, 2026

MCP has generated enormous excitement in the past few months. But there’s very little data on how widely MCP is actually being adopted, and by whom.

So, I decided to find out myself. Since August 2025, I started tracking the launch of new MCP servers across 2 million companies – servers built on dedicated MCP subdomains (ie. mcp.yourcompany.com). While imperfect, it seemed like a solid signal that a company is making a serious commitment to building an MCP server.

How fast is adoption actually growing, what kind of companies are building, and how secure are these servers? Here’s what the data shows.

Note: For those technically-inclined, the code I used to track MCP servers and examine their technical footprint is open-sourced here. The list of all MCP servers I found is here.

1. How has the number of MCP Servers grown in the past 6 months?

When I started tracking, there were 425 MCP servers by the end of August 2025. By the February 2026, that number reached 1,412 – a 232% increase in 6 months (more than tripled). To be clear: these are all company-operated MCP servers that external users connect to – not internal servers that developers spin up to connect Claude to their own tools.

More importantly, month by month, the pace is accelerating. I saw 56 new servers on September, 100 on October, 138 on November, 181 on December, 211 on January, and 301 on February.

Granted, 1412 MCP servers is not a whole lot, in the grand scheme of things. For context: among the same universe of 2 million companies, there are 151,000 dedicated API subdomains (ie api.yourcompany.com).

That means, the # of MCP servers is currently less than 1% of that number. Even if the TAM (total addressable market) of MCPs is 25% of the API market, we’re still in the very early stages of adoption.

Unsurprisingly, as with any early technology, it’s mostly smaller companies that’s been leading adoption. 81% of companies running MCP servers have fewer than 200 employees.

70% of the MCP servers were created by B2B companies. We’re talking your usual suspects like Stripe, Cloudflare, PagerDuty, Akamai and Hubspot.

30% of them were created by B2C (consumer) companies, and there were some eccentric examples. For example, I saw MCP servers from Bared Footwear (a shoe company), Sezano (a Romanian grocery store) and even from government administrations such as the Ministry of Survey from India.

2. How secure are most MCP servers? (Spoiler: not very)

So companies are clearly experimenting with MCP.

But speed has a cost, and it’s showing up in the security posture of the servers.

Of the servers where I could determine authentication method, 38.7% of MCP servers had no authentication. This meant anyone could connect, initialize a session, and enumerate every tool available – no credentials required.

What makes it more concerning is the kinds of companies it applies to. Among the no-auth servers I found tools with names like confirm_transfer, create_transfer, and get_kyc_status on a fintech server. lookup_candidate, get_resumes, and schedule_interview on an HR platform. get_account, create_refund, and simulate_payment on a payments provider.

Just based on the names, these probably shouldn’t be open MCP servers with no authentication.

On one MCP server belonging to a financial services company (that obviously won’t be named), a simple unauthenticated tool call returned what appeared to be account data. Now to be fair, it could’ve been fake mock development data, but either way it probably shouldn’t have been accessible without credentials.

Some of these servers could be development or staging environments where auth hasn’t been added yet. But “we’ll secure it before it goes to production” is a familiar story time after time. An open MCP server with sensitive tools is likely a security breach waiting to happen.

Beyond missing authentication, the broader security picture isn’t much better:

• 22.9% of servers had wide-open CORS, meaning any website can make requests to them (though this could be by design for some servers)
• Only 2.4% had any rate limiting in place
• 3 servers leaked internal debug information on a cold probe with no interaction at all

Companies are clearly rushing to not be left behind the MCP hype, but the result is an ecosystem that’s growing incredibly fast but securing slowly.

There was one bright spot. 93% of servers are already using Streamable HTTP, the current MCP transport standard, versus just 7% still on the deprecated SSE transport.

That suggests that when the spec changes its defaults, developers follow. That’s encouraging from a security perspective: if the major SDKs made authentication a default, most of the ecosystem would likely follow without any deliberate effort from individual developers.

3. Where are MCP servers being hosted the most?

Next, I looked at where these MCP servers are actually being hosted, and compared that to where these same companies host their traditional APIs. I only analyzed servers that weren’t sitting behind a Cloudflare CDN (that did not use Cloudflare Workers) or Akamai, since those mask the underlying hosting provider.

A few things stand out. Vercel, Railway, and Render – platforms developers reach for when they want to ship something quickly – account for 9% of MCP deployments combined, versus just 2.4% of traditional API subdomains.

Interestingly, Azure drops from 19% of API deployments to just 7% of MCP servers. The most logical explanation is that larger, more conservative organizations tend to run on Azure, and they’re slower to adopt anything new. But there was not much difference in the % that used AWS or Google Cloud in MCP servers vs traditional API servers.

Cloudflare Workers is the most interesting data point in the table. Workers accounts for an estimated under 1% of traditional API deployments, but 4.6% of MCP servers.

It’s worth mentioning that 25% of all MCP servers in our dataset sit behind the Cloudflare CDN as well. Between the CDN layer, Workers deployments, and OAuth (with Cloudflare Access/Zero Trust), Cloudflare has quietly positioned itself across the full stack of MCP infrastructure.

One big name not in this table? Oracle Cloud – and that’s not an oversight. Across the entire dataset, I identified just 4 pitiful MCP servers hosted on Oracle Cloud infrastructure, which is statistically indistinguishable from zero.

Oracle has been loudly marketing its cloud AI ambitions, but the developer community building MCP servers apparently didn’t get the memo (or got it and dutifully ignored it). To be fair though, the companies shipping MCP servers fast also tend to be exactly the demographic that never considered Oracle Cloud in the first place.

I also was able to identify the SDK used by some of these MCP servers using error messages, headers, and JSON-RPC error codes as fingerprints.

Three SDKs account for 100% of identifiable implementations with FastMCP having the lion’s share of the market so far.

4. How many tools does the average MCP server expose?

The tool counts tell you something about where we are in the adoption curve. The average # of tools was 13.4 tools per server, but the median tells a more honest story: 5 tools. Nearly half of all servers expose 4 or fewer.

MCP is clearly an ecosystem in the middle of figuring out what it is. The long tail of servers with 1-4 tools suggests a lot of companies are still in “we should probably have one of these” territory rather than “this is a core part of how we expose our platform.”

The exceptions make the pattern clearer by contrast. LimaCharlie’s 175 tools, Bitrise’s 67, Render’s 24 – these are companies that have clearly thought hard about what they want agents to be able to do. They’re building MCP as infrastructure, not as an experiment. But they’re the minority.

Of the 4,126 tools I found, 52% are read operations, 25% are write operations, and 23% I couldn’t classify. The most common tool names across all servers are search (18 servers), fetch (13), and ping (12) — generic utility operations that don’t say much.

More interesting is what sits further down the list, and they all give us hints as to what are the popular early use cases for MCP so far.

Sales automation is clearly a leading use case - create_lead appears across 5 servers, with related tools like find_lead_by_email, merge_leads, and add_to_list showing up across several more.

E-commerce is another strong cluster: get_cart, add_items_to_cart, and submit_checkout each appear on 4 independent servers — AI agents that can browse, add to cart, and complete a purchase end-to-end.

And finally, there’s fin tech: across multiple servers I found tools like place_order, get_holdings, get_positions, and cancel_order – AI agents with the ability to execute real financial trades.

One small but telling pattern: several domains in our dataset share identical tool signatures. For example, a handful of independent US car dealerships share the same 4-tool setup, almost certainly shipped by the same automotive SaaS vendor (CarGenius, I’m looking at you). MCP is already being distributed as a platform feature, not just built company by company.

5. 50% of companies with a MCP server don’t actually have a public-facing API

One of the most common dismissals of MCP goes something like: “This is just a REST API with extra steps. We already have OpenAPI.” It’s a reasonable skepticism. But it assumes companies building MCP servers already had a public API to begin with.

For every company in our dataset, I probed for api.* subdomains and cross-referenced public sources (with the help of the Anthropic API) to confirm whether they exposed a public-facing API – not an internal one, not a partner integration, but a genuine public developer API. And it turns out, about half don’t have one.

That’s interesting, and if it holds up, it suggests something worth thinking about. For these companies, MCP might not be a wrapper on an existing API. It might be the first machine-readable interface they’ve ever shipped.

Why is this the case? For starters, the bar for an MCP server is dramatically lower than the bar for a real public REST API. A proper developer API means versioning, documentation, SDKs, rate limiting, a developer portal, and a lot of work. MCP requires none of that. You write a few tool definitions, spin up a FastMCP server, and you’re good to go.

A public REST API is also a business decision. You’re implicitly saying: we have developers worth building for, we’ll support this, we’ll maintain it. For most small companies, that’s not worth the work involved.

MCP changes the ROI because the “developer” is now an AI agent, and the audience for AI agents is potentially everyone using Claude, ChatGPT, Perplexity, etc.

You’re not building for developers who might integrate with you – you’re building for the entire agentic web. That’s a different business case entirely. A ski rental company would never build a REST API for developers. But if there’s a chance that Claude books ski rentals on their behalf? That’s a customer acquisition channel worth a one-afternoon investment.

If that’s what’s happening here, the bull case is that MCP doesn’t just replace APIs – it expands the total addressable surface of machine-readable interfaces beyond what REST ever reached.

6. The number of MCP servers reached in ~1 year what took Zapier 5 years

To put MCP’s growth in context, it’s worth looking at how the last great integration platform scaled.

Zapier launched its developer platform in 2012 with around 60 apps. It took until 2017 – five years – to reach 1,400 integrations. Today, after 13 years, it has 8,000+. That’s the normal pace of ecosystem building: slow, steady, compounding.

The number of MCP servers hit 1,400 servers in 1 year.

It’s not a fair comparison, I admit – but that’s sort of the point. Zapier integrations require a formal partnership, a review process, and ongoing maintenance. MCP servers can be spun up in an afternoon by a single developer with no approval from anyone. The lower barrier is exactly why the growth curve looks so different.

Of the ~9,000 companies in the Zapier marketplace, 188 already have an MCP server — about 2%, including well-known companies like Stripe, Amplitude, PagerDuty, Webflow, Pipedrive.

But the more interesting number is the 86% going the other way. Of the 1,400+ MCP server companies I found, about 1200 have no Zapier integration at all. They never built one. Combined with the fact that half have no public API either, a significant chunk of MCP adoption isn’t coming from integration-savvy companies adding another channel.

It’s coming from companies that were never plugged into the automation ecosystem at all.

7. Auth0 is the most popular auth providers used by MCP Servers

One last analysis: The most provider popular Auth providers.

Of MCP servers with identifiable auth providers, Auth0 leads at 29%, followed by FastAPI’s built-in OAuth (17%), WorkOS (12%), Cloudflare Access (11%), and AWS Cognito (9%).

The headline isn’t who’s winning – it’s that nobody has won. Auth0’s “lead” is a rounding error in absolute terms. Clerk, the developer-favorite auth tool of the last few years, sits at 5%. The market is genuinely up for grabs.

The MCP Python and TypeScript SDKs ship with OAuth built in, which means most developers have a good-enough solution on day one. But built-in auth doesn’t give you user management, enterprise SSO, audit logs, or compliance certifications.

As MCP servers mature from experiments into production infrastructure, those requirements show up. Whoever makes production-ready MCP auth a one-line integration has a real opportunity, in my opinion.

So what does it all mean?

MCP is real and so far, indications are it’s not a fad. There’s 1,400 live servers, deployed by real companies, growing faster each month. And it’s just not your usual SaaS or developer startup either. It’s being deployed in “boring” industries, by companies that don’t have a public API or a Zapier integration.

But it’s also early, and the cracks are showing. The vast majority of MCP servers have only 1-3 tools. Nearly 40% of servers have no authentication.

On the other hand, security is a solvable problem. What’s interesting is what the data hints at beneath the surface.

The most interesting signal isn’t the growth rate or the tool counts. It’s the 50% of companies with an MCP server and no public API. It’s that 86% of companies with a MCP server don’t have a Zapier integrations.

That cohort suggests MCP might be doing something quite incredible: pulling in companies that never found the ROI to build a public API in the first place.

If AI agents become a genuine customer acquisition channel – and that’s still an if – then the calculus changes for every small business that previously had no reason to make their systems programmable.

Maybe this is a temporary spike. After all, early technology adoption is littered with experiments that never made it to production.

But five months of accelerating adoption is hard to ignore. The companies joining aren’t just your typical tech or developer infrastructure startup – they’re ski rental companies, insurance regulators, and tax filing apps in Bangladesh. That smells like the beginning of a shift where the internet becomes programmable by default.

Notes & Methodology

Notes: If anyone has any data on *demand for MCP servers*, I would love to include it somewhere in this post, as I focused primarily on the supply side 🙂

Methodology: DNS scanning of mcp.* subdomains across our tracked domain database. Infrastructure detection via CNAME resolution and IP range matching. Server fingerprinting via unauthenticated MCP initialize requests to paths /, /mcp, and /sse. SDK classification via error message patterns, HTTP headers, and JSON-RPC error codes. Tool enumeration via full MCP handshake on servers requiring no authentication. Company enrichment via LinkedIn data. Growth projections based on observed monthly new-server counts with 10% month-over-month compounding. Entire list of MCP servers I found can be found here and full source code for my analysis is in Github.