Model Context Protocol (MCP), explained simply

Every team that ships an LLM feature eventually hits the same wall: the model is only as useful as the tools and data you can hand it. So you write an integration for your database, another for your ticketing system, another for the filesystem — each with its own glue code, its own auth, its own schema for describing what the tool does. Do this across a few applications and you have re-implemented the same plumbing many times over.

The Model Context Protocol (MCP) is an open standard that fixes this by defining one way for LLM applications to connect to external capabilities. Instead of N applications each writing M custom integrations, you write a capability once as an MCP server, and any MCP-aware application can use it.

The host, client, and server model

MCP has three roles, and keeping them straight is most of understanding the protocol.

• Host — the LLM application the user interacts with: a desktop assistant, an IDE, a chat product. The host manages the model and decides which servers to connect to.
• Client— a connector that lives inside the host. The host spins up one client per server, and each client holds a single, isolated connection. This one-to-one pairing is what keeps servers from seeing each other's traffic.
• Server — a standalone program that exposes capabilities: tools the model can call, resources it can read, and prompts it can reuse. A server wraps one system — your Postgres, your GitHub, your internal API — and speaks MCP on the outside.

Why this beats bespoke integrations

The win is the same one every good protocol delivers: an M×N problem becomes M+N. Before MCP, connecting five applications to five systems meant twenty-five custom integrations. With MCP, you build five servers and five clients, and everything interoperates. A server someone else wrote for, say, a search engine drops into your host with no bespoke code on your side.

Standardization also buys you a few things that are easy to underrate:

• Discoverability.A host can ask a server "what can you do?" at runtime. The server returns its tools with names, descriptions, and JSON schemas, and the model decides what to call. You don't hardcode capabilities into the app.
• Separation of concerns. The team that owns a system owns its MCP server. Application teams consume it without knowing its internals — same as any API, but with a shape the model understands natively.
• Portability. Because the interface is standard, you can swap the host — move from a desktop assistant to your own product — without rewriting a single integration.

A concrete example

Here is a tiny server that exposes one tool — look up a customer by ID — and one resource. The transport and boilerplate vary by SDK; the shape is what matters.

server.tool(
  "get_customer",
  "Fetch a customer record by ID.",
  { id: z.string() },
  async ({ id }) => {
    const row = await db.customers.find(id);
    return { content: [{ type: "text", text: JSON.stringify(row) }] };
  }
);

server.resource(
  "refund-policy",
  "docs://policy/refunds",
  async () => ({
    contents: [{ uri: "docs://policy/refunds", text: policyText }],
  })
);

When the host connects, the client asks the server to list its capabilities. The model sees a get_customertool with a typed argument and a description, and it can call it when a user asks about an account. The refund-policy resource can be pulled into context so answers stay grounded in the real document rather than the model's guesses.

That's the whole idea. MCP doesn't make models smarter — it makes the connective tissue between models and the real world standard, so the integration you write today is one anyone can reuse tomorrow.