What is the Model Context Protocol (MCP)?

<p>The Model Context Protocol (MCP) is an open standard for connecting language models to tools and data through one consistent interface, so an integration you write once keeps working across different models and host applications.</p> <p>Every time you wire an LLM into a real system, you hit the same wall. The model can reason about your data, but it cannot reach it. Your Postgres rows, your ticketing system, the file on disk that the answer actually depends on. So you write glue. A function here, a JSON schema there, a bespoke adapter for each model vendor. Then a new model ships, or a new data source appears, and you write the glue again.</p> <p>MCP exists to stop that loop.</p> <p>What problem does MCP actually solve?</p> <p>Before MCP, "give the model access to X" meant N times M work. N models, M data sources, and a custom bridge for every pair. Each bridge had its own auth story, its own way of describing what a tool does, its own error handling.</p> <p>MCP collapses that into N plus M. You write one MCP server that exposes your data source. Any MCP-capable client can talk to it. Swap the model, keep the server. Add a second app, point it at the same server. The protocol is the contract in the middle, and both sides only have to speak that contract.</p> <p>If you have used the Language Server Protocol, the shape is familiar. LSP let one language server serve many editors instead of every editor reimplementing support for every language. MCP does the same move for model context.</p> <p>How MCP's client/server model works</p> <p>MCP has three roles worth naming clearly.</p> <p>The host is the application the user interacts with. A desktop assistant, an IDE plugin, a chat UI, your own agent.</p> <p>The client lives inside the host and manages one connection to one server. If the host talks to four servers, it runs four clients.</p> <p>The server is a small program you write that exposes capabilities. A GitHub server, a filesystem server, a company-database server. A server does not track which model is on the other end. It answers protocol messages, and the same server works no matter which LLM the host is driving.</p> <p>Transport is either stdio (the host launches the server as a subprocess and talks over stdin/stdout, good for local tools) or HTTP with server-sent events for remote servers. Messages are JSON-RPC 2.0 in both cases.</p> <p>The important property: the server declares what it can do, and the host discovers those capabilities at connection time. Nothing is hardcoded on the model side.</p> <p>MCP vs raw function calling</p> <p>Function calling is a model feature. The model can emit a structured call against a schema you pass in. MCP is the transport, discovery, and reuse layer built around that feature, so the same capability works across hosts without rewiring.</p> <p>Concern Raw function calling MCP<br> Where tools are defined In your app code, per model vendor In a standalone server, once<br> Reuse across apps Copy the code into each app Point each app at the same server<br> Discovery You hardcode the tool list Host lists tools at connect time<br> Isolation Runs in your app process Server runs as a separate process with its own permissions<br> Transport Vendor SDK specific JSON-RPC over stdio or HTTP/SSE<br> Beyond actions Tools only Tools, resources, and prompts<br> Tools, resources, and prompts</p> <p>An MCP server exposes three kinds of things, and each has a distinct job when you design a server.</p> <p>Tools: actions the model can invoke</p> <p>Tools are actions the model can invoke. create_issue, run_query, send_email. They can have side effects. Each tool ships a name, a description, and a JSON Schema for its inputs. The model reads that schema and decides when and how to call.</p> <p>A tool definition looks roughly like this:</p> <p>json<br> {<br> "name": "search_orders",<br> "description": "Find orders by customer email or order id.",<br> "inputSchema"