How does an MCP server work?
Architecture and communication
MCP follows a client-server model. The host (e.g., Claude Desktop, an IDE) runs an MCP client that connects to one or more MCP servers. Each server is a lightweight program that advertises its capabilities upon connection.
Communication happens via JSON-RPC 2.0 messages. For local servers, stdio (standard input/output) is common: the host spawns the server as a subprocess and exchanges messages over stdin/stdout. For remote servers, HTTP with Server-Sent Events (SSE) allows bidirectional streaming.
The protocol defines a handshake where the client and server exchange capabilities. The server lists its tools, resources, and prompts, and the client can then request them.
- Host: AI application that manages the conversation
- Client: connector inside the host that talks to one server
- Server: program exposing tools/resources/prompts
- Transport: stdio or HTTP+SSE
Tool invocation flow
When a user sends a message, the host passes it to the LLM along with a list of available tools from connected MCP servers. The LLM may respond with a tool call request, specifying the tool name and arguments.
The host's MCP client forwards that request to the appropriate server. The server executes the tool (e.g., queries a database, calls an API) and returns the result as a JSON-RPC response. The host then feeds the result back to the LLM, which generates a final answer for the user.
This flow is similar to standard function calling, but the tool definitions and execution are decoupled from the host. The server can be written in any language and run anywhere, as long as it speaks MCP.
- LLM requests a tool call based on user input
- Host routes request to the correct MCP server
- Server executes and returns result
- Host sends result to LLM for final response
Resources and prompts
Beyond tools, MCP servers can expose resources, which are like files or data sources the model can read. For example, a server might expose a log file or a database table as a resource. The host can list resources and read their contents on demand.
Prompts are reusable templates that help users interact with the server. They can include parameters and are often surfaced as slash commands or menu items in the host UI. This makes it easy to standardize common workflows.
Common mistakes
- Thinking the MCP server runs inside the LLM; it's a separate process that the host manages.
- Assuming all MCP servers must be local; remote servers over HTTP+SSE are supported.
- Believing the server decides when to call tools; the LLM (via the host) makes that decision.