MCP in Practice

You have M AI applications and N systems worth connecting them to. Without a standard that is M × N integrations, each written against a proprietary plugin interface, each rewritten when either side changes. With one, it is M + N. That is the entire pitch, and it is the same pitch as the Language Server Protocol — which is the right analogy to hold in your head. LSP didn't make editors smarter; it made "add Rust support" a thing you do once instead of once per editor. MCP does that for context and actions. What it deliberately does *not* do: it does not tell the model what to do, does not run the model, does not decide permissions, and does not make a badly-designed API pleasant. It standardizes the wire, so the interesting problems are the ones left over.

Three roles, and confusing them makes every other document unreadable. The **host** is the application the user is actually using — an IDE, a desktop assistant, an agent framework. It talks to the model, owns the UI, and enforces permission. A **client** lives inside the host and maintains one connection to one server. Ten servers means ten clients inside the host. The one-to-one pairing is deliberate: it keeps each server's capabilities and session state isolated from every other's. A **server** exposes capabilities — a wrapper around Postgres, GitHub, your internal deploy system, the filesystem. It is usually small, usually stateless, and it can run as a local subprocess or a remote HTTP service. The chain to keep straight: the **model** decides it wants a tool, the **host** approves it, the **client** sends the request, the **server** does the work. The model never touches the server, which is exactly why the design is safe enough to be useful.