Model Context Protocol moved from Anthropic experiment to shared infrastructure fast. Since MCP launched on 25 Nov 2024 and was donated to the Linux Foundation's Agentic AI Foundation in Dec 2025, with Anthropic, OpenAI, Google, Microsoft, AWS, Cloudflare, and others involved, the governance signal is clear: this is infrastructure, not a toy integration layer. For intermediate developers, the practical question is no longer whether an ai mcp server matters, but how to inspect, connect, and operate one correctly.
This tutorial covers the current MCP server model: what servers expose versus what clients expose, including resources, prompts, tools, sampling, roots, and elicitation. You will compare stdio, Streamable HTTP, and deprecated HTTP+SSE, then examine why registry counts disagree by 3x and what real adoption looks like. Next, you will pick a hosted Streamable HTTP endpoint, connect it to Claude, Cursor, or Codex CLI, verify the tool list, and read errors. We will also cover stdio versus Streamable HTTP, local versus hosted tradeoffs, an agent payment scenario with no human in the loop, limitations and auth tradeoffs, plus next steps for skills, the spec, and building your own. You will finish with a practical action plan.
What an AI MCP Server Is, and Why the Governance Story Matters
MCP (Model Context Protocol) is an open protocol that lets an AI client discover and call tools, read resources and load prompts from a separate process. Instead of hardcoding one integration per service into the host app, you point the client at a server that already speaks the protocol.
Anthropic announced MCP on 25 November 2024. In December 2025 it was donated to the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg as members.
That governance structure is the tell. A protocol whose governing body seats competing vendors is infrastructure, not one company's feature. It also means the spec can move under you. The 2026-07-28 revision converted MCP from a bidirectional stateful protocol into a request/response stateless one and introduced a formal deprecation policy. Pin your client version. Read the changelog before you upgrade anything.
Server versus client: the server exposes capability, and the client is the host app connecting to it, such as Claude, Claude Code, Cursor, Codex CLI, VS Code or ChatGPT. One client can hold many servers. Zuplo's 2026 survey puts 70% of respondents at 2 to 7 servers. The table of contents maps where this guide goes next.
Where the term gets sloppy: "AI MCP server" describes both a local stdio process on your laptop and a remote HTTPS endpoint. Those are different deployment shapes with different auth, failure modes and restart behavior. Keep that distinction; the rest of this post depends on it.
What a Server Exposes, and What the Client Exposes
Both sides of the connection expose primitives. That distinction changes how you debug.
Server side
Resources are readable context. Prompts are templated instructions. Tools are callable functions. Tools get the attention when people say "MCP server," but the other two exist, and clients surface them differently: some render resources as attachments, some hide prompts behind slash commands.
Client side
Sampling lets the server ask the model to generate. Roots declare filesystem or workspace boundaries. Elicitation lets the server ask the user for input mid-call, and the current spec splits it into form mode and URL mode for sensitive data and OAuth flows.
The consequence: an MCP server is not a dumb RPC endpoint. It can call back into the client. That is why capability negotiation happens at initialize time, and why the same server can behave differently in two clients.
Tool schemas are JSON Schema. The model sees a name, a description and an input schema. Nothing else. A vague description is the most common reason a correctly registered tool never gets called. Write the description to say when to use the tool, not just what it does.
When a client misbehaves, read the specification before reading your code. Version skew between client and server explains a large share of "the tools did not load" reports. Pin your client version.
For how these primitives fit into an agent loop, see the MCP server backbone.
Transports in 2026: stdio, Streamable HTTP, and Deprecated SSE
Capability negotiation happens over a transport, and the spec defines two.
stdio runs the server as a client-launched subprocess speaking JSON-RPC over stdin and stdout, UTF-8 encoded, newline-delimited. No network auth, no port, no TLS. Its lifetime is tied to the client process, so closing Claude Code ends the server. That is the entire configuration story, which is why local filesystem and shell tools use it.
Streamable HTTP is one endpoint. The client POSTs each JSON-RPC message to a single URL; the reply arrives as a JSON object or a request-scoped SSE stream. Target this for anything remote, and it is what hosted servers use. A hosted endpoint is a plain HTTPS URL, for example mcp.moltlinestudio.com/<server>. Paste it, the tools appear, nothing to build.
HTTP+SSE is deprecated. If a README tells you to run a separate /sse endpoint alongside a POST endpoint, it predates the current spec. Note the nuance: SSE as a mechanism still exists inside Streamable HTTP. What is deprecated is the standalone two-endpoint transport. Migrate rather than build new on it, and read the current transport binding before you copy an old config.
The consolidation is the practical win. One URL replaces per-client process spawning, so the same server works in Claude, Cursor and Codex CLI with no local install and no Node runtime to keep updated. If you are still choosing between the two, stdio vs. Streamable HTTP works through the tradeoffs in detail.
How Many MCP Servers Exist? The Counts Disagree by 3x
Transports settled. The population did not. Ask how many MCP servers exist and you get three answers, roughly 3x apart.
The cleanest number is a raw API pull. On 24 May 2026 the official MCP Registry API returned 9,652 latest server records and 28,959 server/version records. The registry is still in preview, so those totals can reset before general availability. Anthropic separately cites 10,000+ active public servers.
Third-party counts spread wide: about 5,800 servers and 300+ clients (guptadeepak), about 14,000 (arXiv), and 17,000+ (Zuplo). Same ecosystem, three answers.
The spread is definitional, not a scandal. Four populations get counted as one:
Registry records, which are metadata entries. One server can appear at many versions.
GitHub repos tagged
mcp-server: 15,926, withmodelcontextprotocol/serversat 86,148 stars and 10,799 forks.Actively maintained servers.
Anything a vendor calls a server.
Count a metadata record, a package and a repository, and one codebase produces three totals.
So treat any single count as an order of magnitude, not a figure. A number with no stated method is marketing, not measurement.
If you need a defensible number for a decision, query the registry API yourself and state the date. That is reproducible in a way a blog post is not. Before you wire anything up, run it past MCP Server Security: Evaluation Checklist for Production.
What Adoption Actually Looks Like Right Now
Server counts are fuzzy because the population itself is undefined. Usage is measurable, and it moved fast. Anthropic cites 97M+ monthly SDK downloads, and server downloads went from roughly 100,000 in November 2024 to 8M+ by April 2025. That is roughly an 80x rise in five months. Even where the totals stay contested, the direction does not.
Production adoption is smaller than the download curve implies. Stacklok's 2026 report puts 41% of surveyed software organizations in limited or broad production with MCP servers. Use 41%. The widely repeated 78% figure has no traceable source and was retracted by the site that published it, though secondary coverage still circulates it.
Practitioner sentiment is split. Zuplo's 2026 survey of roughly 100 technical professionals found 72% expect MCP usage to increase over the next 12 months, 54% are confident in long-term viability, and about 40% are skeptical. The sample is small, so read those as directional. The skepticism is not noise. It tracks with the security number below.
What people actually run is unglamorous. 63% use data-source servers, 58% wrap existing APIs, and gateways are the most common hosting method. Wrapping an API you already own is the normal first project, not novel tool-building.
The blocker is not capability. 50% name security complexity as the top blocker. That is an intermediate problem: something is deployed, and now it needs hardening. That is the audience this post is written for. For a wider look at what shipped and what held up, see The Bottom Line.
Step 1: Pick a Hosted Streamable HTTP Endpoint
Start from a URL, not a repo. The pattern used here is mcp.moltlinestudio.com/<server>, which serves 22 hosted servers exposing 160 tools. 110 of those tools are free forever: no account, no API key, no signup.
The free tier asks nothing from you. Paste the URL into your client and the tool list loads. No OAuth dance, no token to rotate, no local process to keep alive.
The other 50 tools sit behind one $19/month All-Access licence, payable in cryptocurrency. One tier, no seat math, no per-server add-ons.
Check what a server does before wiring it. The tool list is the contract. A URL that returns 200 on a GET is not necessarily a working MCP endpoint. It has to return a valid tools/list, and it has to speak a protocol version your client understands. Under the 2026-07-28 spec there is no negotiation handshake; every request carries its version and the server accepts or rejects it. Clients on earlier revisions still rely on the initialize handshake. A server supporting neither returns UnsupportedProtocolVersionError, which beats a silently empty tool list.
If you are still choosing, where to find MCP servers to add covers the discovery side.
If you would rather build than paste, the spec is at modelcontextprotocol.io. A minimal stdio server is under 100 lines with the TypeScript SDK, and building one is the quickest way to see why the handshake matters.
Step 2: Connect It to Claude, Cursor, or Codex CLI
Every MCP client config entry has the same three fields: a name, a transport type, and a URL. Key names shift between releases, so check the client's own MCP docs rather than a blog snippet, this one included. For Streamable HTTP, the URL is the endpoint from Step 1.
Claude and Claude Code. Add the remote server to the MCP configuration, then restart the session. Remote HTTP servers land in the same tool list as local ones, so a hosted endpoint and a local stdio server can run in one conversation. How Claude connects to MCP servers shows the config shape.
Cursor. Add the URL under MCP servers in settings. Cursor treats remote servers as first class, so no wrapper script and no local bridge process.
Codex CLI. Register the endpoint in its MCP config and confirm the handshake in the session output. If it prints negotiated capabilities, look for tools in that list before assuming the connection failed.
Keep the endpoint in one place. If you run three clients, store the URL in a note instead of retyping it into each config. In practice, the most common failure is a typo or a trailing slash, and it presents as a server outage rather than a config error.
Step 3: Verify the Tool List Loaded and Read the Errors
A green status dot proves the client handshake completed. It does not prove tools registered. Success is a visible tool list. Count what loaded. Connect all 22 hosted servers and the expected total is 160 tools. A list of 9 tells you exactly which endpoints failed, instead of leaving you with "something went wrong."
Common failures, in the order you will hit them: transport mismatch, where the client is configured for stdio and you handed it an HTTP URL; a wrong or extra path segment, often a trailing slash; and a client that caches the tool list until a full restart rather than reloading the session. For what the discovery exchange actually looks like on the wire, see Tool Discovery: How Claude Code Sees What is Available.
If a tool appears in the list but the model never calls it, the problem is usually the description. The model sees the name, description and input schema, and nothing else. Write the description to say when to use the tool, not just what it is.
Test read-only first. Run a tool that only reads, confirm the round trip, then move to anything that writes or deletes.
When a call fails, log the raw JSON-RPC. Client UIs flatten errors into "something went wrong," which hides whether the server rejected the call or the model sent the wrong argument. The error code is the answer; the toast is not.
That closes the connection loop. Next: whether this endpoint shape fits your case.
stdio vs Streamable HTTP, Local vs Hosted: A Comparison
With the tool list verified, the transport choice is what determines who can call it and what breaks when it fails.
Deployment | Auth | Lifecycle | Reach | What you inherit |
|---|---|---|---|---|
stdio, local process | None between client and server | Starts and stops with the client | One machine only | Silent death when the child process crashes |
Streamable HTTP, local server | Optional token on the loopback port | Survives client restarts | One machine only | Port collisions and a process to babysit |
Streamable HTTP, hosted endpoint | Handled at the endpoint, at the transport layer | No process to restart | Any client on any machine | A network hop, and someone else's availability |
Local over stdio is the right answer for filesystem and shell tools that must see your machine. Nothing else gives a server that kind of access without you opening a port.
The decision rule is short. If the tool needs your local filesystem, keep it local over stdio. If it is read-only, or shared capability you want in three clients without three installs, host it and paste the URL.
Hosting also changes who can pay for a call, which is the next problem.
An Agent Paid an Endpoint With No Human in the Loop
Hosting decision made, the next question is how a hosted server gets paid. Most MCP monetization write-ups stop at metering: count the calls, bill the account. A documented end-to-end agent payment, with nothing clicked by a human, is rare enough to show rather than describe.
Request https://moltlinestudio.com/api. The response is HTTP 402, the reserved Payment Required status code. Alongside it sits an x402 challenge: the price, the asset, the network and the settlement address, encoded in the response body rather than in a page a human has to read.
An agent reads that payload, settles on-chain, and retries the original request with proof of payment. No signup, no card form, no dashboard click, no human.
Why this matters if you publish a server: a priced server needs a machine-readable way for an agent to discover the price. A pricing page is not machine-readable. A paywall is a dead end for an autonomous caller, because the only thing it can do is stop.
x402 is a standards-track concern now, with its own foundation and a public flow that starts exactly where this one does: unpaid request, 402 response, pay, retry. The 30-day figures published on x402.org report roughly 75.4M transactions and $24.2M in volume. Those are self-reported.
Try it before writing client code. Request /api, read the 402 payload, and look at the fields. The response is the documentation.
Limitations and the Honest Auth Tradeoff
Agent-native payment solves a pricing problem. It does not solve an identity problem. Be clear about what the free tier gives up.
The 110 free tools need no account, no API key, no signup. That is deliberate, and it has a cost: no per-key rate limiting, no per-user quota, and no way to revoke a single caller. If one client misbehaves, there is no switch to flip. Calling that "simple" would be hiding the tradeoff.
Zuplo's 2026 survey puts security complexity as the top blocker for 50% of technical professionals. A no-auth free tier does not answer that concern. It sits next to it. If your threat model needs per-caller identity, this is not it.
MCP itself supplies no compile-time RBAC, no consistent metrics, and no per-query audit trail, as Colrows concedes in its own comparison. Those requirements mean a gateway in front of the server, which is a different purchase.
A hosted AI MCP server has other costs. Your data never touches your machine. Every call spends a network hop. Availability is one person's problem, not a team's. That is a constraint, not a footnote.
Nothing here is certified. No SOC 2 report, no published uptime percentage, no SLA. If procurement needs those documents, this is not the right fit yet, and knowing that early saves everyone time.
Next Steps: Skills, the Spec, and Building Your Own
Worked examples, free checkers, and the spec
138 SKILL.md agent skills are open on GitHub at GarphenGate/moltline-oss. Read them as worked examples. Each one shows how a tool description and an instruction file should be written: when to use the tool, what it returns, what it refuses. Steal the structure.
Two free tools run against your own files before you ship: a SKILL.md linter and an agent-readiness checker. Both catch the vague-description problem, the one where a correctly registered tool never gets called.
If you want the packaged version rather than raw endpoints, bundles are distributed through Agensi. Otherwise the endpoints are the product, and they are already live: mcp.moltlinestudio.com/<server>.
Independent audit grades from MCPize are public, running A+ to B+, and each has a result URL you can open. Read the grade before you trust a server, including these.
Build your own: start from the spec
If you are writing your own server, start from the spec rather than a framework. A framework hides the protocol until something breaks, and then you are debugging two layers.
Read the spec at a dated version and state which one you target. The 2026-07-28 revision, the largest since launch, made the protocol stateless: the initialize handshake and session are gone, and Roots, Sampling and Logging are deprecated. So the durable constants are not the handshake. They are the tool schema and the discovery exchange. Get those right, plus the JSON Schema 2020-12 tool definitions the revision reinforces, and a plain round-robin load balancer can run your server.
Conclusion: What to Do With This
That is the loop closed: spec, worked examples, and a server you can run yourself. The last decision is which shape you actually need.
An AI MCP server exposes tools, resources and prompts to a client over stdio or Streamable HTTP. Transport is the choice that matters most, because it decides who can reach the server, where auth lives, and what breaks when a process or a network call fails.
To act now: pick a hosted Streamable HTTP endpoint, paste the URL into your client, count the tools that loaded, and test one read-only tool before trusting anything that writes.
Read statistics with the date attached. The official registry returned 9,652 latest server records on 24 May 2026. Third-party counts spread roughly 3x. The widely repeated 78% production figure was retracted by the site that published it, so use 41% from Stacklok's 2026 report instead.
Then decide honestly whether hosted fits. If you need per-caller identity, per-query audit trails or an SLA, a gateway or a local stdio server is the better answer. No free tier replaces that.
If you want something to paste in the next minute, mcp.moltlinestudio.com/ serves 110 tools free with no signup, no account and no API key. The /api endpoint returns a live HTTP 402 with an x402 challenge, so you can watch an agent read a price and settle on-chain with no human in the loop.
Paste one endpoint. Count the tools. Then decide what you build next.