MCP core concepts: hosts, clients, servers and the three primitives

Who this is for and what you will be able to do

This guide is for developers and students who have heard of MCP and want to understand what it is made of. After reading it you should be able to explain the roles of hosts, clients and servers, tell apart the three kinds of server capability, and write a tool function that an agent can call.

What MCP is

The Model Context Protocol (MCP) is a standardized framework that optimizes communication between large language models and external tools, applications and data sources^[1]. Its main value is a shared interface: a tool that speaks the protocol can be used by any MCP-capable application, without writing separate integration code for each one.

Hosts, clients and servers

MCP follows a client-server architecture in which one host application can connect to several servers^[1]. Typical hosts include Claude Desktop, Visual Studio Code and Claude Code^[1]. The host coordinates model interactions, controls the user interface, enforces permissions and security constraints, and manages user approval for data sharing and tool execution^[1].

The host creates one client for each server it uses. A client is a logical one-to-one link to a particular server, and it does not require a persistent network connection^[1]. A server provides context, tools and capabilities. It can run on the same machine as the host or on an external platform^[1].

The three server primitives

A server can expose any combination of three primitives^[1]:

• Resources: contextual data such as files, database entries, knowledge-base articles and API responses. Resources are identified by URIs, listed with resources/list and read with resources/read^[1].
• Prompts: reusable templates that structure a conversation with a model and support variable substitution. They are listed with prompts/list and fetched with prompts/get^[1].
• Tools: executable functions a model can invoke to act or to retrieve live data. Each tool has a distinct name, a description and a parameter schema defined with JSON Schema. They are listed with tools/list and run with tools/call^[1].

One way to remember the difference: tools do things, while resources supply material. Tools can also carry annotations such as readOnlyHint and destructiveHint, which say whether a tool is read-only or destructive, so that clients can decide before running it^[1].

A typical tool call runs like this: the user asks something in the host, and the host passes the input to the client. If the model decides a tool is needed, the client sends a tool invocation request to the server, naming the tool and its parameters. The server runs the function and returns the result in a structured format. The client adds that result to the model context, and the model writes the answer the host shows the user^[1].

Client-side capabilities

Clients can also expose capabilities that servers may use^[1]:

• Sampling: a server asks the client's AI application for a model completion, using sampling/createMessage.
• Roots: a server learns which filesystem locations are relevant, identified with file:// URIs. Roots are only hints and do not grant access or form a security boundary^[1].
• Elicitation: a server asks the user for more information or confirmation through the client interface, using elicitation/create^[1].
• Logging: a server sends structured log messages to the client.

In the 2026-07-28 revision, sampling, roots and logging are deprecated but kept for compatibility. New implementations should integrate directly with a model provider's API, pass directories through tool parameters, resource URIs or server configuration, and use stderr with OpenTelemetry for observability. All three may be removed in the first specification revision released on or after 28 July 2027^[1]. Elicitation is not deprecated.

Protocol version and transports

MCP uses date-based versions in YYYY-MM-DD format, and the current version is 2026-07-28^[1]. The full specification for that version is published at modelcontextprotocol.io^[1][2]. This revision removes the initialize handshake and protocol-level session IDs, which makes the transport layer stateless^[1].

MCP messages use JSON-RPC 2.0. A request carries an id, a method and optional params; a notification has no id and expects no reply^[1].

There are two main transports^[1]:

• STDIO uses standard input and output to talk to a local process on the same machine, which suits local servers.
• Streamable HTTP uses HTTP POST for client-to-server messages and can use Server-Sent Events for streaming back, which suits remote servers across a network. It supports bearer tokens, API keys and custom headers, and MCP recommends OAuth for token-based authentication^[1].

Hands-on: a Python weather tool

The example uses the fastmcp package, which you install first^[1]:

pip install fastmcp

The tool function itself comes next. The @mcp.tool() decorator registers an ordinary function as an MCP tool^[1]:

@mcp.tool()
def get_weather(location: str) -> dict:
    """Gets current weather for a location."""
    return {
        "temperature": 72.5,
        "conditions": "Sunny",
        "location": location
    }

This snippet contains only the tool function. To run it you also need to create the fastmcp server object and start it over standard input and output; follow the official documentation for that setup^[2]. The function returns fixed data, so a real tool would call a weather service inside it.

Common questions and limits

• A model can call any tool you expose, so permissions matter from the start. MCP does not require a confirmation dialog before every tool call, but hosts should make tool invocations visible, let a person deny them, and show inputs and impact before sensitive operations run^[1].
• Remote connections should use HTTPS and the MCP authorization model. Local stdio servers rely on process isolation, trusted configuration and careful handling of inherited credentials^[1].
• Validate every parameter against its schema and reject malformed input, which helps prevent injection attacks^[1].
• The Tasks extension covers long-running operations. In the 2026-07-28 revision it is an official extension that uses tasks/get, tasks/update and tasks/cancel; tasks/list has been removed^[1].
• Servers written for the 2025-11-25 revision should follow the 2026-07-28 change notes, because some concepts have changed^[1].

Next step

After this guide, read the official specification to check the details of each method and field^[2]. When you start building, begin with one read-only tool, confirm that a host can list it and call it, and only then add write operations and permission controls.

Adapted from lesson 1 (Core Concepts) of Microsoft's open-source course *MCP for Beginners*^[1], released under the MIT License.