ScreenshotNeo
Sign in Get a free key

BlogAI agents

MCP Client vs. MCP Server vs. MCP Host: Roles, Architecture, and Examples

Understand MCP hosts, clients, and servers with message flows, transports, security boundaries, code examples, and practical design guidance.

By the ScreenshotNeo team1 October 20269 min read

Short answer: The MCP host is the enclosing AI application that manages conversations, permissions, and multiple connections. An MCP client is the host-created connection to one server. An MCP server provides focused tools, resources, and prompts. A host can run many clients, while each client maintains one dedicated server connection.

This distinction matters when you design an integration, choose stdio or Streamable HTTP, debug a failed request, or decide where authorization and context filtering belong.

1. The three MCP roles at a glance

Role What it is Owns Typical location
Host The application or process that embeds the AI experience Conversation, model coordination, consent, authorization, lifecycle, and isolation policy Claude Desktop, Claude Code, or another AI application
Client A protocol component created and managed by the host for one server One connection, message routing, capability negotiation, subscriptions, and result forwarding Inside the host process
Server A focused capability provider Tools, resources, prompts, and server-side business logic A local subprocess or remote service

The official architecture describes a client-host-server model in which each host can run multiple client instances. A useful mental model is host = orchestration and policy, client = protocol connection, and server = capabilities.

2. How a request moves through MCP

  1. A user or model action arrives at the host.
  2. The host selects the relevant server and its dedicated client instance.
  3. The client sends a JSON-RPC request to that server.
  4. The server executes a tool, reads a resource, or returns a prompt.
  5. The client forwards the result to the host.
  6. The host updates the user interface or adds the result to the model context.
User or model
    |
    v
MCP host (conversation, policy, consent)
    |
    +-- client A --> server A (files)
    |
    +-- client B --> server B (database)
    |
    +-- client C --> server C (web tools)

Each client-server connection is isolated. A server does not automatically receive the host’s entire conversation or data from other servers. The host decides what context and permissions are passed into each interaction.

3. What an MCP host does

Conversation and model coordination

The host owns the user-facing application and usually holds the complete conversation. It coordinates the model, decides when a tool call is appropriate, and presents results.

Connection and lifecycle management

The host starts or connects to servers, creates one client per server, negotiates protocol versions and capabilities, handles reconnects, and shuts connections down. A host can combine local and remote servers in one session.

Authorization decisions belong at the host boundary. The host can ask for user consent before a tool runs, restrict which servers are enabled, and apply organization policies. A server should receive only the context needed for its task.

Isolation

The host keeps server connections separate. If a file server and a ticketing server are both connected, the ticketing server cannot inspect the file server’s conversation or results unless the host deliberately forwards that information.

4. What an MCP client does

An MCP client is not the whole AI application. It is the host-managed protocol component for exactly one server.

  • Maintains the dedicated connection to its server.
  • Routes bidirectional JSON-RPC messages.
  • Negotiates protocol versions and capabilities.
  • Tracks subscriptions and resource updates when supported.
  • Forwards server results and errors to the host.
  • Advertises client-side capabilities and honors the negotiated feature set.

Because the relationship is one client to one server, a host that connects to five servers normally manages five client instances. This is the key difference between a client and a host.

5. What an MCP server does

A server exposes a focused set of capabilities through MCP primitives:

Primitive Purpose Control
Tools Executable functions such as querying a system or creating a ticket Generally model-controlled
Resources Contextual data that an application can read or subscribe to Generally application-controlled
Prompts Reusable interaction templates Generally user-controlled

Servers may request supported client-side interactions such as elicitation, but they do not gain unrestricted access to the host conversation. A server can be a local process or a hosted service.

6. Is Claude Desktop a host or a client?

Claude Desktop is an MCP host. It can create and manage multiple MCP client instances, each connected to a different server. The same distinction applies to Claude Code and other AI applications that embed the model, manage permissions, and coordinate several integrations.

Calling the application a “client” is understandable in everyday language because it connects to servers, but in MCP terminology the application is the host and the per-server connection inside it is the client.

7. Does every MCP server need its own client?

Yes, in the MCP architecture a host creates one client instance for each server connection. The client owns that connection’s negotiation, messages, subscriptions, and lifecycle. A host may reuse a client for the lifetime of a server connection, then create a new one after a restart or reconnect.

8. Should your code be an MCP server or an MCP client?

Build a server when… Build a client when…
You want to expose your product’s actions, data, or prompts to AI applications. You are building the enclosing AI application that connects to servers.
Your code should be usable by Claude Desktop, Claude Code, or multiple MCP hosts. You need to manage conversations, model calls, permissions, and several server connections.
You can define a narrow capability boundary. You need to route tool calls and results between a host and one server.

Most product integrations are servers. Most custom AI shells are hosts that also contain clients. You rarely build a standalone client unless you are implementing an MCP host or a bridge between systems.

9. Transport choices: stdio and Streamable HTTP

stdio for local processes

With stdio, the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages through standard input and output. It suits local integrations, keeps setup simple, and avoids network overhead.

Client process                      Server subprocess
     |                                      |
     | -- JSON-RPC line on stdin ---------> |
     | <- JSON-RPC line on stdout --------- |

Streamable HTTP for remote services

With Streamable HTTP, the client sends HTTP requests to a remote server. Optional streaming and standard HTTP authentication methods make it the normal choice for hosted or internet-accessible servers.

The JSON-RPC message model stays the same across transports. Changing from stdio to HTTP changes deployment and authentication, not the conceptual responsibilities of host, client, and server.

10. Minimal JSON-RPC message flow

