MCP (Model Context Protocol) Overview

Before MCP, connecting an LLM application to an external tool or data source meant writing a custom integration per tool, per application. The Model Context Protocol standardizes that connection so a tool server built once can be used by any MCP-compatible client.

The three roles

• Host — the application the user actually interacts with (a chat UI, an IDE, an agent runtime). The host embeds one or more MCP clients.
• Client — the piece inside the host that speaks MCP to a server, maintaining a 1:1 connection and handling the request/response lifecycle.
• Server — a lightweight process that exposes capabilities — tools, resources, prompts — over the protocol. A server doesn't know or care which host is calling it.

This separation is the actual point: a server exposing "search the web" or "query this database" can be written once and plugged into any compliant host, instead of every application reimplementing its own version of the same integration.

What a server can expose

• Tools — functions the model can call, with a declared input schema. The model decides when to invoke them based on the conversation; the host executes the call and returns the result.
• Resources — addressable data (files, API responses, database rows) that the host can read and feed into context, similar in spirit to a GET endpoint but discoverable through the protocol itself.
• Prompts — reusable prompt templates a server can expose, so common interaction patterns don't have to be hand-copied into every client that wants them.

Transport

MCP messages are JSON-RPC 2.0 over one of a few transports — most commonly stdio (for local servers spawned as a subprocess) or HTTP with server-sent events (for remote servers). The transport is an implementation detail; the message schema is what stays constant, which is what lets the same server logic run locally or remotely without changing how tools are declared or called.

Why this matters for agent systems specifically

Agent frameworks (LangGraph, custom tool-calling loops, etc.) already have a concept of "a tool the model can call." What they don't standardize is where that tool comes from or how it's discovered. MCP gives that a common shape:

• A new capability (e.g. a web search server) can be added to an agent by connecting to an MCP server, not by writing a new tool-calling adapter for every framework it needs to work with.
• Tool schemas are declared by the server and discovered at connection time, so the host doesn't need hardcoded knowledge of every tool it might ever use.
• The same server can back a chat UI, an IDE assistant, and a headless agent runtime simultaneously, since none of those hosts need server-specific integration code.

Practical notes

• A server should keep tool descriptions precise — the model picks which tool to call based on the description and schema alone, so vague descriptions lead to wrong or missed tool calls.
• Local stdio servers are the simplest way to get started (no networking, no auth to configure) but don't work for capabilities that need to be shared across multiple hosts or users — that's where an HTTP/SSE server earns its complexity.
• Resource and tool lists can change at runtime; well-behaved clients re-fetch them rather than caching indefinitely, since a server's available capabilities aren't guaranteed static across a session.