Model Context Protocol

You've probably had that moment. You're deep in a conversation with an LLM, it's giving you genuinely sharp analysis, and then you ask it something simple — "what's the weather like in London right now?" and it falls flat on its face.

That's because your model is stuck behind a wall. It can think, but it can't reach anything. Not your files, not your calendar, not your company's database, not the live web. Everything it knows is frozen in time from when it was trained.

Enter MCP.

Model Context Protocol. The name explains itself quite well actually:

Model: your LLM.
Context: the extra information that helps it make better decisions.
Protocol: an agreed set of rules for how that communication works.

In terms of a brief background, it's an open standard, built by Anthropic and driven by the community, that gives models a universal way to connect to tools and live data.

The analogy I keep coming back to is USB-C. Remember when every device had its own proprietary cable and you needed a drawer full of chargers? MCP does for AI what USB-C did for hardware.

Aside from standardisation, there are two key challenges:

First, models can't see what you don't show them. Your private APIs, internal databases, local files none of that exists to the model unless you manually feed it in. MCP lets the model pull what it needs, when it needs it.

Second, context windows are expensive. Cramming everything into a prompt isn't just impractical, it's costly. MCP flips the approach instead of pushing the world to the model, the model reaches out for exactly what's relevant.

How it actually works

The architecture is client-server. Your app runs an MCP client (the messenger), which talks to one or more MCP servers (the capabilities). Each server can expose three things:

Resources: data the model can read. For developers think of it like a GET request. A database query, a file, an API response.
Tools: actions the model can take. For developers, think more like a POST. Updating a record, modifying a file, sending a message. This is where your assistant stops being passive and starts being useful.
Prompts: reusable templates you can share across your network so you're not reinventing the wheel every time.

For transport, you've got two options. Firstly, STDIO for anything local e.g. CLI tools, desktop apps. And secondly, Streamable HTTP for anything over the web. That's basically the whole decision.

What does this look like in practice?

You can spin up multiple MCP servers at once; one for web search, one for file access, one for your internal API. The model figures out which tool it needs and calls it.

Some real examples: live Google search, weather data, reading and writing local files, or querying a private company API that no public model would ever have access to.

Can I build one?

Yes, and it's quicker than you'd think. The gist:

Install the MCP SDK and Zod (for input validation)
Create a server, register your tools and resources with a name, description, and handler
Pick a transport, connect, and you're running

A working server fits in under 60 lines. The https://modelcontextprotocol.io/docs/getting-started/intro walk you through it, and the MCP Inspector gives you a way to test and debug as you go.

In a nutshell, your AI was stuck behind a wall. MCP is the door. What you connect it to is up to you.