The exact method names and capabilities depend on the MCP specification revision, so consult the versioned specification when implementing production code. The following illustrates the shape of a request and response:

// Client -> server
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "lookup_issue",
    "arguments": {"id": "BUG-42"}
  }
}

// Server -> client
{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {"type": "text", "text": "Issue BUG-42 is assigned to Maya."}
    ]
  }
}

The host receives the result through the client and decides whether to show it, pass it to the model, request confirmation, or take another action.

11. Capabilities and negotiation

Servers advertise supported capabilities such as tools, resource subscriptions, and prompt templates. Clients advertise the client-side interactions they support. During initialization, both sides negotiate the feature set they can safely use.

  • Do not assume a server supports every primitive.
  • Check the negotiated capabilities before calling optional features.
  • Handle an unsupported method as a normal compatibility error.
  • Pin or validate protocol versions when reproducibility matters.
  • Review the current versioned specification before relying on exact method names.

The July 28, 2026 release announcement describes a stateless protocol core, multi-round-trip requests, header-based routing, cacheable list results, and updated Tier 1 SDKs. Implementations should still follow the versioned specification they target.

12. Security and isolation checklist

  • Keep authorization decisions in the host.
  • Request user consent for sensitive tool calls.
  • Pass the minimum context required for each server task.
  • Use one client connection per server to preserve boundaries.
  • Authenticate remote servers with the HTTP mechanism supported by your deployment.
  • Validate tool arguments and enforce server-side authorization; model intent is not permission.
  • Log connection, capability, and failure events without recording secrets.
  • Close subprocesses and revoke credentials when a server is disabled.

13. Reliability and performance considerations

Latency

stdio avoids network round trips for local servers. Streamable HTTP adds network latency but works across machines and supports hosted deployments. Tool execution time usually dominates, so measure connection setup, protocol exchange, and the server operation separately.

Connection reuse

Keep a client connection open when the host handles multiple requests for the same server. Repeated initialization adds overhead and can make subscriptions unreliable.

Timeouts and retries

Set a host-side timeout for initialization and each tool call. Retry only operations that are safe to repeat, or include an idempotency strategy in the server. Do not blindly retry mutations such as creating an order or deleting a record.

Backpressure

Limit concurrent tool calls per server. A host should queue or reject work when a server is overloaded rather than creating unlimited subprocesses or HTTP requests.

Resource updates

If a server supports subscriptions, ensure the client can process updates and the host can decide which changes belong in model context. Unbounded updates can consume context and memory.

14. Common errors and fixes

Error or symptom Likely cause Fix
Server starts, then immediately exits Startup exception or malformed stdio output Run the server directly, inspect stderr, and ensure stdout contains only protocol messages.
“Method not found” Client called a method outside the negotiated or targeted specification Check the server’s advertised capabilities and your protocol version.
Tool is missing from the model Tool listing failed, was filtered by the host, or the server did not advertise tools Inspect initialization and list results; verify host policy and server registration.
HTTP authentication failure Missing, expired, or incorrectly scoped credentials Verify the authorization mechanism, endpoint, headers, and server-side logs.
Requests hang No timeout, blocked subprocess, network issue, or server deadlock Add bounded timeouts, capture stderr, check connectivity, and inspect concurrent work limits.
Server sees too much context Host forwarded the whole conversation Filter arguments and context at the host boundary; send only task-relevant data.
Duplicate side effects after retry Non-idempotent tool was retried Disable automatic retries for mutations or add idempotency keys.
Updates stop arriving Subscription was not negotiated, connection dropped, or client lifecycle ended Confirm capabilities, reconnect deliberately, and resubscribe after reconnect.

15. Testing a host, client, or server

  1. Server unit tests: validate tool arguments, authorization, error mapping, and resource reads without a network.
  2. Client contract tests: verify initialization, capability negotiation, message correlation, timeouts, and reconnect behavior.
  3. Host integration tests: connect multiple servers and confirm isolation, consent prompts, and context filtering.
  4. Transport tests: run the same protocol scenarios over stdio and Streamable HTTP where both are supported.
  5. Failure tests: terminate a subprocess, return malformed data, delay a response, and revoke credentials.

16. ScreenshotNeo as an MCP server for visual research

If an AI agent needs website screenshots, ScreenshotNeo provides an MCP server with take_screenshot, get_page_info, and capture_pdf tools. The host remains the AI application, its MCP client maintains the connection, and ScreenshotNeo is the focused capability server.

For a direct HTTP request, see the ScreenshotNeo API documentation.

17. Or skip the browser setup

For a screenshot API call, send one GET request:

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing result. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card, and paid plans start at $5 for 3,000 shots.

Create a free ScreenshotNeo account and start with 1,000 screenshots each month at no charge.

18. FAQ

Can one server connect to multiple hosts?

Yes. Each host creates its own client connection. A server should treat every connection as a separate authorization and lifecycle boundary.

Is a host always a desktop app?

No. A host can be any AI application or process that manages model interaction, clients, permissions, and server lifecycle.

Can a server call another server directly?

The architecture centers coordination in the host. If one capability needs data from another server, the host should normally orchestrate those calls and pass the minimum required result.

Does changing transport change MCP semantics?

No. stdio and Streamable HTTP carry the same JSON-RPC model; they differ in deployment, networking, and authentication.

Where should secrets live?

Keep credentials in the host or server’s secure runtime configuration, never in model-visible prompts or untrusted tool arguments. Apply the narrowest scope that permits the operation.

Which specification should I implement?

Use the versioned MCP specification supported by your SDK and host. Capability details and method names can evolve, so avoid relying on an unversioned example alone.

Keep reading