The three things a server can expose
Tools are operations the model may invoke, each described by a name, a schema for its arguments, and what it returns: "list the callers of this function", "open a change request". Because the model chooses when to use them, a well-run client asks the person before anything consequential runs.
Resources are content identified by a URI, such as a file, a record or a report the server produced, which the application pulls into context when it is relevant. They are for reading; changing anything is the job of a tool.
Prompts are named, parameterised templates that a person invokes on purpose. They let the team that owns a system publish the tested way to do a task right next to the tools that do it.
Where it sits
The specification names three parties. The host is the program in front of the person: an IDE, a desktop chat app, a terminal agent. The host runs a client for each server it is connected to, and that client is what authenticates and exchanges messages. The server is the program on the other end. The language model works through the host: it is shown each tool's description and proposes the calls.
What reaches the server is the request, not the chat around it. That limits what a server can learn about a person, and it also means a server cannot tell where an argument came from: a value the model copied out of an attacker's document arrives looking exactly like one the person typed. Every argument has to be validated as hostile input.
The rule that matters most
The specification forbids token passthrough: a server may only accept tokens issued for it, and may not forward a person's token on to another system. Checked on every request, that is what keeps each action attributable to the person who asked, rather than to a shared service account that can see more than they can.
What changed in the 2026-07-28 specification
The protocol became stateless. There is no opening handshake and no session identifier: every request carries its own protocol version and capabilities, so any request can land on any server instance behind an ordinary load balancer. A server that needs state across calls returns an explicit handle and checks, on every call, that the handle belongs to the person presenting it.
The older HTTP-and-server-sent-events transport is deprecated, with a twelve-month window to move. Clients now identify themselves with a metadata document at a URL they control, and dynamic client registration is on its way out. Long-running work and in-chat interfaces became official extensions. A server built in 2025 still works today, but it has a migration due.
When you need one, and when you do not
A single person automating their own work on their own machine is usually better served by a command-line tool or a packaged skill, which costs the model less context. Warehouse access may already be covered by the platform's own managed server. An MCP server earns its place when many people need the same capability, when every call has to be attributable to a person, and when the system behind it is one no assistant can reach on its own.
The question to ask of any MCP server
Whose identity does this call run under? If the answer is a service account, every person who can reach the server can see whatever that account can see, and the audit log names a machine instead of a person. If the answer is "the person who asked, checked on every request", the server is doing its job.