Twenty months. That is all it took for the MCP market to go from a November 2024 specification release to a sprawling ecosystem of nearly 16,000 public servers, 97 million monthly SDK downloads, and formal adoption by OpenAI, Google, Microsoft, and AWS. The growth curve is difficult to overstate: server deployments logged a 400% year-over-year increase by March 2026, and the official registry alone crossed 9,652 listings by April of the same year.
But raw scale tells only half the story. Independent security scans have surfaced exploitable flaws across a significant share of those public servers, and the infrastructure questions around registry lock-in, monetization transparency, and agent-discoverable pricing are only beginning to get serious attention.
This post works through what that growth actually looks like in practice, where the security reckoning currently stands, and what any developer should verify before wiring an MCP server into a production system. You will come away with a clear framework for evaluation, an understanding of the registry landscape, and a short checklist you can apply before your next integration decision.
Scale of the MCP Market
Those figures, 15,930 public servers, 400% YoY growth, 97 million monthly SDK downloads, sit atop an equally compressed adoption timeline. Microsoft's Windows AI documentation now covers MCP natively, and the broader Tier 1 SDK story has continued to accelerate: the July 28, 2026 spec blog reports close to half a billion downloads a month across Tier 1 SDKs, with both the TypeScript and Python SDKs crossing one billion total downloads. That trajectory, covered in more detail in why MCP adoption is accelerating in 2026, is not typical for an open protocol. Most infrastructure specs take years to cross that threshold.
The spec is moving too. The July 28, 2026 revision is the largest in MCP history. The spec was locked May 21, 2026, meaning anyone integrating between that lock date and the revision's release was building against a frozen target that has since shifted. If you are wiring MCP servers into production today, read the July revision before you finalize transport or capability assumptions. The spec uses RFC 2119 mandatory language; "MUST" and "SHOULD" carry normative weight that affects interoperability.
Scale and quality are not the same variable. The figures above describe deployment volume. They do not describe implementation correctness. The NSA noted in its May 2026 guidance that MCP's proliferation has outpaced its security model. High server counts reflect low friction to publish, not a quality floor. A developer evaluating which servers to integrate is looking at 15,930 options with near-zero standardized verification records across them. Understanding why that gap exists, and how it became a structural property of the ecosystem, requires understanding why MCP servers became infrastructure in 2026 in the first place.
The growth numbers are real and worth noting. The variance hiding inside them is where the practical risk lives, and that is what the rest of this analysis examines.
The Security Reckoning Happening Alongside That Growth
That growth rate has a shadow. In May 2026, the NSA released formal security design guidance for MCP deployments, joined by CISA and four allied agencies. The core finding: MCP's architectural model, where servers can query and execute on behalf of clients, creates attack paths that are new and largely untraced.
Independent security scans conducted around the same period found exploitable flaws in a large share of public MCP servers currently in operation.
The Seven Attack Surfaces
The NSA guidance document and supporting analysis identify seven distinct surfaces integrators need to account for:
Prompt injection via tool descriptions. A tool's name or description field carries attacker-controlled text into the model's context.
Tool poisoning. A malicious server registers tools that appear legitimate but execute harmful actions.
Cross-server privilege escalation. An agent authorized on one server is manipulated into exercising permissions on another.
Credential leakage through context. Secrets passed through the context window become accessible to tools that should not see them.
Rug-pull via server update. A server's behavior changes after you have audited and trusted it. The tool manifest you reviewed is not the one running tomorrow.
Confused deputy attacks. A trusted server is induced to act on behalf of an unauthorized principal.
Insufficient transport authentication. Connections lack mutual authentication, making impersonation straightforward.
The CISA advisory characterizes prompt injection specifically as the most pervasive and hardest-to-mitigate threat in agentic systems. Sanitizing inputs at the model level is not sufficient; mitigations need to sit earlier in the call path.
More Servers, More Surface Area
That 400% growth compounds every attack class above: each new server is a new entry point. An integrator pulling tools from five servers faces five independent trust decisions, five update cycles to monitor, and five potential rug-pull windows. The math does not improve with scale.
The Verification Gap
Across approximately 15,930 public MCP servers, public verification records are effectively absent. No registry currently surfaces audit results, transport authentication confirmations, or update-history logs at the server listing level. That means a developer evaluating a server today is making a trust decision with no documented basis for it.
This is a structural problem, not a temporary gap. The ecosystem grew faster than its verification infrastructure. For security checks before adding any MCP server, developers currently have to assemble their own checklist from scattered sources including the NSA guidance, independent scan reports, and manual endpoint testing. The next section covers what that checklist should include.
How to Evaluate an MCP Server Before You Integrate It
The NSA and CISA guidance names the attack surfaces. What it does not provide is a step-by-step method for evaluating a specific server before you wire it into your agent. No industry checklist exists for that yet. Four dimensions cover most of the practical risk: endpoint behavior, authentication model, monetization transparency, and public audit record.
Endpoint Behavior
Test directly. Send a Streamable HTTP request to the server's endpoint. A well-behaved server responds without requiring an account, an API key, or a signup flow. It returns a well-formed tool manifest you can inspect. If a server gates that initial response behind registration, you cannot verify what you are integrating before committing credentials or agent context to it.
Authentication Model
Servers that require opaque tokens with no documented revocation path create the credential leakage risk the CISA guidance identifies explicitly. Before integrating, confirm: Is token scope documented? Is there a revocation procedure? If neither is published, treat the authentication model as untested. A server that cannot explain how to invalidate a compromised token should not sit inside an agent with broad tool access.
Monetization Transparency
This dimension is almost never discussed, but post-integration surprises are common. Check whether pricing, usage limits, and tier boundaries are documented before your agent depends on the server. Opaque monetization is also a functional problem for autonomous agents: if the server cannot communicate its price in a machine-readable way, the agent cannot acquire or renew access without a human in the loop. This is a system design constraint, not just a billing inconvenience.
Public Audit Record
Self-attestation is weak signal. Look for a verifiable public result, one with its own URL that you can open independently of the vendor's marketing page.
Two tools produce that kind of record in the current MCP ecosystem. Moltline Studio's free agent-readiness checker grades servers on documented criteria and outputs a public result URL anyone can share and verify. Grades run A+ to B+. MCPize audit grades work the same way: each audit has its own result URL, shareable and independently reviewable. Neither requires trust in a vendor summary. You open the URL and read the result yourself.
For a more detailed breakdown of these four dimensions in a production context, A Production-Grade MCP Server Evaluation Checklist covers each with specific pass/fail criteria.
The practical sequence is: test the endpoint unauthenticated, read the tool manifest, check the authentication documentation for scope and revocation, confirm pricing is disclosed, then look for a public audit result with a verifiable URL. A server that clears all four is materially lower risk than one you took on trust from a registry listing.
Registry Lock-in and Portable Alternatives
Evaluating individual servers is only half the problem. The other half is where your agent finds them in the first place.
Four major registries host that concentration of public servers. It is convenient during integration and fragile afterward. When your agent resolves tool endpoints through a registry, it inherits a dependency on that registry's discovery format, API schema, and continued availability. Those are three separate failure modes, and unwinding any of them after the fact requires touching every agent that consumed the integration.
What Lock-in Looks Like in Practice
The failure scenario is not hypothetical. If a registry changes its discovery format, an agent that parsed the old schema silently returns no tools or throws at runtime. If a registry deprecates an endpoint, every resolution path through it breaks simultaneously. If a registry shuts down, the servers it listed do not disappear, but your agent has no way to find them. None of these scenarios require the underlying MCP server to fail; only the intermediary needs to change.
The July 28, 2026 spec revision moves MCP to a stateless core with header-based routing, which reduces session coupling between clients and servers. It does not reduce registry coupling. Discovery is still a separate concern from transport.
A Portable Alternative: SKILL.md
One way to reduce registry dependency is to decouple skill distribution from registry infrastructure entirely. SKILL.md is a file-based skills model. 138 open SKILL.md files are published at GarphenGate/moltline-oss on GitHub. Each file describes a discrete agent capability in a structured, human- and machine-readable format. An agent can consume these directly from the repository, from a local clone, or from any mirror, without routing through a registry at all.
That is the core portability guarantee: the dependency is on a file at a URL you control, not on a registry's discovery layer you do not.
Agensi provides a complementary distribution channel. Skills and servers distributed through Agensi exist outside the four major registries, giving integrators a second resolution path that does not share failure modes with registry-based discovery. You can find a curated starting list of evaluated servers at best-mcp-servers.
What Portability Costs
The tradeoff is real. Registry-based discovery provides a large, indexed surface that makes finding relevant servers fast. Portable models require you to know what you want before you go looking. There is no browse or search layer. Manual wiring means more explicit configuration: you specify endpoints directly rather than resolving them dynamically. Keeping that configuration current is your responsibility, not the registry's.
The choice is not between good and bad options. It is between explicit dependency on infrastructure you manage and implicit dependency on infrastructure you do not. For production agents where a registry outage cannot be acceptable downtime, the manual overhead of a portable model is often the smaller cost.
Monetization Transparency and Agent-Discoverable Pricing
Registry lock-in is a discovery problem. Pricing opacity is a different kind of problem, and for autonomous agents it is more severe.
Most MCP servers in the current ecosystem have no machine-readable pricing. Access terms live in a marketing page, a Notion doc, or an email thread. When an agent hits a paywalled endpoint, it stalls. A human has to step in, negotiate access, generate a key, and inject it into the agent's context. That is not a UX inconvenience; it is a hard architectural break in any workflow that is supposed to run without supervision.
The HTTP 402 Mechanism
HTTP 402 ("Payment Required") has existed in the spec since 1997 but saw almost no production use until agentic workflows created a concrete need for it. The pattern is straightforward:
Agent sends a request to a paywalled endpoint.
Server returns
402with a machine-readable payload containing price, currency, and settlement address.Agent reads the payload, executes the payment on-chain, and retries with proof of settlement.
Server validates and responds normally.
No human involvement. No account creation. No API key provisioned by hand.
The x402 protocol, backed by stablecoins on blockchain rails, is the most documented open implementation of this pattern. It eliminates the friction that breaks agentic loops at the payment step.
A Live Endpoint You Can Test
mcp.moltlinestudio.com/api serves a live x402 challenge. Paste it into Claude, Cursor, Codex CLI, or any MCP client. The agent receives a 402 with a price payload it can read and settle on-chain in cryptocurrency. No signup is needed to observe the challenge. The behavior is there to inspect, not just described.
This is one concrete example of what zero friction as an architectural choice looks like at the protocol layer. The design decision is that price discovery and settlement should be things an agent can do, not things a developer has to do on an agent's behalf.
Documented Pricing vs. Opaque Models
Moltline's pricing is publicly stated, with a paid All-Access tier covering premium tools across hosted servers and a large set of free tools requiring no payment, no account, and no key. Both tiers are documented before you touch an endpoint.
Most MCP servers in the ecosystem publish no pricing. Some gate access behind enterprise sales. Others require a waitlist. For a developer evaluating an integration, the absence of published pricing means you cannot assess cost until you are already partway into an onboarding flow.
For an autonomous agent, unpublished pricing is a hard blocker. The agent cannot negotiate. It cannot read a sales page. Opaque pricing effectively removes that capability from the agent's reachable set until a human re-enters the loop.
Pricing Transparency as a System Design Question
If you are building an agent stack that acquires capabilities at runtime, the pricing model of every MCP server in your dependency graph is a systems concern. Ask three things before wiring in any server:
Is the price documented publicly and in advance?
Does the endpoint return a machine-readable price payload under 402?
Can your agent settle and retry without human intervention?
If any answer is no, autonomous capability acquisition through that server is not possible today. That may be acceptable for a human-supervised workflow. It is not acceptable for an unsupervised one.
What the Market Looks Like From an Integrator's Perspective
The question is whether the free surface area is large enough to evaluate an integration before any commitment is required.
At Moltline Studio, 110 of the 160 available tools are free with no account, no API key, and no signup. They are spread across 22 hosted servers. Each server has a direct Streamable HTTP endpoint:
mcp.moltlinestudio.com/<server>
Paste that URL into Claude, Claude Code, Cursor, or Codex CLI. The tools are available immediately. No SDK wrapper, no authentication step, no configuration file beyond the endpoint itself.
The remaining 50 tools require the $19/month All-Access licence, payable in cryptocurrency only. If you want a detailed breakdown of how to think about tier composition against your actual tool usage, Practical Stack Composition: Endpoints, Tiers, and Cost covers that directly.
What to know before committing
This is a one-person studio. There is no published SLA. There is no dedicated support team. It is not positioned as enterprise infrastructure, and claiming otherwise would be inaccurate.
That is not a disqualifier for every use case. Prototyping, agent scaffolding, internal tooling, and exploratory integrations do not require carrier-grade uptime guarantees. Production workloads with strict availability contracts do. Know which category your use case falls into before wiring anything deeply.
The evaluation path
Start with the 110 free tools. Send a raw Streamable HTTP request to any endpoint and inspect the tool manifest directly. Run the free agent-readiness checker; each result has a public URL. If the free tier covers your requirements and the audit grade is acceptable, you have enough signal to decide whether the $19/month tier is worth testing. If the free tier does not cover your requirements, you also have that signal before spending anything.
The 138 open SKILL.md files at GarphenGate/moltline-oss on GitHub are a parallel resource, free and registry-independent, useful for agent skill composition outside the MCP server surface entirely.
The evaluation order matters: free tools first, readiness check second, paid tier third, deeper integration last.
A Short Checklist for Integrators
Before committing to any server, run through these four checks in order.
1. Confirm a public audit grade. Both the Moltline agent-readiness checker and MCPize produce shareable public result URLs graded A+ to B+ (covered in How to Evaluate). If a server has no public audit record, treat that as a signal, not a minor gap. With roughly 15,930 servers deployed and near-zero public verification records across the ecosystem, the absence of a grade is the norm, not the exception. You are deciding whether to accept that risk, not whether to be surprised by it. For a fuller breakdown of what those grades cover, the Actionable Takeaways post walks through the scoring criteria directly.
2. Test the endpoint before you wire it in. Send a Streamable HTTP request and inspect the tool manifest. If the endpoint requires an account, an API key, or a redirect before it returns a manifest, document that dependency before integrating. Servers at mcp.moltlinestudio.com/<server> respond to a direct request with no auth step; use that as a baseline for what frictionless looks like.
3. Verify pricing is agent-readable. If there is no HTTP 402 x402 payload (see Monetization Transparency), autonomous settlement is not possible, flag that before wiring in. Check mcp.moltlinestudio.com/api for a live example of the x402 pattern.
4. Evaluate your registry dependency. If your integration discovers servers through a single registry, write down what breaks when that registry changes its format or goes offline. Portable alternatives exist: 138 SKILL.md files at GarphenGate/moltline-oss on GitHub can be consumed without registry intermediation.
Free starting points, no account required:
110 tools across 22 servers at
mcp.moltlinestudio.com, direct Streamable HTTP, no signup138 open SKILL.md agent skill files at
GarphenGate/moltline-osson GitHubFree agent-readiness checker with public result URLs
Run the checklist against any server before it reaches production, including Moltline's own. The tooling to do it is free. The cost of skipping it is not.
Conclusion
The MCP market in 2026 is growing fast, but growth without scrutiny is how vulnerabilities and bad dependencies reach production. Four things matter most before you integrate: verify authentication is actually enforced, confirm the server is reachable without friction, check that pricing is agent-readable rather than human-gated, and understand your exposure if a single registry goes offline.
These are not abstract concerns. They are checklist items you can run today, against any server, using free tooling.
The ecosystem rewards developers who treat evaluation as a first step rather than an afterthought. Portable skill files, open server directories, and machine-readable pricing patterns already exist. The infrastructure to build responsibly is in place.
Pick one server on your integration list. Run the checklist against it before the week ends. That single habit, repeated consistently, is what separates resilient agent stacks from fragile ones.