Most roundups labeled MCP server examples hand you a snippet that never touches the wire. That hides the part that matters: MCP is a layered protocol, and every client/server message must follow JSON-RPC 2.0. The spec splits responsibilities into a base protocol, lifecycle management, authorization, server features, client features, and utilities. It also sets a hard line: implementations MUST support the base protocol and lifecycle, while tools, resources, prompts, roots, sampling, elicitation, and transports MAY be added. That MUST-versus-MAY split explains why one MCP server example can be a ten-line stdio server and another can expose Streamable HTTP, auth, and sampling.
This post walks through concrete MCP server examples with real endpoints and JSON-RPC payloads. You will see one complete request, response, and notification flow. You will learn how to check the spec revision before copying anything, review server feature examples for tools, resources, and prompts, cover client features like roots, sampling, and elicitation, compare stdio, Streamable HTTP, and SSE transports, inspect authorization examples for HTTP transports, find more MCP server examples, and try a hosted example. By the end, you will know which payloads are portable and which depend on the latest spec.
What Actually Counts as an MCP Server Example
The word "example" does a lot of work in MCP. The spec splits implementations into six components, and only two are mandatory. Per the specification overview, implementations MUST support the base protocol and lifecycle management. Authorization, server features, client features and utilities MAY be implemented.
The six components, for labelling anything you find in the wild:
Base protocol: the core JSON-RPC message types.
Lifecycle management: initialization, capability negotiation, session control.
Authorization: the auth framework for HTTP-based transports.
Server features: resources, prompts, tools.
Client features: roots, sampling, elicitation.
Utilities: logging and argument completion.
Every example shares one hard requirement. All messages between clients and servers MUST follow JSON-RPC 2.0. Requests MUST carry a string or integer id. The spec defines exactly three message types: requests, responses and notifications.
That split is the reframe. A minimal compliant server can expose nothing beyond the base protocol and lifecycle and still pass. "Server" in the spec means a program on either end of the connection, so a client can be a server too. A good example is one that names the component it exercises, not one with the longest feature list. If you are still building the mental model, start with What Are MCP Servers? A 2026 Guide to Model Context Protocol.
The rest of this post follows one format. Each example names the component, gives the exact endpoint or method, shows the payload, and flags MUST or MAY. No description of a payload where a payload will do.
One Complete Example, End to End: Request, Response, Notification
The fastest way to see all three message types is to point a client at a live endpoint and read the traffic.
Paste target
mcp.moltlinestudio.com/<server> over Streamable HTTP. The 110 free tools need no account, no API key, and no signup, so you can follow this without stopping to register.
Request
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}
All messages between clients and servers MUST follow JSON-RPC 2.0, per the base protocol specification. That payload is the canonical shape: integer id, method name, empty params.
Response
{"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"example_tool","description":"Returns a fixture.","inputSchema":{"type":"object"}}]}}
The id is echoed back unchanged. That echo is how a client matches a response to the request it sent.
String ids work identically. Send {"jsonrpc":"2.0","id":"req-1","method":"tools/list","params":{}} and the response comes back with "id":"req-1". The spec allows a string or an integer, never null.
Notification
{"jsonrpc":"2.0","method":"notifications/initialized"}
No id field at all. Notifications are the third message type, alongside requests and responses, and they must never receive a response.
Lifecycle around it
Every server runs initialize, capability negotiation, then normal traffic. The client sends initialize carrying protocol version, capabilities, and implementation info. The server replies with the version it selected and the capabilities it supports. The client confirms with notifications/initialized. That ordering is MUST for every server, per the lifecycle specification, which makes it the first thing to check in any example you copy. For how those capability declarations map onto actual server surfaces, see Anatomy of an MCP Protocol Server: Resources, Prompts, and Tools.
The common failure
Reusing an id across concurrent in-flight requests. The spec requires a request id that has not been previously used by the requestor within the same session. Two outstanding calls sharing id: 1 leave a client that tracks ids unable to tell the responses apart, and the mismatch fails quietly.
Check the Spec Revision Before You Copy Anything
Before you copy the payload above into anything real, pin it to a revision.
Two anchors, roughly 13 months apart
2025-06-18 revision
Latest revision, 2026-07-28
Those two anchors are not adjacent releases. A payload that is correct on one revision can assume a capability name, transport default, or auth flow that changed on the other, or on a release in between. The 2025-06-18 changelog shows the spec moving inside a single revision already: JSON-RPC batching removed, structured tool output added, servers reclassified as OAuth Resource Servers. Cite one revision in isolation and the tutorial goes stale while still looking correct. Read the changes against the wider arc of the protocol's evolution and the pattern is easier to spot.
Diff these three things first
Transport assumptions. Endpoint shape, session handling, whether a response can upgrade to a stream.
The authorization section for HTTP transports. A flow that was optional may now be expected, or the reverse.
Capability names declared during
initialize. A renamed capability makes a client silently ignore a feature it could have used.
Enumerate, don't guess
The spec recommends its machine-readable index at llms.txt for discovering pages. An agent can fetch that file and enumerate the spec instead of guessing URLs.
Two navigation entries matter before you treat any behavior as settled: the Registry section and the SEP process. Spec enhancement proposals are where a behavior that looks obviously correct may still be open.
One limitation, stated plainly: this post's primary source extract is the 2025-06-18 revision. Verify payload shapes against the latest revision before shipping to production.
Server Feature Examples: Tools, Resources and Prompts
With the revision pinned, here is what the three server features actually look like on the wire.
Tools
Most roundups stop here. A tools/list request:
{"jsonrpc":"2.0","id":1,"method":"tools/list"}
Then a call with a name and an arguments object:
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search","arguments":{"q":"mcp"}}}
The response carries a content array:
{"result":{"content":[{"type":"text","text":"3 results"}]}}
Entries can be text, image, audio, a resource link, or an embedded resource. Tools are model-invoked, so a client needs discovery logic over the declared set. That flow is covered in Tool Discovery: How Claude Code Sees What is Available.
Resources
Read-oriented, a different access pattern. The resource descriptor shape (verify against the spec's Resources page before shipping):
{"uri":"file:///notes.md","mimeType":"text/markdown"}
resources/read then fetches that uri. Nothing mutates.
Prompts
User-invoked templates, not model-invoked calls. prompts/list enumerates them; prompts/get accepts arguments:
{"jsonrpc":"2.0","id":4,"method":"prompts/get","params":{"name":"review","arguments":{"lang":"go"}}}
The spec describes prompts as templates a client retrieves, supplies arguments to, and receives back as messages. Registering one as a tool is a common wiring mistake.
Capability negotiation
The initialize result declares which of the three exist:
{"capabilities":{"tools":{},"resources":{},"prompts":{}}}
Read this rather than assuming. A missing key means unsupported.
MUST or MAY
All three are server features, therefore MAY. A server declaring none of them is still compliant. That is why this section starts with the initialize result instead of a feature list.
Client Feature Examples Most Roundups Skip: Roots, Sampling, Elicitation
Server features are MAY. So are client features, and that is where most roundups stop writing. The spec gives Roots, Sampling and Elicitation their own pages under Client Features at https://modelcontextprotocol.io/specification/2025-06-18.
Roots
The client declares its boundaries:
{"jsonrpc":"2.0","id":7,"method":"roots/list"}
The response returns URIs such as file:///Users/you/project. A server that honors roots keeps reads and writes inside those paths. That is what keeps a filesystem server inside the directory the user actually intended.
Sampling
The server borrows the client's model instead of shipping its own key:
{"jsonrpc":"2.0","id":8,"method":"sampling/createMessage",
"params":{"messages":[{"role":"user",
"content":{"type":"text","text":"Summarize this log."}}],
"maxTokens":256}}
The client runs the completion and returns it. The server holds no credentials. Sampling can nest inside other server features.
Elicitation
The server needs structured input mid-call. The client surfaces a prompt, and the response is validated against a JSON schema carried in the request. That is the flow that turns a failed tool call into a question. Elicitation is new in the 2025-06-18 revision, and servers MUST NOT use it to request sensitive information.
The gap is structural. These three are client-side, so a roundup built from server code can show tools/list and resources/read but never the client half of the exchange. Coverage problem, not spec problem.
Test recipe: point a server at a client with no sampling support and confirm the failure is a clean capability error from the initialize handshake, not a hang. Sampling is MAY, so design around it: read negotiated capabilities and fall back. Aggregating several servers behind one client raises related questions, covered in what most searchers actually mean by 'meta MCP server'.
Transport Examples: stdio, Streamable HTTP and SSE
Client features fail quietly; transports fail loudly.
stdio. A locally spawned process exchanging newline-delimited JSON-RPC 2.0 on stdin and stdout. For example (verify against your client's docs): {"mcpServers":{"files":{"command":"node","args":["./server.js"]}}}. Anything the process writes to stdout that is not a JSON-RPC message corrupts the stream. Send logs to stderr instead.
Streamable HTTP. A single endpoint accepts POST and can upgrade a response to a server-sent event stream. Moltline's servers use this shape: https://mcp.moltlinestudio.com/<server>. In Claude and Claude Code, add the URL in Claude Code's MCP settings (syntax verified against Claude Code docs). In Cursor, paste the URL into MCP settings (check current client docs). In Codex CLI, add an [mcp_servers.moltline] block with url = "..." (check current client docs).
SSE is a separate transport, not a synonym for Streamable HTTP. The spec lists two standard transports, stdio and Streamable HTTP, and SSE is not one of them. Mixing the two in config produces the classic symptom: the client connects, then never lists tools. If you are weighing the two, stdio vs. Streamable HTTP: Which Should You Use? covers the tradeoff.
Where deployments break. Session identifiers dropped between requests, so state vanishes. Reconnect behavior after a dropped stream, where resumption is not guaranteed. Proxy and load balancer timeouts cutting long-running calls at 30 or 60 seconds.
MUST or MAY. The base protocol does not mandate a transport. Pick per deployment, then confirm the client supports it. This is the transport detail most mcp server examples skip entirely.
Transports decide whether the connection holds. Authorization decides what it is allowed to do.
Authorization Examples for HTTP Transports
Authorization applies only to HTTP-based transports. Over stdio there is nothing to authorize: the server is a local process, and the process boundary is the trust boundary. Most auth confusion comes from applying one model to both.
The HTTP flow. An unauthenticated request gets a challenge, the client obtains a token, and later requests carry it.
POST /mcp HTTP/1.1
Host: mcp.example.com
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
The client reads that metadata, gets a token, and retries:
POST /mcp HTTP/1.1
Authorization: Bearer eyJhbGciOi...
What breaks in practice.
Wrong audience. A token minted for one resource is sent to another, and the server rejects it.
Expired token with no refresh path. The client drops the call instead of re-running the flow.
Token scoped to a different endpoint. A read scope is used against a write endpoint.
The no-auth case is legitimate. The free tier at mcp.moltlinestudio.com/<server> requires no account, no API key and no signup. That fits public read-only tools. It is a deliberate configuration, not a missing auth section. If you want the client-side view of that handshake, see how Claude connects to MCP servers.
Agent-native payment as authorization. /api serves a live HTTP 402 x402 challenge, so an agent can read the price and settle on-chain with no human in the loop. Payment becomes the authorization step.
MUST or MAY: authorization is MAY. Skipping it is compliant, which is why so many examples quietly do. Treat an example with no auth section as unverified for production, not as secure.
Where to Find More MCP Server Examples
Start where the spec starts. Its navigation is a map of where practitioner attention sits: separate pages for Architecture, Lifecycle, Transports, Authorization, Server Features, Client Features, Registry, and SEPs. When a roundup you find covers only Tools, diff it against that list and note what is missing. The Registry and SEPs sections matter most, since an enhancement proposal is where a behavior gets settled rather than assumed.
Do not scrape those pages by hand. The machine-readable index at https://modelcontextprotocol.io/llms.txt lets a script or an agent enumerate the spec's pages, so your list stays current across revisions instead of aging with the last one you bookmarked.
Two free resources are worth running before you copy anything. For skill-shaped examples, 138 SKILL.md agent skills are open in GarphenGate/moltline-oss on GitHub, and the same repo carries a SKILL.md linter for checking your own files against the same rules. For endpoints, run the free agent-readiness checker first. You get a pass or a fail rather than a vibe. If you want a shortlist instead of a directory, this walkthrough covers where to find MCP servers to add.
Vet whatever survives those filters with four questions:
Which spec revision was it written against, and are you running that revision?
Which transport does it use: stdio, Streamable HTTP, or the older SSE?
Does it document authorization, and does the server you tested actually enforce it?
Does the server advertise its own capabilities? On the 2026-07-28 revision that means implementing
server/discover, since theinitializehandshake was removed.
One honest limit: this section rests on a single primary spec extract. Where that source set cannot support a claim, including benchmarks and vendor comparisons, the text says so rather than inventing one.
Try a Hosted Example Right Now
Skip the local build. Point a client at an endpoint that already runs and watch the lifecycle execute in one step.
The paste target
mcp.moltlinestudio.com/<server>
That is a direct Streamable HTTP endpoint, not a config generator. Swap <server> for a catalog name and paste the URL into Claude, Claude Code, Cursor, Codex CLI, or any MCP client. No account, no API key, no signup. The client sends initialize, negotiates capabilities, then calls tools/list. If the declared capability set matches what you expected, the wiring is correct.
What is in the catalog
Moltline hosts a set of MCP servers across a free no-signup tier and a paid All-Access tier. This is not a marketplace. No third-party tools are hosted on anyone else's behalf. Everything sold is built and run by one person, and that is the honest reason the surface stays small enough to audit. A narrow catalog is a constraint, not a selling point dressed up as one.
The agent-native path
Hit /api and you get a live HTTP 402 x402 challenge. The response states the price; an agent can read it and settle on-chain without a human approving anything. A human buyer pays in cryptocurrency through the site. /api exists for the case where there is no human in the loop at all.
Distribution and grading
Bundles ship through Agensi. MCPize audit grades carry public result URLs you can open and check yourself instead of taking on faith.
Pick the server that maps to the component you need to exercise, paste the endpoint, and call tools/list. The response tells you whether the rest is worth reading.
What to Do Next
You have an endpoint and a catalog. Here is the sequence that keeps a copied example from breaking in production.
Label every example you copied. Which component does it exercise, and is that component MUST or MAY? Base protocol and lifecycle management are MUST. Authorization, server features, client features and utilities are MAY. If the tutorial never said, assume MAY and test it yourself.
Diff against the latest revision. Payloads written for one revision can assume capability names, transport defaults or auth flows that moved in another. Compare your payloads against https://modelcontextprotocol.io/specification/latest/basic, not the revision the tutorial cited. Porting between revisions, check transports and the authorization section first.
Verify transports and authorization before features. These are the two areas where real deployments break, and the two most often missing from example roundups. Verify transports and auth independently; both sections above show the exact failure modes. A tool list that loads over a broken transport is not a pass.
Run one endpoint end to end today. Paste
mcp.moltlinestudio.com/<server>into your client, calltools/list, and check the capability set againstserver/discover. On the 2026-07-28 revision theinitializehandshake was removed;server/discoveris now how a server advertises its capabilities. No signup required; a mismatch is a server bug.Get the rest if you need it. The remaining tools unlock at the All-Access tier;
/apidelivers the x402 challenge for on-chain settlement.
That is the loop: label, diff, verify, connect.
Conclusion
Real MCP examples are revision-specific. Verify transports, auth, and capabilities before shipping. The value is a working connection, not a screenshot. Paste mcp.moltlinestudio.com/<server> into your client and call tools/list. Build from evidence, not assumptions. Your next real endpoint is one request away.