Search for the mcp server market and you will find a category gap: the most visible dedicated research forecasts security tooling, not servers or hosting. MCP, Anthropic's open-source standard interface for connecting AI applications to files, databases, and tools like search engines, shipped in late 2024 and saw wide adoption. Reference servers now anchor the ecosystem. That mismatch frames this analysis: the problem is category definition, not market size.
We will examine what the only dedicated report, the Model Context Protocol Security Market forecast for 2026 to 2031, covers and why its segments, like MCP Discovery and Inventory, MCP Security Assessment and Scanning, and MCP Gateway, say little about hosting. We will then review the Concordia University BoatSE '26 study of bug reports and pull requests on MCP reference servers, where file system operation issues rank as the most prevalent category at 21.32%. Next, we will map the unpublished hosting layer, inspect a hosted setup at the endpoint, review HTTP 402 and x402 pricing for agents, and outline how to evaluate an MCP server before wiring it in. Finally, we will locate where money sits across three candidate layers, state what this analysis cannot tell you, and suggest next steps.
Why the MCP Server Market Is a Category Problem, Not a Size Problem
MCP is an open-source standardized interface introduced by Anthropic to connect AI applications to external systems: files, databases, search tools. It shipped in late 2024, and adoption has been wide since. Anthropic's reference servers remain central; the STDIO transport is still the most widely deployed integration path in the ecosystem.
Search "MCP server market" and almost nothing returns about servers or hosting. The only dedicated market research scoped to this keyword covers security, not servers. If you need the protocol grounding first, start with What Are MCP Servers? A 2026 Guide to Model Context Protocol.
The word "market" implies vendors selling substitutable things. What exists instead is three adjacent capability layers: discovery and inventory, assessment and scanning, and gateway. Each is monetizable. Hosting is a fourth layer underneath them, with far less public documentation.
No vendor-neutral census of hosted servers, free-tier terms or endpoint-level prices is published anywhere indexed. Any quoted "market size" for MCP servers is therefore inherited from an adjacent report, not measured. If the citation chain ends at a security scope, the figure describes risk surface, not supply, and does not describe the thing you are buying.
This analysis responds by defining the category plainly, filling the hosting gap from direct observation of one running setup, and naming which questions public evidence cannot answer.
That framing has a practical use. When someone asks you to justify a build or buy decision, open the source behind your number. A security-market scope with no published size does not price the endpoint you are wiring in.
What the Only Dedicated Market Report Actually Covers
The keyword surfaces exactly one dedicated report: Mordor Intelligence's Model Context Protocol Security Market Size, Share & 2031 Growth Trends Report. Note the subject. It is MCP security, not MCP servers, and not hosting.
The document forecasts a 2026 to 2031 window and segments the category by capability: MCP Discovery and Inventory, MCP Security Assessment and Scanning, MCP Gateway, and others. It also splits by deployment into Cloud and On-Premises. The accessible extract cuts off mid-sentence inside the deployment list, so treat that segmentation as incomplete rather than exhaustive.
That deployment split is the closest the report gets to addressing hosting at all. It is a deployment-mode axis: where software is installed. It carries nothing about who operates servers for whom, or what supply exists.
More importantly, the extract contains no market size, no CAGR, and no dollar figure. The title promises "Market Size." The accessible content is a taxonomy of where tooling money goes. Read it that way.
Vendor interest clusters at gateway and scanning, and both sit adjacent to hosting rather than inside it:
A gateway routes traffic to servers someone else runs.
A scanner inspects servers someone else runs.
Neither hosts anything. The segmentation is a useful roadmap for which layers attracted commercial attention first. It says nothing about how many servers are running, what they cost per tool, or what free tiers allow. This taxonomy stops at the tooling layers; the Table of Contents of our managed MCP servers guide picks up where it stops, at endpoints you can actually call.
So the next time you see "the MCP server market is worth X," open the source. If the citation chain ends at a security-market scope with no figure, the number was invented somewhere between the report and the sentence.
What Developers Actually Hit: The Concordia Bug Report Study
The security-market segmentation tells you where vendors clustered. It does not tell you what breaks. For that, the useful artifact is a peer-reviewed study: "Developer Challenges in the Adoption of Model Context Protocol in AI Agent Development" by Oyelayo, Abedu, Khatoonabadi and Shihab at Concordia University, presented at BoatSE '26. The authors analyzed bug reports and pull requests on MCP reference servers to characterize developer challenges. The PDF is public at das.encs.concordia.ca/pdf/oyelayo_BoatSE2026.pdf.
Three categories carry the weight
File system operation issues are the most prevalent category at 21.32% of issues analyzed. That is the single largest bucket, and it is an operational concern, not a feature request. Data validation and type issues follow at 13.97%. Schema mismatches, unexpected types and rejected payloads rank second.
Connection and communication issues rank differently by count than by cost. The raw count is lower, but the authors report that developers spend more effort on them than on any other category. Relative effort per issue is highest here. Transport is the expensive part, not the loudest one.
Why the sample matters
The sample is Anthropic's reference servers, built to demonstrate connecting AI applications to external data sources. A 2026 paper choosing first-party examples is evidence that practice in this ecosystem is still defined by those servers rather than third-party alternatives. The study's stated audience is server maintainers, and its findings describe reference implementations, not hosted ones.
What to budget for
Wire these numbers into your estimate. Budget integration time for transport, reconnection and payload validation, because that is where the reported problems live. It is also the gap a hosted endpoint with a fixed contract closes for you, which is why what to look for when evaluating an MCP server starts with schemas and failure paths rather than feature lists.
The Hosting Layer Nobody Publishes Numbers For
Transport is where the reported problems cluster. Hosting is where the published data runs out.
Search the keyword and you get security tooling, vendor blog posts, and GitHub repositories. No public figures exist on hosted server counts, free-tier terms, or endpoint-level pricing.
The counts that do surface measure registry and repository records, not running endpoints. On May 24, 2026, the Official MCP Registry API returned 9,652 latest server records and 28,959 server/version records, while the GitHub Search API returned 15,926 repositories carrying the mcp-server topic (MCP adoption statistics). Server/version records are a versioning construct. Directory listings enumerate packages. Neither tells you whether an endpoint is live right now, or what the free tier allows before it asks for an account.
Endpoint economics are effectively invisible. There is no side-by-side of published per-tool prices, no comparison of auth models, and no record of what happens when a free quota runs out. One aggregation attempt deleted its transport and auth split outright because it could not verify the claim.
The published conversation assumes a team, a platform, and an enterprise buyer. Every documented adopter in the indexed material is a platform or a large organization. A one-person, self-hosted operating model is essentially unaddressed.
That has a practical consequence for buyers: you cannot shortlist hosting providers on published data. You test endpoints, read schemas, and keep your own dated notes. It is more work, and it produces better evidence. For a direct comparison of what a free tier returns versus running your own process, see Free Tier vs. Local Servers: Honest Trade-offs.
For anyone writing about this category, the absence of figures is not proof that hosting is small. It is proof that nobody has bothered to publish the numbers.
What One Hosted Setup Looks Like at the Endpoint
The hosting layer is easier to describe with a running example. Everything below is one operator's observation of one live setup, not a market statistic.
Moltline Studio runs 22 hosted MCP servers exposing 160 tools. Each has a fixed Streamable HTTP endpoint, so you paste mcp.moltlinestudio.com/<server> into Claude, Claude Code, Cursor, Codex CLI or any MCP client and the tools work. Of the 160 tools, 110 are free forever with no account, no API key and no signup. Anonymous access is spec-permitted rather than a workaround: MCP authorization is optional, and strongly recommended only when a server touches user-specific data or needs action auditing.
The other 50 tools sit behind a $19/month All-Access licence, paid in cryptocurrency. That is the whole commercial surface: one price, one tier, no seats, no sales call.
Free and separate from the servers: 138 SKILL.md agent skills published on GitHub at GarphenGate/moltline-oss, plus a SKILL.md linter and an agent-readiness checker. Bundles distribute through Agensi. MCPize audit grades on this setup run A+ to B+, and each grade has a public result URL anyone can open and re-check.
Read those figures as a sample of one. A single running deployment describes itself exactly and generalizes to nothing else, which is also why no numbers are attached here for customers, revenue or uptime. The setup is documented because the tooling is built and run in-house rather than brokered, so endpoint behavior can be stated precisely instead of inferred.
What makes it worth writing down is that it makes the hosting layer concrete in three places: a fixed endpoint per server, a documented free tier that returns working tools without an account, and a published price for everything else. Those three properties are what to check in any other hosted setup you evaluate before wiring it in.
Endpoint Pricing an Agent Can Read: HTTP 402 and x402
The last piece of that setup is the one most hosted servers have not built: a price an agent can read without a human in the loop.
Moltline's /api endpoint serves a live HTTP 402 x402 challenge. An unauthenticated request gets the payment terms back in the response. The agent reads the price, decides whether the terms are acceptable, signs a payment with a wallet it controls, and retries. Settlement happens on-chain. No browser, no card form, no invoice cycle.
That is the design question. Human checkout flows assume a person at a keyboard. An unattended agent cannot fill a form, hold a subscription, or wait on a sales process before making one tool call.
Three checks apply to any hosted MCP server:
Is the price machine-readable at the endpoint, in the response itself?
What authentication does a paid call require, and can an agent satisfy it alone?
Does the free tier return working tools before any of that?
x402 over HTTP 402 is a working example on one endpoint. It is not a standard the ecosystem has agreed on. Attribution is contested: x402.org describes an open standard with a Linux Foundation launch, while other trackers credit a single issuer. Reported volume exists, 75.41M transactions and $24.24M settled in one recent 30-day window on x402.org, with a separate tracker publishing cumulative totals under its own methodology. Do not reconcile the two. Volume on a payment rail is not evidence that hosted MCP vendors have adopted it. Treat it as one option and decide per integration.
The cost difference is concrete. If the endpoint states its own price, pricing logic lives on the server and your client stays simple. If it does not, you hardcode the terms and you own the failure handling when those terms change without notice. For a solo developer shipping an agent, that is recurring maintenance on a dependency you do not control.
For the mechanics of reading a payment decision out of a 402 response, see HTTP 402 and x402: Machine-Readable Licence Checks.
How to Evaluate an MCP Server Before You Wire It In
Endpoint pricing answers what you will pay. It does not answer whether the server survives a dropped connection or an honest schema. Evaluate in this order, and test rather than read.
Paste the endpoint before reading the docs. Drop
mcp.moltlinestudio.com/<server>into Claude, Cursor, or Codex CLI and call the tool list. If it demands a signup, an API key, or an email before returning anything, record that as friction, then weigh it against running your own process, where the setup cost and every future upgrade are yours.Read the schemas, then break them. Data validation and type issues are 13.97% of issues analysed in the Concordia study of MCP reference servers. Send malformed payloads at the boundary: wrong types, missing required fields, extra keys. What comes back tells you whether the server validates or throws.
Exercise the failure paths. File system operations lead that same study at 21.32% of issues, and connection and communication issues consume the most relative developer effort. Drop the connection mid-call. Time out a request. Ask for an oversized response. These are the paths most likely to break in your integration.
Check self-description. Run the free agent-readiness checker and the SKILL.md linter against anything you plan to depend on. A server that cannot describe itself to an agent is a support ticket waiting to be filed. For broader shortlisting criteria, see how to choose an MCP server.
Decide build versus host on maintenance. A local server you own is a permanent queue of upstream fixes. A hosted endpoint moves that queue to whoever runs it. That transfer, not the feature list, is what you actually buy.
Keep dated notes. Record what you tested, what failed, and when. Vendor claims age; your own checklist does not.
None of this says where the money in the category sits. That is the next question.
Where the Money Actually Sits: Three Candidate Layers
That checklist tells you whether a given server works. It does not tell you who sells what around it. For that, the segmentation is the only map available, and it names three candidate layers.
Layer one: discovery and inventory. Registries and catalogs of what exists. Cheap to build, hard to monetize on its own, and only as useful as the supply it indexes. The Cloud Security Alliance's draft agentic MCP security guide counted nearly 7,000 internet-exposed MCP servers, roughly half without authentication controls. A catalog with dead endpoints is a link list.
Layer two: assessment and scanning. Reviewing servers for security problems as a product. Buyers clearly exist: the same guide counts over 30 MCP CVEs filed in January and February 2026, including CVE-2025-6514 at CVSS 9.6 across more than 437,000 installed environments. Per-scan pricing and attach rates do not appear anywhere published, so treat vendor positioning here as marketing rather than evidence.
Layer three: the gateway. Routing, authentication and policy enforcement in front of servers. It is the most commercially visible layer in the segmentation and the least about hosting servers, since the servers behind a gateway are still someone else's problem to run. The November 2025 MCP specification formalized OAuth 2.1 for remote servers, so this layer reads as protocol work rather than product differentiation.
The hosting layer underneath all three has no published figures at all. A gateway with nothing to route to is a routing table. Hosting is what makes the layer above it real, and it overlaps most with the three layers of agent readiness: a server has to be reachable, describable and payable before anything above it can be evaluated.
Honest limitation: I run one hosting setup. I can describe what an endpoint does, what the free tier allows and what the paid tier costs on that setup. I cannot speak to vendor revenue, market share or growth rates anywhere else.
That asymmetry is the reason this article separates observation from inference. Layer analysis is cheap. Figures you can verify are not.
What This Analysis Cannot Tell You
The layer map above is inference built on two documents. Here is what it cannot establish.
No census exists. Nobody publishes a count of hosted MCP servers, their free-tier terms, or what one tool costs per call. This is not a query problem you fix with better search terms. Directories index repositories and package names, not live endpoints with prices attached. What would count as a census: a dated, endpoint-level inventory listing auth model and price per tool, published by someone with no server to sell.
Segmentation is not supply. Security-market categories describe where paid tooling clustered first, discovery and inventory, scanning, gateway. They say nothing about hosting. They do not tell you how many servers run, what any of them charge per tool, or whether one free tier is more generous than another. Different questions, and no published source answers them.
One setup is one setup. The figures in the previous section come from one operator. That setup runs 22 hosted servers exposing 160 tools, 110 free with no account and 50 behind a $19/month licence. Those are accurate descriptions of it and nothing more. A sample of one does not generalise. Do not read them as averages, medians, or share of anything.
Trace every dollar figure. Any number attached to "the MCP server market" is suspect until you open the citation. Most end at a security-scope report, a vendor page arguing you should buy, or nothing at all. If the chain terminates in a taxonomy with no size, the number was invented somewhere downstream. Check before you repeat it.
Test, then date it. Where evidence is thin, hit the endpoint yourself. Paste it into a client, note what auth it demands, send a malformed payload, record what returns. Write the date next to the result. Smaller claims, better decisions.
The next section covers what to do with that.
What to Do With This
Verify before you quote. When an "MCP server market" figure crosses your desk, open the source. If it traces back to a security-market scope with no size, say that instead of repeating the number.
Read the Concordia study for what breaks in practice. File system operations are 21.32% of issues analysed. Data validation and type issues are 13.97%. Connection problems consume the most developer effort, reported as relative effort rather than a percentage. Budget integration time for transport, reconnection, and payload validation before you budget for features.
Test endpoints before you commit. On Moltline, 110 tools are free forever with no account, no API key, and no signup at mcp.moltlinestudio.com/<server>. Paste the endpoint into Claude, Cursor, or whatever client you run and confirm tools return. Run the free agent-readiness checker and the SKILL.md linter on anything you plan to depend on. A server that cannot describe itself to an agent is a support ticket.
If you would rather not maintain your own server process, the $19/month All-Access licence covers the other 50 tools. Treat it as one published data point and compare it against your real maintenance cost: upstream fixes, reconnects, schema drift.
Then write down what you verified. Date, endpoint, tool count, what the free tier allowed, what broke. In a category with no public census, your own dated notes are the most reliable market data you will get.
Conclusion
The MCP server market is a category problem, not a size problem. Verify every figure at its source before you quote it. The Concordia study shows what actually breaks in practice: file system operations at 21.32%, data validation and types at 13.97%, and connection problems consuming the most developer effort. Budget integration time for transport, reconnection, and payload validation before you budget for features. The hosting layer remains unpublished territory, so treat any single price point as one data point and compare it against your real maintenance cost.
Test endpoints before you commit. Run the free agent-readiness checker, paste endpoints into your client, and confirm tools return. Then write down what you verified: date, endpoint, tool count, what broke. In a category with no public census, your dated notes become the most reliable market data you will get. Start testing today.