What is Model Context Protocol (MCP)?
Model Context Protocol, usually shortened to MCP, is an open specification, published by Anthropic, for connecting an LLM-based application to external tools, files, and data sources through one standard interface. Instead of writing a custom integration for every tool a model might need to call, a developer runs or connects to an MCP server that exposes those tools in a consistent format, and any MCP-compatible client can then discover and use them.
The problem it addresses
Before a standard existed, connecting a model to a database, a file system, or a third-party API meant writing bespoke glue code for each combination of model and tool. An assistant that needed to read local files, query a database, and call a search API required three separate integrations, each tied to whichever model framework was in use. MCP separates the tool-serving logic from the model-calling logic: a server implements the protocol once, and any client that speaks MCP can use it, independent of which model sits behind that client.
How it's structured
MCP defines a client-server relationship. An MCP server exposes three main things: tools the model can invoke (functions with defined inputs and outputs), resources it can read (files, records, or other data), and prompt templates it can reuse. An MCP client, typically embedded in an application like an IDE or chat interface, connects to one or more servers, lists what they offer, and passes that information to the model so it can decide when to use them. The connection can run locally over standard input and output, or remotely over HTTP.
How MCP relates to function calling
MCP builds on top of function calling rather than replacing it. Function calling is what lets a model output a structured request to invoke a named function with specific arguments. MCP standardizes the layer above that: how a client discovers which functions are available in the first place, how it presents them to the model, and how results get passed back, so that adding a new tool doesn't require reworking the model integration itself.
Where things still vary
MCP is a young specification, and while several model providers and tool vendors have published servers and clients, the exact set of features supported, authentication handling, and versioning behavior differ between implementations. Anyone building on it should check the current spec and their specific client's support before relying on advanced features like streaming resource updates or server-initiated prompts, since these have moved during the protocol's early revisions.
Why it matters for self-hosted deployments
MCP doesn't depend on where the model runs. A self-hosted model behind an OpenAI-compatible API can sit behind an MCP client the same way a hosted API would, calling local or internal MCP servers to reach internal databases, ticketing systems, or file shares without that data leaving your infrastructure. For teams already keeping inference private for data-residency reasons, running the tool layer through local MCP servers keeps the whole request path, not just the model call, inside your own network. See what is an LLM agent for how tool access fits into agent design more broadly.