MCP Servers and Clients: Roles, Transports and Setup

What is it?

MCP has three roles:

• Host — the user-facing AI application: a desktop chat app, an IDE, a custom agent. It owns the conversation with the model and enforces user consent.
• Client — a connector inside the host. Each client maintains a one-to-one connection with a single server. A host with three servers runs three clients.
• Server — a program that exposes capabilities to clients: it might wrap a database, a file system, a SaaS API or a search service.

Servers advertise capabilities; clients and hosts decide how to present them to the model and user.

Why does it matter?

Knowing the roles tells you where things run and who is responsible for what. A local server runs on the user's machine with the user's permissions. A remote server runs on someone else's infrastructure and may need authentication. The host decides what the model may call and when to ask for approval. Mistakes about these boundaries are the usual source of security problems.

How does it work?

Capabilities a server can expose

• Tools: model-invoked actions with JSON-Schema inputs.
• Resources: readable data identified by URIs, typically chosen by the application or user to add context.
• Prompts: templates for common tasks, typically surfaced to users.

Clients may also offer features back to servers, such as asking the host's model to generate text (sampling), subject to user approval. Support varies by client, so check what your host implements.

Transports (how messages travel):

• stdio: the host launches the server as a local subprocess and exchanges JSON-RPC messages over standard input/output. Simple and common for local tools.
• HTTP-based (Streamable HTTP): the server runs as a web service; the client sends requests over HTTP and the server can stream responses. Suited to remote and shared servers, and the area where authorization requirements apply (MCP Authorization (OAuth for MCP Servers)). Earlier versions of the spec used HTTP with Server-Sent Events; the specification has changed over time, so use the current docs.

Lifecycle

Specification revisions up to 2025-11-25 (stateful):

1. Client connects and sends an initialize request with its supported protocol version and capabilities.
2. Server replies with its own; the client confirms.
3. Client lists tools/resources/prompts and uses them during the session.
4. The connection closes when the host shuts down or the user disconnects.

Revision 2026-07-28 (stateless): the initialize handshake and protocol-level sessions (the Mcp-Session-Id header) were removed. Each request carries the protocol version and client capabilities in its metadata; servers must implement a server/discover call that advertises supported versions, capabilities and identity; and servers that need state across calls use explicit handles passed as ordinary tool arguments. The same revision replaced server-initiated requests such as sampling and elicitation with a multi round-trip pattern in which the server returns an "input required" result and the client retries with the answers. Check which revision your SDK and host implement before following a tutorial.

Building a server: official SDKs exist for several languages. You define tools (name, description, input schema, handler) and the SDK handles the protocol. The handler is ordinary code — which is where you validate input and enforce permissions.

Example

A typical local configuration, as used by several desktop clients (the exact file name and keys differ per host — this is illustrative only):

{
  "mcpServers": {
    "notes": {
      "command": "node",
      "args": ["./notes-server.js"],
      "env": { "NOTES_DIR": "/home/me/notes" }
    }
  }
}

The host starts notes-server.js, performs the handshake, lists its tools (say search_notes, create_note), and offers them to the model. Limiting NOTES_DIR to one folder is least-privilege in practice.

When should I use it?

Build an MCP server when you want your service or data reachable from multiple AI clients. Use existing servers when a trusted, maintained one covers your need. Run local stdio servers for personal, on-device access; use remote servers for shared or hosted capabilities, with proper authentication.

Common mistakes

• Running unreviewed servers from the internet with broad file or network access.
• Putting secrets in config files that are shared or committed.
• Exposing tools that are too powerful (arbitrary shell, arbitrary SQL) instead of narrow ones.
• Auto-approving every tool call.
• Assuming all clients support all features.
• Trusting tool descriptions and outputs as safe — a malicious or compromised server can try to manipulate the model (What is Prompt Injection?).

Related concepts