If you are asking what is mcp server, the authoritative answer starts with the Model Context Protocol specification, not a vendor blog. MCP is defined there as an open protocol for seamless integration between LLM applications and external data sources and tools, offering a standardized way to connect models with the context they need. An MCP server is the server-side role in a JSON-RPC protocol that exposes capabilities to AI systems, enabling composable integrations and workflows. Because the spec uses BCP 14 normative keywords such as MUST and SHOULD, precise reading matters.
This guide walks through the specification's server side model. We will clarify what an MCP server is in three sentences, then map Host, Client, and Server roles. You will learn the four server capabilities: Discovery, Prompts, Resources, and Tools; the client-side features Roots, Sampling, and Elicitation; and the transport options stdio, Streamable HTTP, and custom bindings. We will also try one in 60 seconds, cover security and production notes, discuss payment and agent-to-agent settlement, answer common questions about MCP servers, and close with next steps.
What an MCP Server Is, in Three Sentences
The specification says it plainly. MCP is "an open protocol that enables seamless integration between LLM applications and external data sources and tools," and it provides "a standardized way to connect LLMs with the context they need."
So, in three sentences: an MCP server is the server half of a JSON-RPC protocol. It advertises a set of capabilities. It answers requests from an AI client over a transport, and the client decides what to do with the results.
Definitional claims belong on authoritative artifacts, not vendor blogs. The 2026-07-28 specification "defines the authoritative protocol requirements," and the TypeScript schema is the machine-readable version of that contract.
Read the spec with BCP 14 in mind. It adopts RFC 2119 and RFC 8174 keywords, so MUST and SHOULD carry normative weight. When someone tells you a client "must" do something, check whether the document says MUST or only SHOULD.
For a plain-language entry point, use the canonical intro page. We are not trying to out-rank it. This guide goes where it does not: transports, production security, and payment. For wider orientation, see What Are MCP Servers? A 2026 Guide to Model Context Protocol.
The Server Side Role: Host, Client, Server
Host, client, server: three roles. A host application (Claude, Cursor, Codex CLI) embeds a client. That client speaks JSON-RPC to one or more servers. The server exposes capabilities and does the work asked of it.
More precisely, an MCP server is the server-side role in a JSON-RPC protocol that exposes tools and capabilities to AI systems, which is how developers build composable integrations and workflows instead of hand-rolling a bespoke integration per model vendor.
It is not necessarily a web server. Over stdio it is a local subprocess the client launches: no port, no TLS, no DNS name. Streamable HTTP servers resemble web services; stdio servers never touch the network.
Fan-out runs both ways. One server can serve many clients; one client can connect to many servers at once. That is how a single agent session holds file access, a database, and a search tool in the same context window. For how a server divides work internally, see Anatomy of an MCP Protocol Server: Resources, Prompts, and Tools.
Because MCP defines server-side and client-side roles precisely, logic placed on the wrong side, routing decisions in the server, capability decisions in the client, undermines the model.
The Four Server Capabilities: Discovery, Prompts, Resources, Tools
The server exposes exactly four capabilities. Enumerate these and you have enumerated the whole server surface, the backbone of any MCP integration.
Discovery is how a client learns what the server offers before calling anything, which is why capability negotiation happens up front rather than being assumed.
Tools are callable functions the model invokes with arguments. A create_invoice tool takes a customer id and an amount and returns a document id. See the tools specification.
Resources are addressable context the client reads, closer to files than functions. A resource URI can return the current contents of a config file or a table schema, as described in the resources specification.
Prompts package reusable instructions the client can invoke by name. A review_migration prompt takes a file path and returns a structured review request.
The four capability surfaces are the ones you build against. A Utilities group also appears in the spec sidebar, logging, completion, and operational helpers, but it is not a fifth tool surface you expose to callers. The client side contributes features of its own.
What Runs on the Client Side: Roots, Sampling, Elicitation
Server capabilities stop at the four above. Roots, Sampling, and Elicitation run the other direction. The spec files them under Client Features, not Server Features.
Roots tell the server which directories or boundaries the client is willing to expose. The client draws the sandbox, so your server stops guessing. If a tool walks a filesystem, read the roots list, not the process working directory.
Sampling lets a server ask the client's model to generate text. You get summarization or classification without an API key, a model choice, or an inference bill. That pattern shows up in web, search, and browser automation, where a page has to be condensed before the tool returns it.
Elicitation lets a server ask the user for missing input mid-task, in form or URL mode, instead of failing or letting the model invent a default. Design error paths around a prompt, not a dead end.
The asymmetry is the point. These are client features. If you build a server, you consume them. You do not implement them.
Transports: stdio, Streamable HTTP, and Custom Bindings
Transport is a binding, not a semantics layer. The spec is explicit: "Protocol semantics are identical on every transport," and message patterns "are part of the core protocol and are the same on every binding" (transports overview).
stdio is "newline-delimited messages over the standard streams of a client-launched subprocess." The client starts your process and talks over stdin and stdout. Fits local tooling and single-user setups.
Streamable HTTP is "each message [being] an HTTP POST to a single MCP endpoint." One URL, no local process. That is what makes hosted servers pasteable into any client.
Both carry the same MUSTs: messages are JSON-RPC, and a binding "MUST" deliver client requests and notifications inbound and server responses and notifications outbound. Custom transports are allowed if they meet those obligations.
Selection rule: stdio when the server is a local process tied to one machine; Streamable HTTP when it is remote, shared, or needs to survive a client restart. For a worked comparison, see stdio vs. Streamable HTTP: Which Should You Use?.
Try One in 60 Seconds
Copy an endpoint of the form mcp.moltlinestudio.com/<server> and paste it into Claude, Claude Code, Cursor, or Codex CLI as a remote MCP server. There is no install step and no local process to manage. If you want the client-specific menus, adding a remote MCP server in under 60 seconds covers that part.
The free tier is the endpoint and nothing else: 110 of 160 tools across 22 hosted servers, free forever, with no account, no API key, and no signup. The remaining 50 tools sit behind a $19/month All-Access license, payable in cryptocurrency.
Verify it worked. Ask the client to list tools, then make one real call, a fetch or a lookup, and confirm a result comes back. If the tool list is empty, the endpoint is wrong, not the protocol.
One tradeoff, stated plainly. A hosted endpoint means you do not run the process, which also means you do not control its uptime or its internals. If that matters, run your own server over stdio and compare the two.
Security and Production Notes
Pasting an endpoint is the easy part. The page to read next is the spec's own: modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices, which treats authorization, SSRF, and SSRF Against Authorization Servers as distinct topics.
SSRF against an authorization server is the sharp edge. A server that accepts a URL from a client and fetches it can be steered at internal metadata endpoints or at the very authorization service it trusts. Validate and allowlist. Parsing a URL is not validation.
Deployments break in three places: a server that ships with no auth, a token audience nobody checks, and tool arguments that flow straight into a shell or a query string. The third one is technical requirements for implementing licensed MCP servers territory, not protocol trivia.
The uncomfortable part: an MCP server is an execution surface handed to a probabilistic caller. Treat tool arguments as untrusted input, because the model will eventually send something you did not anticipate.
Scope, honestly. This is a one-person studio's tooling, not a compliance program. There is no certification to point at. Read the spec's security page before you expose anything to the open internet.
Payment and Agent-to-Agent Settlement
The spec covers authorization, not billing. Payment negotiation is not part of the core specification, so anyone calling it standardized is describing a vendor convention, not the protocol.
Moltline runs a live example. moltlinestudio.com/api returns HTTP 402 (Payment Required) with an x402 challenge, so a client can learn the price of a one-month All-Access licence without a human reading a pricing page. The agent requests the resource, gets 402 with payment details, settles on-chain, and retries with proof of payment. No signup, no dashboard, no card form in the loop. The x402 machine payment flow walks the same sequence.
The $19/month licence unlocks the same 50 premium tools.
Know the limit. x402 settles payment. It does not establish identity, reputation, or refunds. If you need those, build them yourself.
Common Questions About MCP Servers
The x402 flow above is a convention layered on the protocol. The questions below are about the protocol itself.
Is an MCP server a web server? No, see the Transports section above for the stdio vs. Streamable HTTP distinction.
Does it have to run locally? No. Remote servers are addressed by the spec, and hosted endpoints such as mcp.moltlinestudio.com/<server> are the practical version of that.
How is it different from a REST API? A REST API is documented for humans to read and wire up by hand. An MCP server describes its own capabilities to the client at runtime, so one integration works across compliant clients without per-client glue.
Which spec revision should I build against? Pin a dated revision. The 2026-07-28 release introduces breaking changes and a formal deprecation policy, so review the spec's deprecation guidance before you commit to behavior.
Can one server expose tools, resources, and prompts together? Yes, the spec's four capabilities are defined independently. A server that only implements Tools is a common pattern; check the Server Features overview for the capability-declaration rules.
Next Steps
Paste mcp.moltlinestudio.com/<server> into your client, pick a free server, and confirm the tool list populates.
Building rather than consuming? Run your setup through the free agent-readiness checker and the SKILL.md linter before you publish. Neither requires an account. The 138 SKILL.md agent skills open on GitHub at GarphenGate/moltline-oss are working examples of the packaging pattern, and the linter will show you where yours falls short.
If the 110 free tools are not enough, the $19/month All-Access licence unlocks the remaining 50, payable in cryptocurrency. Bundles are distributed through Agensi.
The model, compressed: an MCP server is a JSON-RPC server that advertises tools, resources, prompts, and discovery, and speaks the same semantics over stdio or Streamable HTTP. Pick a transport, respect the normative MUSTs, treat tool arguments as untrusted input. That is the whole model.
Conclusion
An MCP server is a JSON-RPC server that advertises discovery, prompts, resources, and tools, then speaks consistent semantics over stdio or Streamable HTTP. That consistency is the payoff: one integration can serve many compliant clients without per-client glue. Treat tool arguments as untrusted, pin a dated spec revision, and respect the normative MUSTs before production.
Paste an endpoint, confirm the tool list, and start building.